search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.52k stars 6.45k forks source link

STM32L432KC Nucleo Reference board SWD problem after programming with Zephyr #35055

Closed chucklink closed 2 years ago

chucklink commented 3 years ago

I am developing an application currently running on STM32L432 KC Nucleo reference board. I have created an STMCubeMX startup file and simple application that works flawlessly. I can program and reprogram at 4000 kHz using the STMCube programmer tool. I want to use Zephyr RTOS so I’ve built the Zephyr 2.5.0 L432KC project exactly as documented: https://docs.zephyrproject.org/2.5.0/boards/arm/nucleo_l432kc/doc/index.html
I can build either the “Blinky” or “HelloWorld” and load the image the first time flawlessly using The onboard ST-LINK at 4000 kHz. However as soon as the Zephyr project is loaded, the SWD becomes troublesome. West Flash loses complete control. Moving back to STM tools I can sometimes connect. I can not communicate at any speed other that 5 kHz. Sometimes not at all. Usually it requires a power cycle and holding reset to erase (at 5 kHz) to reprogram. Then I can use West Flash again.

Most interesting, I can program the STMCubeMX image and reprogram multiple times at 4000 kHz. If I move over to the Zephyr tools and image, I can use West Flash the first time at full speed and subsequently I can reprogram the Zephyr image at 480 kHz. If I remove power from the target, I have to go back to the STM Programmer to erase the Zephyr image at 5 kHz and start the process again. It appears at the Zephyr image is not initializing at least one register at startup. Once the register is set using the STMCubeMX image, as long as power is not removed, the Zephyr image works OK (not great since programming speed is only 480 kHz.)

Has anyone else seen this or resolved this issue? It appears that something is not being initialized completely. I will continue the research, as well as try this on other STM boards.

I did try this on a Nucleo STM32F401 and it does not seem to exhibit the problem. It works flawlessly.

FRASTM commented 3 years ago

Did you try to update the stlink firmware of the nucleo board using the stm32Cubee Programer

I can flash and re-flash with 'west flash' different samples successively on a nucleo_l011k4 (nucleo32)
(its STLINK version is V2J29M18)

chucklink commented 3 years ago

I did update the ST-LINK Firmware without success. I've tested this function on numerous other boards (Mostly "F") boards and the problem does not exist on them. I've ordered 4 new "L" boards with different processors to test the functionality.

DariusBabrauskas commented 3 years ago

I have same problem with stm32L4a6.

  1. With stm32CubeProgrammer I connect at speed 15 ... 125K then do mass erase.
  2. Then I able flash at hight speed. Then I can work normal until power off/on. After this swd speed decrease again, and I must repeat step 1. I use zephyr v2.5. CPU power 1.8V Using Software Reset.

It looks software problem - (maybe MPU or corruption system registers ...) Disabling MPU "CONFIG_ARM_MPU=n" not help.

erwango commented 3 years ago

I have same problem with stm32L4a6.

Thanks for keeping us informed. I guess this is a custom board, right ? (this could be a potential clue in the analysis)

DariusBabrauskas commented 3 years ago

Yes, this is custom board. But I found chucklink report. He using nucleo board. So possible system error. I dont have problem with swd speed before.

erwango commented 3 years ago

I dont have problem with swd speed before.

@DariusBabrauskas Are you suspecting a regression ? If yes, can you share some details ?

DariusBabrauskas commented 3 years ago

After investigation, possible we found cause of problem. It looks that swd can't connect if mcu sleeping (wfi). (our custom board dont have hardware reset connected to swd- if it can help). My test code in init.c file before main:

.....................
    int cnt=0;
    while(1){
                k_msleep(1);//swd can connect
        //k_msleep(3);//swd can't connect
        printk("%04d.\r\n",cnt++);
    }
    extern void main(void);

    main();..................
DariusBabrauskas commented 3 years ago

Solution for stm32 :

#if CONFIG_DEBUG_SWD == 1
#include "stm32l4xx_ll_system.h"
#endif

//insert this code anywhere and must be executed:
#if CONFIG_DEBUG_SWD == 1
    LL_DBGMCU_EnableDBGSleepMode();//
#endif

add in default Kconfig.defconfig
config DEBUG_SWD
         bool "Enable usage debug via swd in wfi mode"
         default y
erwango commented 3 years ago

Thanks @DariusBabrauskas for reporting this. If that's the solution we're looking for for this issue, then ok, I don't think this could be harmful. What I'm not sure to understand is why this would be needed now, as this is not specific to a L4xyz specific variant, not L4 specific at all. Is that a new issue that appeared recently or would it be because of your custom board specifics ("our custom board dont have hardware reset connected to swd- if it can help") ?

@chucklink Can you have a try with the proposed solution and see if fixing your issue ?

Btw, I just got hands on a nucleo_l43kc board this morning. I'm sorry to say that I don't reproduce exactly the point you're mentioning ("impossible to flash a zephyr image following a power off on a board using zephyr image"). What I do see, though, in the same condition, is that openocd complains, but finally manages to get back on its feet and eventually flashes. Cf log below

Error: mem2array: Read @ 0xe0042004, w=4, cnt=1, failed
Error executing event examine-end on target stm32l4x.cpu:
/local/mcu/zephyrproject/sdk/zephyr-sdk-0.12.2/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts/mem_helper.tcl:6: Error: 
in procedure 'ocd_process_reset' 
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 288
in procedure 'mmw' called at file "/local/mcu/zephyrproject/sdk/zephyr-sdk-0.12.2/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts/target/stm32l4x.cfg", line 108
in procedure 'mrw' called at file "/local/mcu/zephyrproject/sdk/zephyr-sdk-0.12.2/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts/mem_helper.tcl", line 36
at file "/local/mcu/zephyrproject/sdk/zephyr-sdk-0.12.2/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts/mem_helper.tcl", line 6
Info : Previous state query failed, trying to reconnect
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800145c msp: 0x20000740
Polling target stm32l4x.cpu failed, trying to reexamine
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : device idcode = 0x10016435 (STM32L43/L44xx - Rev: Z)
Info : flash size = 256kbytes
Info : flash mode : single-bank
Warn : Adding extra erase range, 0x08003468 .. 0x080037ff
auto erase enabled
wrote 13416 bytes from file build/nucleo_l432kc/zephyr/zephyr.hex in 0.875596s (14.963 KiB/s)

And I can actually see the exact same behavior on other L4 board (disco_l475_iot1).

About programming speed, indeed STM32CubeProgrammer offers to flash using higher speed than current openocd configuration in Zephyr. I'm not sure that we can change openocd setting, but you can use stm32cubeprogrammer runner. Cf for instance boards/arm/nucleo_g071rb/board.cmake

erwango commented 3 years ago

@chucklink Did you have time to looked at upper comment ?

DariusBabrauskas commented 3 years ago

It seems to me, that @erwango used openocd. I am using pyocd. Maybe theys scripts different. Openocd at start used low connection speed.

github-actions[bot] commented 2 years ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.