STM32F401 Nucleo-64 no longer programmable (Regression)

[Quadricopter]

Since commit 7651d21, I cannot flash my Nucleo-64 anymore :-(

> st-flash write nucleo.bin 0x8000000
st-flash 1.5.1-12-g30de1b3-dirty
2019-01-28T14:03:16 INFO common.c: Loading device parameters....
2019-01-28T14:03:16 INFO common.c: Device connected is: F4 device (Dynamic Efficency), id 0x10016433
2019-01-28T14:03:16 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 16384 bytes
2019-01-28T14:03:16 INFO common.c: Attempting to write 4020 (0xfb4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2019-01-28T14:03:16 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2019-01-28T14:03:16 INFO common.c: Starting Flash write for F2/F4/L4
2019-01-28T14:03:16 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 4020
2019-01-28T14:03:19 ERROR flash_loader.c: flash loader run error
2019-01-28T14:03:19 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
Makefile:44: recipe for target 'flash' failed
make: *** [flash] Error 255

Comment following line makes st-flash work again with Nucleo-64
https://github.com/texane/stlink/blob/30de1b30e7a96974ae764d0508c151eadb1addd1/src/flash_loader.c#L265

> lsusb
Bus 001 Device 024: ID 0483:374b STMicroelectronics ST-LINK/V2.1 (Nucleo-F103RB)

[dhylands]

I can confirm this. And I must apologize. I think my earlier claims on another thread about things working were almost certainly incorrect. Now that I'm executing the st-flash that was actually built I can reproduce this and I threw in a couple of prints to help figure out what's going on.

On the Nucleo-F401RE, sl->core_id is coming out as 0x2ba01477 and CS32_CORE_ID is also 0x2ba01477 so the stlink_flash_loader_write_to_sram routine/
is incorrectly picking the stm32vl flash loader rather then the stm32f4 flash loader.

The datasheets suggests that the JTAG core id for the F401 should be 0x4ba01477

Unfortunately, I don't have an stm32vl part to see if there is a way around this problem. I noticed that src/common.c uses a different set of tests (based on sl->flash_type) to report the type of flash being used. Perhaps stlink_flash_loader_write_to_sram needs to also use sl->flash_type ?

[Nightwalker-87]

Fixed in the following commits:
1st fix: 3295ab4, 2nd fix: f5d0454 (master-branch) and b40c243 (develop-branch) .

[Quadricopter]

Hello,

tested with master branch ( commit: f5d0454 )
NUCLEO-F401RE
It's OK for me!

st-flash write nucleo.bin 0x8000000
st-flash 1.6.0-31-gf5d0454
2020-03-24T19:46:31 INFO common.c: Loading device parameters....
2020-03-24T19:46:31 INFO common.c: Device connected is: F4 device (Dynamic Efficency), id 0x10016433
2020-03-24T19:46:31 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 16384 bytes
2020-03-24T19:46:31 INFO common.c: Attempting to write 12368 (0x3050) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-03-24T19:46:32 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2020-03-24T19:46:32 INFO common.c: Starting Flash write for F2/F4/L4
2020-03-24T19:46:32 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 12368
2020-03-24T19:46:32 INFO common.c: Starting verification of write complete
2020-03-24T19:46:32 INFO common.c: Flash written and verified! jolly good!