Stlink: STM32L422CB: st-flash fails to flash ihex image

Created on 12 Apr 2020  ·  12Comments  ·  Source: stlink-org/stlink

Trying to flash a small hex file to a STM32L422CB. The hex file is fine, flashes successfully with st-link utility. st-flash erases the first 2kb page of flash successfully, but doesnt write the the hex file at all.

  • Programmer/board type: STLink V2
  • Programmer firmware version: V2.J34.S7
  • Operating system and version: Windows 10
  • Stlink commandline tool name: st-flash v.1.6.0
  • Target chip (and board if applicable): STM32L422CB

Futher we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:

Commandline-Output:

PS C:\Users\xxx\Documents\Code\Test> st-flash --format ihex write ./build/test.hex
st-flash 1.6.0
2020-04-12T18:28:57 INFO common.c: Loading device parameters....
2020-04-12T18:28:57 INFO common.c: Device connected is: L41x device, id 0x10006464
2020-04-12T18:28:57 INFO common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 2048 bytes
2020-04-12T18:28:57 INFO common.c: Attempting to write 592 (0x250) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-04-12T18:28:57 INFO common.c: Finished erasing 1 pages of 2048 (0x800) bytes
2020-04-12T18:28:57 INFO common.c: Starting Flash write for F2/F4/L4
2020-04-12T18:28:57 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 592
2020-04-12T18:28:57 INFO common.c: Starting verification of write complete
2020-04-12T18:28:57 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1
PS C:\Users\xxx\Documents\Code\Test>

Expected/description:

Should flash the hex file without errors

buneeds-fix componenst-flash needinvestigation owindows programmestlinkv2 targestm32l4

All 12 comments

Who can take a closer look at this?

I suggest a check with the same board and other flash tools so that we can confirm this is not a hardware problem.
The verification failed at the very beginning so if it is not a hardware problem, there might be some problems in flashloaders. Unfortunately error code check in flashloaders (if possible) is not applied on most models. I would suggest print out all register values after the failed flash, with st-util and (gdb or lldb).

I tried with both, a genuine st link v2 and one of those cheap copies from china. It fails on both. I will look at the registers later when i have some more time.

The "flash tools" I mentioned refers to openocd or the official tools by ST. Sorry for the ambiguous expression. When you check the register values, it would be better to print out STM32_FLASH_SR register value, located in STM32_FLASH_REGS_BASE + 0x10. STM32_FLASH_REGS_BASE is 0x40022000 on STM32L4.

Sorry for replying so late.
I tried to flash a few different hex files of different sizes, st-flash successfully erases the the needed pages (verified by examining memory content with st link utility), but fails to flash as i said in initial post.
Flash is successful when flashing the hex with st link utility or the corresponding dfu with the st dfu tool, so i'd say that it's not a hardware issue.

Here is what STM32_FLASH_SR reads:
grafik

The clue is that FLASH_SR shows PGSERR and PGAERR are set, that is, there are some alignment issues. If you can provide the general purpose register values after a failed programming (with gdb, info registers without reseting the board before attaching) and launch st-flash with --debug on, I think we will be able to further investigate with debug log and register values.

Edit: Would be better if you can provide STM32_FLASH_SR original value before flashing.

grafik

these are the registers after failed flash (connected without reset).

Here the output with --debug set:
log.txt

@lulle2007200 in the mail I received you said that with —debug it flashes without error. I noticed that you edited it.
Was there indeed a successful flashing, with debug on?

If so, it may be a timing problem, just like that of f0 series.

From the log, things seem to be fine before running. the general purpose registers hold values that are hard to explain. If r0 was zero at the very beginning, maybe some issues with functions that write values to registers?

It didnt work, i messed up while trying to redirect output of st-flash to file. turned out it didnt run at all, but i had flashed it before using st link utilty...
Also, i hit close and comment instead of comment by accident, sorry for the confusion.
I will take another look tomorrow.

@lulle2007200: Any update on this?

I kind of forgot about this, life got in the way.
st-flash fails to erase and flash the provided hex file.
I multiple files of different sizes, doesn't work with any of them. Note that flashing those with the official ST-Link Utility works perfectly fine.
I have attached a log of the st-flash output and the values of the general purpose registers and STM32_FLASH_SR, both, before and after the flash attempt.
log.txt
Regs

Now we are looking for a skilled developer who his somehow familiar with the L4 series to have the chance for a fix.

Was this page helpful?
0 / 5 - 0 ratings