Loading...
 
Skip to main content

System Workbench for STM32

Forum List Topic List

Forums » System Workbench for STM32 » Debug only works after chip erase in ST-LINK utility
 
Thread actions
Print this page
  • Print all pages

    • Debug only works after chip erase in ST-LINK utility

    Posted by Adrian A on 2017-05-27 23:46

    I have a custom board that I am trying to debug from an ST-Link devleopment board. After much experimentation, I found that I can successfully load and debug a program, but only if the chip had previously been erased with the STM32 ST-LINK utility application. Otherwise, I always get a message of "unplugged target during debug session"

    Here's the console log from a failed launch:



    Open On-Chip Debugger 0.10.0-dev-00278-ga53935e-dirty (2017-05-09-09:25)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    srst_only separate srst_nogate srst_open_drain connect_assert_srst
    Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
    adapter speed: 4000 kHz
    adapter_nsrst_delay: 100
    Info : clock speed 4000 kHz
    Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
    Info : STLINK v2 JTAG v27 API v2 M v15 VID 0x0483 PID 0x374B
    Info : using stlink api v2
    Info : Target voltage: 77.475003
    Info : STM32L082CZYx.cpu: hardware has 4 breakpoints, 2 watchpoints
    Info : accepting 'gdb' connection on tcp/3333
    STM32L082CZYx.cpu: target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xf1000000 pc: 0x08003cb4 msp: 0x20005000
    STM32L0: Enabling HSI16
    Info : Device: STM32L0xx (Cat.5)
    Info : STM32L flash has dual banks. Bank (0) size is 96kb, base address is 0x8000000
    Info : Device: STM32L0xx (Cat.5)
    Info : STM32L flash has dual banks. Bank (1) size is 96kb, base address is 0x8018000
    STM32L082CZYx.cpu: target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xf1000000 pc: 0x08003cb4 msp: 0x20005000
    STM32L082CZYx.cpu: target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xf1000000 pc: 0x08003cb4 msp: 0x20005000
    STM32L0: Enabling HSI16
    Error: jtag status contains invalid mode value - communication failure
    Info : Previous state query failed, trying to reconnect
    STM32L082CZYx.cpu: target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0x81000000 pc: 0x20000004 msp: 0x20005000
    Error: error writing to flash at address 0x08000000 at offset 0x00000000
    STM32L082CZYx.cpu: target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xf1000000 pc: 0x1ff00404 msp: 0x200014d0
    Info : dropped 'gdb' connection

    After a chip erase, the console log from a successful launch looks like this:


    Open On-Chip Debugger 0.10.0-dev-00278-ga53935e-dirty (2017-05-09-09:25)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    none separate
    Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
    adapter speed: 4000 kHz
    adapter_nsrst_delay: 100
    Info : clock speed 4000 kHz
    Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
    Info : STLINK v2 JTAG v27 API v2 M v15 VID 0x0483 PID 0x374B
    Info : using stlink api v2
    Info : Target voltage: 3.257482
    Info : STM32L082CZYx.cpu: hardware has 4 breakpoints, 2 watchpoints
    Info : accepting 'gdb' connection on tcp/3333
    STM32L082CZYx.cpu: target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xf0000000 pc: 00000000 msp: 00000000
    STM32L0: Enabling HSI16
    Info : Device: STM32L0xx (Cat.5)
    Info : STM32L flash has dual banks. Bank (0) size is 96kb, base address is 0x8000000
    Info : Device: STM32L0xx (Cat.5)
    Info : STM32L flash has dual banks. Bank (1) size is 96kb, base address is 0x8018000
    STM32L082CZYx.cpu: target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xf0000000 pc: 00000000 msp: 00000000
    STM32L082CZYx.cpu: target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xf0000000 pc: 00000000 msp: 00000000
    STM32L0: Enabling HSI16
    Warn : couldn't use loader, falling back to page memory writes
    STM32L082CZYx.cpu: target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0xf1000000 pc: 0x1ff00404 msp: 0x200014d0


    I'm also getting the same behavior when I use a Nucleo STM32L073 board.

    After searching some other problems and responsese I've tried several combinations of the settings of the reset_config (can someone point me to a source for what they mean?) in the Debug.cfg file, but I'm getting the same behavior.

    Reads: 22098
    Posted by Adrian A on 2017-05-28 03:01

    Update:

    Erasing the chip before programming no longer works. I haven't changed anything as far as I can tell. It's failing both on my custom board and the STM32L073 Nucleo board.

    I'm importing a fresh example project and debugging it on the STM32L073 nucleo board. That's working (for now).

    This problem has been so inconsistent it's starting to drive me crazy.

    Maybe there is something wrong with my STM32CubeMX settings?

    Another unmodified project won't debug on the STM32L973RZ, but one will.

    Works: \STM32Cube_FW_L0_V1.9.0\Projects\STM32L073RZ-Nucleo\Examples\RCC\RCC_LSIConfig\SW4STM32\STM32L073RZ_NUCLEO
    Doesn't work: \STM32CubeExpansion_LRWAN_V1.1.0\Projects\Multi\Applications\LoRa\PingPong\SW4STM32\STM32L073RZ-Nucleo\sx1272mb2das

    I'll keep at it to see if this is consistently true


         Posted by Adrian A on 2017-05-28 03:58

    Another fun update:

    I was digging through the documentation on the flash option bytes and it occurred to me that when I assembled my custom board I had forgotten to install the pull-down resistor on the BOOT0 pin. I installed the resistor, and was able to debug my program yay!
    I tried it again, and I got the same disconnected error. Boo!
    Tried it again, and it still didn't work. Boo!

    Erased the chip with the utility, and was able to debug! Yay!
    Tried to re-launch the debugger again, and I got the unplugged error again. Boo!
    Erased the chip with the utility, and was able to debug! Yay!
    Erased the chip with the utility, and was able to debug! Yay!
    Tried to re-launch the debugger again, and I got the unplugged error again. Boo!
    Erased the chip with the utility, and was able to debug! Yay!

    So it appears that fixing the boot0 pull-down resistor makes it at least act consistently in that something in the flash from the previously-loaded program prevents a successful debug launch. I notice that when debugging works, it gets past the breaking point with the warning: "Warn : couldn't use loader, falling back to page memory writes".

    I just tried making it fail by re-launching the debugger without first erasing the chip, and the debugger worked. This time I had accidentally tried re-launching without terminating the previous debug, and once I terminated the last debug session, I re-launched and to my surprise, the debug session started successfully. Terminated and tried re-launching and it failed again. When it in place of the "Warn : couldn't use loader, falling back to page memory writes" message, I get:

    Error: jtag status contains invalid mode value - communication failure
    Info : Previous state query failed, trying to reconnect
    Error: error writing to flash at address 0x08000000 at offset 0x00000000

    Maybe when the flash has the previous program, the program also installs some kind of flash loader that fails when it runs?


         Posted by Adrian A on 2017-05-30 06:06
    An update: I found that by setting the debug clock frequency lower (1.8 MHz, down from 4.0 MHz) I stopped getting the errors. Maybe it was primarily a signal integrity issue on my debug cable?

    Posted by smn on 2017-06-15 17:44

    I had the same problem and I solved it by lowering the WORKAREASIZE :
    set WORKAREASIZE 0x1000

    Changing the debug clock frequency had no effect on the problem on my side. I am using :
    set CLOCK_FREQ 4000

         Posted by LaurentL on 2017-06-16 10:31

    Thanks for the answer.

    I found that lowering swd freq to 480 KHz on big project, it was ok.

    But lowering WORKAREASIZE to 0x1000 solved it definitely and SWD freq can be let at 4MHz.

         Posted by Adrian A on 2017-06-18 05:25
    That worked for me as well, at 4 MHz. So my problem wasn't a signal integrity issue. The chip has 0x5000 of RAM, so I'm not sure how the default debug workarea size of 0x5000 would work in any case, since I gather from this source that the working area should be some free RAM that can be used by the debugger, and would presumably need to be smaller than (physical size - application size). It's also not clear to me how the debug interface speed plays into this. Guessing here, but maybe the work area gets disabled if it's set to be >= the whole chip SRAM size, and the SRAM work area is needed to speed things up enough to support the full speed?

    Posted by andrey2016 on 2017-07-06 12:06

    Another problem: Debug started through time (stm32l496).
    But the same solution.
    Yes. It works. Set WORKAREASIZE to 0x1000 in debug.cfg and disable automatic debug script generation ( .. Run/Debug Configurations/debuger)


         Posted by ags3268 on 2017-10-03 18:00

    Just wanted to chime in that I had the exact same problem where I could only program about 1 out of 5 attempts (sometimes 1/10) even though I had reduced the frequency and raised the voltage. I am using STM32L051 with an STLINKV2 ISOL:

    I got the same:

    Error: jtag status contains invalid mode value - communication failure
    Info : Previous state query failed, trying to reconnect
    Error: error writing to flash at address 0x08000000 at offset 0x00000000

    The solution of reducing WORKAREASIZE to 0x1000 worked perfect! Now I'm 10/10.

    Many thanks as it took about two months to finally stumble upon this post.

         Posted by LaurentL on 2017-10-03 18:07

    Hi,

    Normally, the issue has been corrected.

    On which version are you working ?
    It should work if you install latest version. v2.2.0.

    Rgds,
    Laurent


         Posted by NoellEagan on 2017-10-03 19:15

    Hi..i am a new user here. As per my knowledge the chip has 0x5000 of RAM, so I’m not sure how the default debug workarea size of 0x5000 would work in any case, since I gather from this sourceQuestion that the working area should be some free RAM that can be used by the debugger, and would presumably need to be smaller than.

    https://www.7pcb.com

         Posted by LaurentL on 2017-10-04 09:02

    Yes, the workarea in ram is used to program the flash.
    But the bigger it is and the longer the flash programming is and the STM32L0 are long to program (compares to other STM32F) so there were some errors on swd communication.
    As i said, It has been corrected.

    And even in the meantime, the L0 cfg has a reduced workarea size of 2K (0x800). So, not even 4K (0x1000).

    So, if it is still not working now using SW4STM32 v2.2.0, let us know.

    Rgds,
    Laurent


    Posted by MarkV6 on 2017-10-30 08:06
    Did you configure the Debug Serial Wire (SWCLK and SWDIO) in your configuration?