Closed WRansohoff closed 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.
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.
@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.
@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
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
@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.
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:
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:
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.