STM32L496G discovery kit - st-flash write does not work - flash loader run error

[homer242]

• Programmer/board type: Stlink/v2-1 onboard
• Programmer firmware version: V2J28M18
• Operating system: Linux 4.13.0-1-amd64 # 1 SMP Debian 4.13.10-1 (2017-10-30) x86_64 GNU/Linux
• Stlink tools version and/or git commit hash: v1.4.0-13-g1969148
• Stlink command line tool name: st-flash
• Target chip (and optional board): STM32L496G discovery kit

I cannot use st-flash to write an image on linux. By now, I use Windows to do this. I can see these information in the STM32 ST-LINK Utility when I click on "Connect to the target." button:

11:29:41 : ST-LINK SN : 0674FF555352845187081728
11:29:41 : ST-LINK Firmware version : V2J28M18
11:29:41 : Connected via SWD.
11:29:41 : SWD Frequency = 4,0 MHz.
11:29:41 : Connection mode : Connect Under Reset.
11:29:41 : Debug in Low Power mode enabled.
11:29:41 : Device ID:0x461 
11:29:41 : Device flash Size : 1MBytes
11:29:41 : Device family :STM32L49x

It works pretty well on Windows (Windows 7 Pro) but I need to hold on the reset button when I plug the board to the USB port of my laptop. If I do not, the ST-LINK program does not work well. I do not know why I need to do this but I saw on Internet few month ago a guy talk about this hint and since I use this trick. A colleague with the same board and a different laptop (with Windows XP) can use it without this trick. Pretty weird. Perhaps, this behavior can explain why I cannot use st-flash on linux ?

~/wksp/dev $ st-flash --format ihex write output/images/STM32L4_mr4k.hex                                                            
st-flash 1.4.0-13-g1969148
2017-11-28T11:20:35 INFO common.c: Loading device parameters....
2017-11-28T11:20:35 INFO common.c: Device connected is: L496x/L4A6x device, id 0x20006461
2017-11-28T11:20:35 INFO common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2017-11-28T11:20:35 INFO common.c: Attempting to write 82704 (0x14310) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08014000 erasedEraseFlash - Page:0x28 Size:0x800 
2017-11-28T11:20:36 INFO common.c: Finished erasing 41 pages of 2048 (0x800) bytes
2017-11-28T11:20:36 INFO common.c: Starting Flash write for F2/F4/L4
2017-11-28T11:20:36 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 32768
2017-11-28T11:20:39 ERROR flash_loader.c: flash loader run error
2017-11-28T11:20:39 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

If I use the option --debug, there are extra information. I put the output in an attached file: write_debug_out.txt

After trying to write an image with st-flash, If I plug the board on my Windows laptop and try to start the board with ST-LINK_CLI.exe, nothing happen:

C:\Users\admin\Desktop\fw>ST-LINK_CLI.exe -Rst -Run
STM32 ST-LINK CLI v3.1.0.0
STM32 ST-LINK Command Line Interface

ST-LINK SN : 0674FF555352845187081728
ST-LINK Firmware version : V2J28M18
Connected via SWD.
SWD Frequency = 4000K.
Target voltage = 3.3 V.
Connection mode : Normal.
Device ID:0x461
Device flash Size : 1024 Kbytes
Device family :STM32L49x
MCU Reset.

run application to exit

Failed to run application!
The core is kept under Reset!

I hope the information will be enough to help me.

Thank you,
Anthony V.

[Nightwalker-87]

@homer242: Please verify if the problem still exists in Release v1.5.0.

[homer242]

Hi, I will try this version next monday and let you know the result. Regards, Le ven. 20 mars 2020 à 12:52, Nightwalker-87 <notifications@github.com> a écrit :

…

@homer242 </~https://github.com/homer242>: Please verify if the problem still exists in Release v1.5.0. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#657 (comment)>, or unsubscribe </~https://github.com/notifications/unsubscribe-auth/AAADB7UVRPCP45EGDY22MH3RINKJJANCNFSM4EFUE46A> .

[homer242]

I have just tested with the version 1.5.1 available in debian buster. I was able to flash my board:

st-flash write /home/avd/wksp/dev/output/images/img.bin 0x8000000
st-flash 1.5.1
2020-03-23T16:13:24 INFO common.c: Loading device parameters....
2020-03-23T16:13:24 INFO common.c: Device connected is: L496x/L4A6x device, id 0x20006461
2020-03-23T16:13:24 INFO common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2020-03-23T16:13:24 INFO common.c: Attempting to write 481512 (0x758e8) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08075800 erasedEraseFlash - Page:0xeb Size:0x800 
2020-03-23T16:13:30 INFO common.c: Finished erasing 236 pages of 2048 (0x800) bytes
2020-03-23T16:13:30 INFO common.c: Starting Flash write for F2/F4/L4
2020-03-23T16:13:30 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 22760
2020-03-23T16:13:41 INFO common.c: Starting verification of write complete
2020-03-23T16:13:45 INFO common.c: Flash written and verified! jolly good!

Thanks for all the work done !

[Nightwalker-87]

@homer242: Thx. Release v1.5.0 did not work?
BTW: I think this was fixed by yourself: See PR #615. (°.°).
Seems as if only a necessary reference is missing here...

[Nightwalker-87]

Edit: ... but it is in wrong chronological order. Very confusing to me.

[homer242]

I do not know whether it works with the version 1.5.0 or not.

I forget lot of things about the issue context. Apparently, the flash operation did not work with the version v1.4.0-13-g1969148 and my board based on STM32L4 microchip. Indeed, the PR #615 says I make a fix for STM32L496xx/4A6xx devices and it was before I opened this issue. It is a little bit disturbing.

I think the story is I did a mistake with the title of this issue and saying there was a problem with the "STM32L496G discovery kit". I did first try with the discovery board. And stlink worked well after my fix (PR #615 ). Next, I might have tried with an another board based on STM32L4 microchip, it did not work and this is why I opened this issue. Actually, it was rather a problem with the board I think.

[Nightwalker-87]

I see. So if you say it may have been a hardware related problem, which is no longer reproducible, I'd suggest to link this to the mentioned PR without changing the title. The latter would not help any further as the circumstances are too old to remember precisely. To sum it up: You did a PR for v1.5.0 which adds support for the mentioned board and later used tried with v1.4.0 and reported this. (for whatever reason, I don't question that :-D ). However it was solved already by then. So it is fixed in v1.5.0, where this now solved issue belongs. That's all I needed to know.

Thank you for helping to get this sussed out. 👍