search

stlink-org / stlink

Open source STM32 MCU programming toolset
BSD 3-Clause "New" or "Revised" License
4.34k stars 1.23k forks source link

Attempting to flash to STM32L052K8 corrupts flash memory #681

Closed WRansohoff closed 1 year ago

WRansohoff commented 6 years ago

Attempting to flash a .elf to the chip results in a series of errors indicating an STM32L1 loader is being used (quoted further down), and subsequent connections fail with the following strange error message:

2018-03-08T23:04:41 WARN common.c: Invalid flash type, please check device declaration
2018-03-08T23:04:41 INFO gdb-server.c: Chip ID is 00000000, Core ID is  0bc11477.

That state persists until the chip is 'fixed' by connecting to it during a hardware reset via ST's ST-Link Utility on a Windows machine. Here is the output that st-util gives during the problematic flashing operation:

st-util 1.5.0
2018-03-08T23:04:03 INFO usb.c: -- exit_dfu_mode
2018-03-08T23:04:03 INFO common.c: Loading device parameters....
2018-03-08T23:04:03 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-03-08T23:04:03 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-03-08T23:04:03 INFO gdb-server.c: Chip ID is 00000417, Core ID is  0bc11477.
2018-03-08T23:04:03 INFO gdb-server.c: Listening at *:4242...
2018-03-08T23:04:13 INFO gdb-server.c: Found 4 hw breakpoint registers
2018-03-08T23:04:13 INFO gdb-server.c: GDB connected.
2018-03-08T23:04:14 INFO common.c: Attempting to write 128 (0x80) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2018-03-08T23:04:14 INFO common.c: Finished erasing 1 pages of 128 (0x80) bytes
2018-03-08T23:04:14 INFO common.c: Starting Half page flash write for STM32L core id
2018-03-08T23:04:14 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-03-08T23:04:17 ERROR flash_loader.c: flash loader run error
2018-03-08T23:04:17 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-03-08T23:04:17 WARN common.c: 
write_half_pages failed == -1
  0/  1 pages written
2018-03-08T23:04:17 INFO common.c: Starting verification of write complete
2018-03-08T23:04:17 INFO common.c: Flash written and verified! jolly good!
2018-03-08T23:04:17 INFO common.c: Attempting to write 128 (0x80) bytes to stm32 address: 134217856 (0x8000080)
Flash page at addr: 0x08000080 erased
2018-03-08T23:04:17 INFO common.c: Finished erasing 1 pages of 128 (0x80) bytes
2018-03-08T23:04:17 INFO common.c: Starting Half page flash write for STM32L core id
2018-03-08T23:04:17 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-03-08T23:04:20 ERROR flash_loader.c: flash loader run error
2018-03-08T23:04:20 WARN common.c: l1_stlink_flash_loader_run(0x8000080) failed! == -1
2018-03-08T23:04:20 WARN common.c: 
write_half_pages failed == -1
  0/  1 pages written
2018-03-08T23:04:21 INFO common.c: Starting verification of write complete
2018-03-08T23:04:21 INFO common.c: Flash written and verified! jolly good!
[ ... repeats a few times ... ]

Expected/description: The program should flash susccessfully. But despite reporting success, when I try to step through it in GDB, the chip jumps directly from the reset location to 0x20000010. So I gotta figure that something went wrong somewhere.

Nightwalker-87 commented 1 year ago

@Mk-arc Thanks, we are making progress. :ok_hand: Let me analyse the remaining inconsistency.

Could you re-run the above with the --debug option? You can either clip the lengthy output or use pastebin.com. As there is only a temporary need, you may also set an expiry date.

Nightwalker-87 commented 1 year ago

We're looking at common.c L811ff now:

int32_t write_buffer_to_sram(stlink_t *sl, flash_loader_t *fl, const uint8_t *buf, uint32_t size) {
  // write the buffer right after the loader
  int32_t ret = 0;
  uint32_t chunk = size & ~0x3;
  uint32_t rem = size & 0x3;

  if (chunk) {
    memcpy(sl->q_buf, buf, chunk);
    ret = stlink_write_mem32(sl, fl->buf_addr, (uint16_t)chunk);
  }

  if (rem && !ret) {
    memcpy(sl->q_buf, buf + chunk, rem);
    ret = stlink_write_mem8(sl, (fl->buf_addr) + chunk, (uint16_t)rem);
  }

  return (ret);
}

...asking ourselves under which circumstances this function would return an error: ret == -1 :thinking:

... which is the case for (read_write.c L49ff):

int32_t stlink_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {
  DLOG("*** stlink_write_mem32 %u bytes to %#x\n", len, addr);

  if (len % 4 != 0) {
    ELOG("Data length doesn't have a 32 bit alignment: +%d byte.\n", len % 4);
    return (-1);
  }

  return (sl->backend->write_mem32(sl, addr, len));
}

@Ant-ON is this really a bug? What's your say on this implementation/handling? The ELOG message did not show up in the output above though, so there must be a different cause.

mynameisdaniil commented 1 year ago

@Nightwalker-87 just tested current testing branch (8fad9be9d0b055069b3f4fcdc3dc17014a6ce9cb) and develop (d4b53b06b6ed8906798201ece463ffd2704051ef). Release bulds on linux@amd64, libusb 1.0.23. STM32L152CCT (detected as STM32L0xxx_Cat_3) onboard stlink V2J21S5 (stm32l0538-disco board). I was unable to successfully flash this chip.

st-flash 1.7.0-294-gd4b53b0
2023-06-28T01:34:01 INFO common.c: STM32L0xxx_Cat_3: 8 KiB SRAM, 64 KiB flash in at least 128 byte pages.
file ./firmware.bin md5 checksum: 637a2ffa8845e9c902741fcb869ac4b, stlink checksum: 0x000f74f0
2023-06-28T01:34:01 INFO common_flash.c: Attempting to write 10728 (0x29e8) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8002980 erased (size: 0x80)
2023-06-28T01:34:02 INFO flash_loader.c: Starting Flash write for L0
2023-06-28T01:34:02 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-06-28T01:34:02 INFO flash_loader.c: Clear DFSR
2023-06-28T01:34:02 ERROR flash_loader.c: Flash loader run error
2023-06-28T01:34:02 WARN flash_loader.c: Loader state: R2 0x21000003 R15 0x21000003
2023-06-28T01:34:02 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2023-06-28T01:34:02 WARN flash_loader.c: Failed to use flash loader, fallback to soft write
167/167 halfpages written
2023-06-28T01:34:03 ERROR common_flash.c: Invalid flash address
stlink_fwrite_flash() == -1

And here's full debug output: https://pastebin.com/5NP1Q6Te

BTW I've noticed that you've dropped support for Mac OS, is there an objective reason? Would you mind a pull request that brings it back? Mac is my main machine for the time being and it would be nice if I can use stlink without VM.

UPD: I have two of this boards. And another one produces different error:

2023-06-28T01:42:21 INFO common.c: STM32L0xxx_Cat_3: 8 KiB SRAM, 64 KiB flash in at least 128 byte pages.
file ./firmware.bin md5 checksum: 637a2ffa8845e9c902741fcb869ac4b, stlink checksum: 0x000f74f0
2023-06-28T01:42:21 INFO common_flash.c: Attempting to write 10728 (0x29e8) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8002980 erased (size: 0x80)
2023-06-28T01:42:22 INFO flash_loader.c: Starting Flash write for L0
2023-06-28T01:42:22 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-06-28T01:42:22 INFO flash_loader.c: Clear DFSR
2023-06-28T01:42:23 ERROR flash_loader.c: Flash loader run error
2023-06-28T01:42:23 WARN flash_loader.c: Loader state: R2 0x16FEF800 R15 0x0
2023-06-28T01:42:23 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2023-06-28T01:42:23 WARN flash_loader.c: Failed to use flash loader, fallback to soft write
167/167 halfpages written
2023-06-28T01:42:23 ERROR common_flash.c: Flash memory contains a non-erased value
2023-06-28T01:42:23 INFO common.c: Go to Thumb mode
stlink_fwrite_flash() == -1

(https://pastebin.com/suG0ybvc)

UPD2: Debug build gives ERROR common_flash.c: Invalid flash address for both boards.

eschoker commented 1 year ago

@mynameisdaniil same issue here. I was running into another one all day. After cleaning everyone and re cloning the current main repo I run to

2023-07-19T15:57:19 ERROR common_flash.c: Invalid flash address
2023-07-19T15:57:19 INFO common.c: Go to Thumb mode
stlink_fwrite_flash() == -1

I have tested on only one board so far the Nucleo-L031K6. Below is the full output

st-flash --reset write build/stm32l0xxTemplate.bin 0x8000000
st-flash 1.7.0-296-gf7fb0a6
2023-07-19T15:57:19 INFO common.c: STM32L0xxx_Cat_2: 8 KiB SRAM, 32 KiB flash in at least 128 byte pages.
file build/stm32l0xxTemplate.bin md5 checksum: efc4df8973afd432b9aebe6cd4dd143, stlink checksum: 0x0006ff84
2023-07-19T15:57:19 INFO common_flash.c: Attempting to write 5212 (0x145c) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8001400 erased (size: 0x80)
2023-07-19T15:57:19 INFO flash_loader.c: Starting Flash write for L0
2023-07-19T15:57:19 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-07-19T15:57:19 INFO flash_loader.c: Clear DFSR
2023-07-19T15:57:19 ERROR flash_loader.c: Flash loader run error
2023-07-19T15:57:19 WARN flash_loader.c: Loader state: R2 0xB8548D00 R15 0x55F7
2023-07-19T15:57:19 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2023-07-19T15:57:19 WARN flash_loader.c: Failed to use flash loader, fallback to soft write
 81/ 81 halfpages written
2023-07-19T15:57:19 ERROR common_flash.c: Invalid flash address
2023-07-19T15:57:19 INFO common.c: Go to Thumb mode
stlink_fwrite_flash() == -1
chrisgjohnson commented 1 year ago

On my Nucleo-L031K6 I have similar problems from the latest testing commit:

2023-07-27T01:12:39 INFO common.c: STM32L0xxx_Cat_2: 8 KiB SRAM, 32 KiB flash in at least 128 byte pages.
file /home/chris/projects/stm32/own/wireless_thermometer_receiver/main.bin md5 checksum: 135fd01736fa864fc8c4b7f5f2d5119, stlink checksum: 0x002a15e7
2023-07-27T01:12:39 INFO common_flash.c: Attempting to write 31664 (0x7bb0) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8007b80 erased (size: 0x80)
2023-07-27T01:12:41 INFO flash_loader.c: Starting Flash write for L0
2023-07-27T01:12:41 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-07-27T01:12:41 INFO flash_loader.c: Clear DFSR
2023-07-27T01:12:41 ERROR flash_loader.c: Flash loader run error
2023-07-27T01:12:41 WARN flash_loader.c: Loader state: R2 0x41000003 R15 0x41000003
2023-07-27T01:12:41 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2023-07-27T01:12:41 WARN flash_loader.c: Failed to use flash loader, fallback to soft write
494/494 halfpages written
2023-07-27T01:12:43 ERROR common_flash.c: Flash memory contains a non-erased value
stlink_fwrite_flash() == -1

This file is flashed successfully on the same hardware with st-flash 1.6.0

Nightwalker-87 commented 1 year ago

@chrisgjohnson The codebase has undergone major and very useful refactoring work with lots of improvements and fixes since then. Thus there can be no easy rollback to the previous state. Also by then there were some obscure implementations without any (proper) documentation on their functionality. This is why some users have taken action and have rewritten some parts of the code for flashing. As to my knowledge however a coexistence of old and new sections remain up to the latest state.

Thus one would need to debug the latest code likely without any comparison to the previous state.