[Ancaritha]

Yup, local C# program throws the same error.  However, I can just click on the link and get the text that it returns.  I can even get it inside of Visual Studios and it formats it as XML automatically for me.  For some reason I just can’t create an SSL connection to it.  I’ll have to poke around on the firewall and see if I can figure out exactly what’s causing that as I can obviously visit the link fine, I just can’t create an SSL connection to it…

 

Thanks for providing the direct link so I have something to test against.  Worst case scenario, in the short term I can at least copy the text and create my own PackageCatalog.xml file 🙂  Thanks!

[Ancaritha]

Fun fact, I just hopped on the WiFi of another company that we share a space with (they used to be part of us and I help administrate things on their network from time to time) and it also failed on their network.  They also have a SonicWall firewall (though a different model) but everything that’s configured on it is totally different than ours and they have a different ISP.  It’s possible that SonicWall pushed some sort of update that is flagging this connection erroneously as something bad which means other people might also run into this problem.  My VisualGDB packages did have a version of GCC 9.3 available for download, just not the latest so it was working until somewhat recently.

[Ancaritha]

I just whitelisted *.visualgdb.com and it still doesn’t work.  Are there any specific sub domains that need to be whitelisted?  I know to download the GCC package I couldn’t just do *.sysprogs.com, I had to specifically do us.cdn.sysprogs.com (though I suspect *.*.sysprogs.com would have worked).  Our firewall kept pegging the GCC download as a Trojan and would prevent it from being downloaded (it’s done this back since version GCC 5 or 6 I think).

 

I did just briefly disable our Geo-IP filter and out Gateway Anti-Virus completely and it still failed.  I checked another developers computer and it failed for them as well, so at least it’s not something that’s just on my computer.   I’m going to poke around on the firewall a bit more and see if there is any other filtering happening that I don’t remember about.

 

The full exception text is:

VisualGDB version: 5.4.112.3242
—————— System.Net.WebException ——————
System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
at System.Net.WebClient.DownloadData(Uri address)
at System.Net.WebClient.DownloadData(String address)
at kx1.b(Boolean b, Boolean a)
at VisualGDB.GUI.WPF.PackageListDataObject.FetchThreadBody()

[Ancaritha]

Well, switching to the Online view results in an error message popup that says “The request was aborted: Could not create SSL/TLS secure channel.”  Deleted the PackageCatalog.xml just makes it think I have the latest installed 🙂

 

That sounds an awful lot like something got borked in my installation, so a good old fashioned uninstall/reinstall seems in order.  I figured I’d post the error anyway just in case you guys had seen this before and knew exactly what had to be changed to fix it.

[Ancaritha]

I run into this problem quite frequently as well.  I’m always using the “Start debugger with GDB” option from inside Visual Studios.  I sometimes get that error when I haven’t even set any break points yet.  Usually I just hit stop and then “start debugger” again and it works fine, but on occasion I’ve had to flash the entire chip using the ST-Link Utility and then it’ll work.

I was running a year old version of OpenOCD, which I just updated to the latest.  I’m hoping that’s the issue but knowing about that “info breakpoints” command might be useful, see if there is somehow a disconnect between what Visual Studios thinks it has for breakpoints vs what GDB thinks it has.

[Ancaritha]

For the time being I’ve updated the project I’m working on to use the touch in our repository I’ve added but that echo idea might be worth looking into just so I can remove external dependencies.  It might take some work to get right if I ever have to touch more than one file.  We haven’t had to do that on more recent projects but it’s always a possibility that the need for it might pop up again.  I suppose I could probably just be lazy and make multiple ‘echo’ lines in the makefile 🙂

 

Thanks!

[Ancaritha]

One of our source files, contain the GCC commands __DATE and __TIME__.  These only get updated when the file is changed (which makes sense, otherwise it’s not building it).  Since this is a low level file that we seldom change, we need a way to force GCC to rebuild it to get the updated date and time.  That’s what we use touch for.  It fills in a variable that we can access over our communication system to get the buildstamp for the code running on a device.  We can also display it on the system UI and whatnot.

Making a binaries folder somewhere in our source tree and storing touch there is probably the easiest solution; don’t have to modify the system PATH file or do any extra weird copies when setting up a new computer that could be easy to miss/forget about or install antiquated toolchains.

Touch does actually rely on 2 other files in the toolchain (libicon2.dll and libintl3.dll), but those are both also in the toolchain /bin directories so they’re easy to get.

Thanks!

[Ancaritha]

It would appear that the incorrect target configuration file is being selected.  The “Debugged Device” drop down list just has the STM32L0xx option, which selects target/stm32l0.cfg

According to OpenOCD, approximately 2 years ago a patch was merged that makes it so now dual bank devices (such as the L07x) need to use a new configuration file, stm32l0_dual_bank.cfg.  When I manually switch to that file by modifying the command line options, it programs fine.

[Ancaritha]

I opened a ticket with OpenOCD and posted basically the same information I posted here.  If I hear back anything interesting I’ll update this thread so you guys are made aware of it as well.

 

Thanks!

[Ancaritha]

I’m gonna ignore the 5th file.  I feel like you get the general idea at this point…

Attachments:

You must be logged in to view attached files.

[Ancaritha]

Ok, well the text files are too large to be uploaded, clocking in at an enormous 1.3 megs and 1.8 megs…  So i’m going to do it two different ways.

Full files using google drive (in case you want to look at everything all at once):
Here is the New (broken) version: https://drive.google.com/file/d/1B7g_HdNXt1BKeRnigwQTaDTLI5gMJwSI/view?usp=sharing
Old (working) version: https://drive.google.com/file/d/1636131gweiYT9em3aO28TmsUjIXy07lw/view?usp=sharing

I’m also attaching the files split into 3 and 5 parts respectively.  You can only upload 4 files at once sooooooooooooooooooo yea

Attachments:

You must be logged in to view attached files.

[Ancaritha]

Alrighty, I’ve attached two text files.  The “New” one is using the 2018-12-12 release of OpenOCD.  The “Old” is using our custom built one based off of 2017-04-14.

I placed a breakpoint at the first instruction of Main().  Using our custom built one, I’ll hit it every time.  Using the new one it never gets there.  If I pause the debugger and look at the hardware registers in the debugger and there are some… dubious values there.  R0 through R12 all have a value of 0xffffffff.  SP is 0x20004fe0.  LR is 0xfffffffe.  PC is 0xfffffffe.  I tried looking at the OpenOCD output but theres kind of a lot going on in there…

It should be noted that if I program the board using ST-Link and then do “Attach to running firmware”, it works fine.  It just appears to have an issue with programming the board.

[Ancaritha]

Heh, yup, found the old post: https://sysprogs.com/w/forums/topic/issues-using-newest-version-of-openocd-0-10-0/

Looks like I definitely dropped the ball, I’ll try and pick that up again now 🙂

[Ancaritha]

I’ve noticed that OpenOCD has issues with L0’s  (at the very least, the L071 that I use) if you are using a version after the 2018 release (before that works A-OK).  We had to update to the latest version to support the L496 processor and when I did that I stopped being able to program my L0 board.  We ended up manually building OpenOCD from a slightly older package and adding support for the L496 ourselves so that we could use both.

I recently decided to give the latest OpenOCD another shot and my initial test worked OK but recently I tried to use it again and it usually failed, so I started looking at this again  (I actually posted on the forums about this around a year ago but became swamped and was unable to experiment with it and just had to go with a known working).

When comparing the two OpenOCD outputs, I did notice something odd:

Old version (that works):
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 128kb, base address is 0x8000000

New Version (that fails):
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 64kb, base address is 0x8000000

 

Clock speed and adapter speeds match between the two versions.  Could this be as simple as the config file for the L0 is incorrect?

[Ancaritha]

Unfortunately I’m using make, so that’s not an option.  Oh well, disabling the warning it is.

Thanks for the help!

[Author]

Posts