Firmware Updating for Portenta H7

I am currently working on a project with the Arduino Portenta H7 and I am looking for a solution to update my micropython firmware , I found some like the OTA solution or updating the bootloader that seems not a good fit for me, that's why I have came to you hoping you help me with some hints to fulfil my project .

Any guidance or insight/direction would be much appreciated.

The Arduino page has a "Contact Us" link:
https://www.arduino.cc/en/Main/ContactUs

Not familiar with MicroPython env.
But usually:

  • you press reset button twice - until flashing green LED (fading flashes) - P7 enters bootloader mode (via UART, see a different UART device now in Device Manager)

  • you start bootloader tool, dfu_util.exe and flash the new FW

This FW might be your MicroPython FW (as a BIN file to flash).
It would not overwrite the bootloader - you can still flash any FW, also Arduino sketches.
You can "just" overwrite the bootloader with an external debugger (ST-LINK) connected.

Thank you tjaekel for your reply ,
I think I didn´t present my problem well , I am working on a customer device , after the product is shipping to the customer and I want to update the firmware , this is my situation .

Similar to my situation (keep my clients/users updated with new FW versions).
Options:

  • Portenta H7 with the onboard Bootloader:
    via USB-C and the dfu_util.exe user can flash a new FW version

  • Arduino supports also OTA, via WiFi, I guess (never tried)

  • connect a debugger, ST-LINK, as SWD (breakout board has debug header, but not MCU module - hard to find), flash the new version with debugger (and related tool, e.g. STM32CubeProgrammer)

  • Implement and add your own bootloader, e.g. to get a new FW via UART and program it into flash (part of it)

This are solutions to update the C firmware but I am looking for updating the micropython firmware, I was thinking about freezing the python code into the micropython firmware and then compile it to get the .bin or .hex file to upload it via a debugger (ST-Link , SWD ) to the Portenta H7, I am still not sure if that could be a solution or not, what do you think ?

Your last solution I didn´t understand it well , could you explain it more please .

I do not know much Micropython but it seems that the OTA solution might be more suited for your use-case. I have tested the Arduino version.
If your board is connected to a network via Wifi or Ethernet, you can have a TCP server listening for an update order. Then the OTA library will try to fetch an update file remotely, decompress and verify it then reboot the board. The bootloader will replace the firmware and boot into the new one.

I am interested in knowing as well - I have not been able to get a concise answer from arduino support.

In my case, I would like to load a new libmbed.a file

"load a new libmbed.a file" - a LIB, e.g. this one is not loaded directly. It is part of you project, is linked at the end by your compiler (linker) and becomes part of the BIN (or ELF file), which you flash. So, updating a new version of "libmbed.a" needs to compile/create your FW image file again (after the LIB was updated/overwritten in your project).

When it comes to flashing a new generated BIN file: check the Bootloader, OTA feature or the BOOT mode on MCU, e.g. via User USB cable, to flash a newer BIN file version.

Will the linking happen automatically if I just include it in my root project directory?

There was a libmbed.a file that was modified to support the internal RTC clock, and I would like to test that.

Good question. The easiest way: find where the "old" libmbed.a file is located. I guess somewhere in your repository (the files used by the compiler, outside your project files, but all the code needed to create an executable). I guess it sits somewhere in "/user/AppData/Adruino15/...".

You could try to find also your linker settings in IDE: you might see from where the libmbed.a is used. If you have a newer version somewhere else: just change this linker path to this file.

The linker options are "-L" for the path to the location of any library file, and "-l" to specify which LIB to use (in order to resolve missing references, to take the code from lib).
If you see a "-l" (e.g. on command line log) - often some parts for file file name are omitted, e.g. a LIB has to start always with name "lib" - omitted, or the ".a" (because the file extension tells you the format and GCC might use and assume always a ".a" file (instead of ".lib" on other compilers).

Just check if you can see the log on last step, the linker step, on command line. You should see which LIB and from where it is used.
Modify the linker options and set a different path to LIB files ("-L"), or even a different LIB file to link ("-l").

But the easiest way is often to search on file system where the "old" LIB file is and overwrite it with newer version.

BUT! Be very careful, actually aware of: just updating to a newer LIB file - WITHOUT to update also all (external) H-files - can cause a lot of trouble!

If a function in LIB is changed, even the same name still, but a change on parameters, e.g.:

  • old: void function(char i);

  • new: void function(int i);

The generated code in your project, using this function is potentially wrong (wrong parameter types provided). You had to update also all the H-files which declare the interface of this new LIB version. Without updating the H-File - even it might look compile clean - it can crash!

Also: if the LIB provides a new function, e.g. you know that there is a new feature, a new function - without the related H-file - you are not able to use (not declared, not known, that there is a new function in LIB now).

An update of a LIB file version should come also always with an update of all the H-Files (which declare the public interface of the LIB). Do not mix old H-files with new LIB.

Hmm, I am not sure they had published the .h files.

In actual fact, I started looking for the file, and ? it was moved, as I can no longer find it in github ? so cannot confirm if the .h files were published with it.

I will search a little more.

Out of curiosity, since the libmbed.a file is 7MB long - presumably only components that are required are linked, so the actual memory use would be a small fraction of the above. Some of the function calls would be the same as the 3.2 OS that comes with the Portenta - I would guess that the newer library functions would be linked in preference?

Thanks

Found the library

ArduinoCore-mbed/variants/PORTENTA_H7_M7/libs at stm32_dynamically_switch_lptimer · facchinm/ArduinoCore-mbed (github.com)

Apparently this is the library it was compiled from

ArduinoCore-mbed/libraries at stm32_dynamically_switch_lptimer · facchinm/ArduinoCore-mbed (github.com)

Sorry, not familiar in detail with LIBs available in Internet. I tried also once to update my system for newer LIB - but a bit lost how to do.

Regarding LIB and code size:
Sure, any LIB file can be very large. But you cannot compare a LIB file size with a BIN file size (the code size you want to flash).

  1. a LIB files is a special file format with a lot of meta data: it is still relocatible code (a collection of *.o files). It has a lot of addition information, e.g. reference tables, helping code to bind later to physical addresses etc.). A LIB is always way larger as the resulting BIN file.

  2. Yes: a LIB contains ALL, but the linker will just grab what is needed to resolve external references (functions called from library). The linker just takes what is needed from LIB, not the entire LIB. At the end: you have just the code in BIN file which is really needed and used, not all the potential functions sitting in LIB file). BTW: the linker might add some more code needed, e.g. when you call a function in LIB which needs other functions in LIB - they are all taken from LIB to your BIN, but nothing which is never needed or used)

Never mind: try to update the LIB file which is used by the linker. And to make sure: update also H-files. And compile your project 'against' the updated H-files and LIB file. Then you should be fine.
Actually, you should see errors if you try to use a new function from a LIB but linker still uses the old LIB file. Based on the error messages, e.g. "missing external reference", you would know: not found in LIB. Fix issues step by step (new LIB file), update H-files.

And: you can use also the generated MAP file: it might help you to cross-check where is this function, how large is it, what else (on functions) are taken to BIN file.

Just bear in mind: it is hard to debug issues with LIB file code. Arduino seems to provide just and only "release" code versions. So, you cannot step into LIB functions, you do not see source code in LIB file (you would need a "debug" version of the LIB). It can be hard to debug a system when it crashes inside a LIB function (no insights). I recommend to figure out first if it crashes inside a LIB function. If so: check if calling the LIB function has the right "signature" (parameters), if this LIB function needs a pre-requisite configuration (e.g. when using malloc() inside LIB).
For experts, when it comes to HardFault_Handler called (e.g. by a LIB function) - there are some hooks to figure out where the original memory location was causing the trouble (but very detailed MCU register debug).

If the LIB provides now completely new functions, let's assume a new IoT protocol, services to connect to a cloud ..., and you found this single functions seems to do what you need - often, before using such a (high-level) function - it needs also a low-level initialization.
Check the API: is there an initialization needed? Does it mean the existing system has now to initialize something new/else... Just finding a new function in LIB does not mean automatically you can use it "without care".

There is this file

How to install and use a custom core version in the IDE – Arduino Help Center

Presumably I would install in a new directory beside the 3.2.0 install

C:\Users\RS\AppData\Local\Arduino15\packages\arduino\hardware\mbed_portenta

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.