Hi,

I’ve a simular problem here with my stm32l071, see the log below. A wiring problem seems not to be the issue here,  the “STM32CubeProgrammer” does the programming well.

Tried two boards….

Any news around this topic? Did you solve the problem?

Thnx

Martin

Open On-Chip Debugger 0.10.0 (2017-06-09) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport “hla_swd”. To override use ‘transport select <transport>’.
adapter speed: 240 kHz
adapter_nsrst_delay: 250
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v31 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.184252
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000
STM32L0: Enabling HSI16
adapter speed: 1800 kHz
VisualGDB_OpenOCD_Ready
Info : accepting ‘gdb’ connection on tcp/64516
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 96kb, base address is 0x8000000
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000
STM32L0: Enabling HSI16
adapter speed: 1800 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000
STM32L0: Enabling HSI16
adapter speed: 1800 kHz
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20005000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20005000
Error: jtag status contains invalid mode value – communication failure
Info : Previous state query failed, trying to reconnect
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x20000006 msp: 0x20005000
Error: error writing to flash at address 0x08000000 at offset 0x00000000
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1389). Workaround: increase “set remotetimeout” in GDB
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000

• This reply was modified 5 years, 7 months ago by mcipjvw.

Hi,

Thanks for your reply. I just played with the adapter speed. Setting to 1200 kHz did the job for now. Remarkable that programming with the stm32cube programmer does not give any problem.

Martin

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?

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.

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

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!

Thanks for pointing this out. This looks like a different issue from the other STM32L0 bug we were aware of (FLASH programming errors triggered by section alignment).

We have just released an updated OpenOCD package adding the dual-bank devices to the device selection menu (and also including latest updates from the OpenOCD repository). Please feel free to install it via Tools->VisualGDB->Manage VisualGDB Packages.

We will also review the STM32L0 device parameters during the next STM32 BSP update and will see if there is an easy way to detect the dual-bank devices automatically.