2

I am looking for a command line tool for flashing my NUCLEO card in ubuntu. I want this tools for flash my NUCLEO remotely with node.js. I already try st-flash and stm32flash but these tools don't work properly. My programs are generated by mbed online tool.

Do you have any suggestions ?

Thanks for your answers

Tanguy Hardelin
  • 71
  • 1
  • 4
  • The tools you mentioned *do* work properly, but like any tool must be used correctly. Questions seeking recommendations are off topic, while to receive help with a particular tool you must include the exact details of the attempt and the resulting failure message. – Chris Stratton Dec 03 '19 at 15:40
  • @ChrisStratton it remains an X-Y problem in that case. The question should be about making these tools work rather than canvassing for yet more alternatives. I still think the reason these tools don't work may have the same cause as the drag n drop method failure – Clifford Dec 03 '19 at 17:32
  • A search for options is certainly off-topic. But with the exception of things like a bad USB cable the failure of assorted stlink or virtual serial based tools is typically one of misuse, and so unrelated to the fairly routine failure of the cheesy fake mass storage mechanism to fool the filesystem code of assorted host operating systems. I would agree that there is presently no appropriate, answerable question on this page. – Chris Stratton Dec 03 '19 at 17:36
  • FWIW I personally use OpenOCD for this though initially used texane/stlink (ie st-flash) but then I am generally working on custom boards. When I need to use a Nucleo instead it's just a matter of telling openocd to expect their slightly different stlink protocol version and VID/PID. I tend to use the UART bootloader approach only in a situation such as an embedded Linux system needing to update a helper MCU contained in the same product. But these are personal choices. – Chris Stratton Dec 03 '19 at 19:17

1 Answers1

0

You can update Nucleo boards simply by copying the mbed image to the mass storage device presented when you connect to the composite USB interface.

The image file is automatically written to the microcontroller flash by the integrated STLink device when the file is placed on the USB drive. This is a "write-only" device; the written file cannot be read back - if you interrogate the drive it always appears empty.

In Ubuntu you may have to explicitly mount the device. If it mounts automatically it will appear under /mnt (I guess).

Since it is a standard USB mass storage interface, you should not need any Nucleo or ST specific driver or software. It is a "drag & drop" programming interface.

If your board does not appear as a mass storage device, you may need to update the integrated STLink firmware as described at https://os.mbed.com/teams/ST-Americas-mbed-Team/wiki/Preparing-the-STM32-Nucleo-Board

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Thanks for your quick response ! :) Yes I currently do that but the problem is after several flash my nucleo card seem like 'corrupted'. When my card is 'corrupted' I can't flash anymore and I have to reflash the nucleo firmware with STCubeProgrammer :/ – Tanguy Hardelin Dec 03 '19 at 12:58
  • @TanguyHardelin : Then this is an [X-Y problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). You should solve the problem of the documented means of flashing not working rather than inventing a new problem then solving that! Possibly your application is somehow inadvertently blocking the SWI / JTAG or setting RDP perhaps? Either way, just programming it in a different way is unlikely to be the solution you assume it is. – Clifford Dec 03 '19 at 13:51
  • This is really not the best mechanism, it is notoriously problematic and most serious users will end up configuring their systems to not mount this fake mass storage device but rather interact with the stlink functionality. That said, if you luck out in the interaction between the fakery and the behavior of the host OS, *when* it works it works. – Chris Stratton Dec 03 '19 at 15:43
  • I'm going to guess the "corrupted" refers to the target STM32's somewhat notorious habit of getting into a flash locked state all by itself. Typically this requires an unlock/mass erase and true pull-all-cables-out power cycle. The other possibility would be an SWD-pins disabled state, recoverable by a careful dance of asserting hardware reset during connection or temporarily switching the boot mode pin to bootloader to stop bad firmware from starting up and reconfiguring the needed pins. – Chris Stratton Dec 03 '19 at 19:31