PlatformIO Community

Mbed framework for STM32F407VE (192k RAM. 512k Flash)

STM32F407VE (192k RAM. 512k Flash) is not supported by mbed framework, however a similar board (Seeed Arch Max) with the same microcontroller (STM32F407VET6) has mbed framework.

I tried to upload the compiled Seeed Arch Max code onto STM32F407VE, but could not get through. I then manually uploaded the firmware.bin file using st-link utility and the code worked as expected.

Here is the error message from pio.
NU MCU Eclipse OpenOCD, 64-bitOpen On-Chip Debugger 0.10.0+dev-00593-g23ad80df4 (2019-04-22-20:25)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 1
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
adapter speed: 2000 kHz
Error: timed out while waiting for target halted
TARGET: stm32f4x.cpu - Not halted
in procedure ‘program’

embedded:startup.tcl:479: Error: ** Unable to reset target **
in procedure ‘program’
in procedure ‘program_error’ called at file “embedded:startup.tcl”, line 504
at file “embedded:startup.tcl”, line 479
*** [upload] Error 1

Is it possible to solve this upload issue and enable mbed for STM32F407VE?

The problem seems to lie in the reset_config method used in the openOCD configuration. Do you have the NRST signal of your ST-LinkV2 connected to the target board, as a start? If yes, you might have to play around with the used cfg file in <user home directory>/.platformio/packages/tool-openocd/scripts/target/stm32f4x.cfg regarding reset_config.

There’s also the possibility of flashing a different firmware to your ST-Linkv2 to enable the virtual hard disk / thumb drive feature which would enable uploading via the upload_protocol = mbed method. (st software).

No, NRST was not connected. Will try that and look at reset_config.

For mbed framework, is it possible to use st-link as upload_protocol? The error message in my earlier post was generated by setting upload_protocol = stlink.

Yes absolutely, the upload methods are always independent of the used framework. You can also upload a Arduino firmware via the mbed disk upload if the st-link would expose such an interface.

Since upload methods do not depend on frameworks, if st-link V2 works under one framework, it should also work under others. I tested the board using arduino framework with upload_protocol = stlink. There was no issue at all. In that case, NRST was not connected either.

So I reason without changing anything the same setup should also work under mbed, but it didn’t.

Not necessarily, since the running firmware on the microcontroller can e.g. switch off things like the ability to live-debug or do low-power debugging. See DBGMCU control register: https://os.mbed.com/users/EricLew/code/STM32L4xx_HAL_Driver/docs/tip/group__SYSTEM__LL__EF__DBGMCU.html or here p. 1702 following.

So, doing a software-reset via the SWD might fail for some firmwares which do not configure this. That’s why there’s a hardware reset NRST.

Thanks a lot for your explanation! Will check out NRST later.

Connected RST (st-link) to TRST/RESET(JTAG socket). As I have no knowledge on openocd, so I just randomly tested some options for reset_config. Unfortunately, none has worked.

Could you try each of the following options

reset_config srst_nogate
reset_config srst_only
reset_config trst_only
reset_config srst_only srst_nogate
reset_config none
reset_config trst_and_srst

Tried all with the latest st-link v2 firmware, same error, no success.

What options do you use for uploading the firmware.bin through the ST-Link utility? (Connect under reset / Software reset etc)

I used the default option for reset mode which is hardware reset.