How to write bytes to flash without restart?

[ADiet.1]

I am trying to use the windows version of STM32_Programmer_CLI.exe (version 2.13.0) to write bytes to a flash (windows 10). The command I am using is like

./STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -w8 0x08080000 0x00 0x00 0x00 0x00 0x00 0x00 -w8 0x08080C00 0xAA 0x00 0x00 0x00 0x00 0x00 -v

and although I use the "mode=hotplug", each time I run this command a restart is triggered. I did expect no restart when using "mode=hotplug".

Can I try something else to be sure to avoid a restart/reset?

[Sara BEN HADJ YAHYA]

Hello @ADiet.1​ ,

Thanks for your feedback,

Could you please explain how you've noticed the reset.

I did some tests from my side and no reset has been triggered with HOTPLUG mode.

Waiting for your response,

Sara.

[ADiet.1]

I am connected to the UART debug port to check the log/debug output. This log shows me a reboot/restart of the device.

[Sara BEN HADJ YAHYA]

Hello @ADiet.1​ ,

Could you please share your project and the log output for further check.

Thanks in advance,

Sara.

[Tesla DeLorean]

https://community.st.com/s/question/0D53W00002Axzb7SAB/how-can-i-use-the-stm32cubeprogrammer-windows-executable-to-read-a-memory-area-without-the-device-resetting

[ADiet.1]

Hello, here is the complete output:

 -------------------------------------------------------------------
 STM32CubeProgrammer v2.13.0
 -------------------------------------------------------------------
 
ST-LINK SN : 53FF6E065056705437210781
ST-LINK FW : V2J29S7
Board : --
Voltage : 3.24V
SWD freq : 4000 KHz
Connect mode: Hot Plug
Reset mode : Software reset
Device ID : 0x447
Revision ID : Rev Z
Device name : STM32L07x/L08x/L010
Flash size : 128 KBytes
Device type : MCU
Device CPU : Cortex-M0+
BL Version : 0xB2
 
 
Downloading 8-bit data...
 
██████████████████████████████████████████████████ 100%
Downloading 8-bit data done successfully
 
Downloading 8-bit data...
 
██████████████████████████████████████████████████ 100%
Downloading 8-bit data done successfully
 
Verifying ...
Read progress:
██████████████████████████████████████████████████ 100%
Download verified successfully

And I checked, the device made a restart again.

[Sara BEN HADJ YAHYA]

Hello @ADiet.1​ ,

The output you shared doesn't show the reset, could you please share the trace where the reset is observed.

Thanks,

Sara.

[ADiet.1]

An application runs on the device which is being restarted. It starts as if I would switch power off and power on again...

[Sara BEN HADJ YAHYA]

Hello @ADiet.1​ ,

Could you please create a simple project in which you send a counter over USART and re-do the test with the command.

STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -w8 0x08080000 0x00 0x00 0x00 0x00 0x00 0x00 -w8 0x08080C00 0xAA 0x00 0x00 0x00 0x00 0x00 -v

If the counter restarted, send me the project.

Thanks in advance,

Sara.

[ADiet.1]

Hello Sara,

thanks for your time looking into this issue with me. I just had some time to take a look again and there seem to be at least two real, reproducible issues with the STM programmer independent of the software running on the device. We can have a teams call so I can show in real life the problems that I have with the hardware/software.

First of all, when I use the command to write bytes to the device I always get an error

Error: Failed to download data! If it's a Flash memory, it may be not erased or protected
 
Downloading 8-bit data done successfully
 
Downloading 8-bit data...
 
██████████████████████████████████████████████████ 100%
Downloading 8-bit data done successfully
 
Verifying ...
Read progress:
██████████████████████████████████████████████████ 100%
Download verified successfully

when I run the command, which is very confusing as below I get the messages that all is fine. Except when I execute the command twice within one second. Then I do not get that error line. Also Independent if I get this error or not the device resets.

The device resetting: I can see that by

1. looking at some UART debug port which shows some output
2. I head a noise from the device (maybe a relais)
3. the LED's used in the device blink off and on

So the device definitively resets. Also, when I write the SAME bytes to the memory the device also resets. Even if the firmware on the device checks some memory/bytes regularly, there is no change of the bytes in the memory. So the software cannot possible detect any change in the memory/bytes/flags, independent of what software is being used on the device. The ONLY event that coincides with the reset is the writing of the flags using the command

./STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG -Rst -w8 0x08080000 0x00 0x00 0x00 0x00 0x00 0x00 -w8 0x08080C00 0x00 0x00 0x00 0x00 0x00 0x00 -v

I will however double check with a developer if the software is able to detect when a STM programmer connects to the device and performs a software reset on the disconnect event, but I find that highly unlikely as the firmware has nothing to do directly with the STM programmer.

Otherwise I see no other explanation as that the STM programmer itself triggers the reset itself.

Please let me know if a meeting of some sort can be arranged so I can show you in more detail the issues I have. Thank you

[ADiet.1]

Hello,

so this restart could be caused by the software on the device. But for this top happen the mcu must be put in a `halt` state. So how can I run this above command without putting the microcontroller in any halt state? I tried different options and even tried with `--run`, but it does not seem to work...

[Sara BEN HADJ YAHYA]

Hello @ADiet.1​ ,

When using the Hotplug mode, connection to the target is done without a halt nor a reset. From CubeProgrammer side I can assure you that there is no isse in the HotPlug connection mode.

In your case, a reset is triggered and from you're saying it is probably caused by the software, if that is the case, the halt could be also triggered by the software.

You can use the "-score" command to check the core status (�?Running�?, �?Halted�?, �?Locked up�?, �?Reset�?, or �?Kept under reset�?).

At this level, I can confirm that the issue is not related to the CubeProgrammer tool, I suggest you review the software that can contain the root cause of the problem. 

Thank you for your contribution to the ST community, if you have another issue, please do not hesitate to create another thread.

Sara.

[ADiet.1]

Hello again,

there is still the issue with the above mentioned error I get when writing to the mcu, and I do not understand what a "core locked up" means for the core status.

I also tried to write bytes without any additional option, but I also used "-run", "-step" and "-halt" and in every case I get a core status "Core locked up". What does it mean?

[Tesla DeLorean]

Alternate approach, your firmware could facilitate the writing of these values via a console or user interface during final test, etc​