How to build mbed-OS (debug) for Portenta H7

Official Hardware Portenta Family Portenta H7
1

I need to debug mbed-OS because a QSPI tutorial sample is not working. Does anybody know how to do this in a way that does not require me to install all the mbed-OS tools?

I noticed that you can simply copy the source files into the installation tree and Arduino will indeed start compiling mbed-OS source code albeit with errors. For success you first need to delete all the irrelevant build targets, but in the end, errors remain. I used the source code from the arduino mbed-OS github repository at GitHub - arduino/mbed-os: Arm Mbed OS is a platform operating system designed for the internet of things .

I use an Eclipse makefile project to build a version that lets me debug the source code. It uses the same commands as the Arduino IDE and lets me clean the file caches manually. Unfortunately it is Os-optimized code, but the debugging works well enough to get by.

Meanwhile I will keep plugging away, deleting files that I think may not be relevant for what I need. If there is any documentation for doing what I want, please let me know.

2

I have a similar question a few questions down on the forum (no answers yet).

https://forum.arduino.cc/t/compile-a-new-libmbed-a-file/1025085)

Basically I want to recompile mbed, and generate a new libmbed.a file (you can enable debug with the -g flag as per this help file

https://github.com/arduino/ArduinoCore-mbed#readme)

I have not been able to get the compile to work though - either through windows, or a linux shell on windows.

If you figure out how to do complete the compile successfully, let me know (arduino support hasnot been too forthcoming with suggestions either).

Thanks

3

Thanks for the link! I missed that directory altogether, and that's probably the right way to do it.

Meanwhile I am debugging a select set of mbed-os files. The way I did it is as follows:

  1. Copy the source files that you want to debug into the mbed tree of the installation (under AppData/Local/Arduino15/.... (etcetera)
  2. Define any macros that are missing when building in the Arduino GUI. I looked some up on the mbed-os website.
  3. Once the select set of libmbed.a files compile succesfully, you will get build errors due to duplicates.
  4. Use the toolchain's ar command to delete those modules from libmbed.a. Before doing this, make a backup copy, of course.
  5. Complete the Arduino build. It should now build.

Once it builds from Arduino I continued with my Eclipse makefile project that is based on their builder tool commands. In the debug configuration for this project, add the source directories that have those files. Then, debug.

For those interested in using Eclipse for debugging: My Eclipse project was created in STM32CubeIDE. When selecting the toolchain, choose the specific STM one (called ARM-GCC-GNU or something like that). This will add some needed include paths. Add more as needed. Create a build and cache folder and use a makefile that looks something like this:

HERE := .
BUILD := $(HERE)/build
CACHE := $(HERE)/cache
ARDUINO15 := C:/Users/Henk/AppData/Local/Arduino15
PACKAGES := $(ARDUINO15)/packages
TOOLS := $(PACKAGES)/arduino/tools
LIBRARIES := $(ARDUINO15)/libraries
BUILDER_OPTIONS := -logger=machine \
		-hardware "C:/Program Files (x86)/Arduino/hardware" \
		-hardware $(PACKAGES) \
		-tools "C:/Program Files (x86)/Arduino/tools-builder" \
		-tools "C:/Program Files (x86)/Arduino/hardware/tools/avr" \
		-tools $(PACKAGES) \
		-built-in-libraries "C:/Program Files (x86)/Arduino/libraries" \
		-libraries $(LIBRARIES) \
		-fqbn=arduino:mbed_portenta:envie_m7:split=100_0,security=none \
		-ide-version=10816 -build-path $(BUILD) -warnings=none -build-cache $(CACHE) \
		-prefs=build.warn_data_percentage=75 \
		-prefs=runtime.tools.arm-none-eabi-gcc.path=$(TOOLS)/arm-none-eabi-gcc/7-2017q4 \
		-prefs=runtime.tools.arm-none-eabi-gcc-7-2017q4.path=$(TOOLS)/arm-none-eabi-gcc/7-2017q4 \
		-prefs=runtime.tools.dfu-util.path=$(TOOLS)/dfu-util/0.10.0-arduino1 \
		-prefs=runtime.tools.dfu-util-0.10.0-arduino1.path=$(TOOLS)/dfu-util/0.10.0-arduino1 \
		-prefs=runtime.tools.openocd.path=$(TOOLS)/openocd/0.11.0-arduino2 \
		-prefs=runtime.tools.openocd-0.11.0-arduino2.path=$(TOOLS)/openocd/0.11.0-arduino2 \
		-prefs=runtime.tools.imgtool.path=$(TOOLS)/imgtool/1.8.0-arduino \
		-prefs=runtime.tools.imgtool-1.8.0-arduino.path=$(TOOLS)/imgtool/1.8.0-arduino \
		-verbose

all : 
	"C:/Program Files (x86)/Arduino/arduino-builder" -dump-prefs $(BUILDER_OPTIONS) $(HERE)/src/stm32bsp.ino
	"C:/Program Files (x86)/Arduino/arduino-builder" -compile $(BUILDER_OPTIONS) $(HERE)/src/stm32bsp.ino

Then, add an STM32 debug configuration for it. It will require you to select a target. Once that is done you can use it to debug. I do have to click the Portenta buttons here and there to get it in run mode while starting a debug session. Sorry I'm not more precise but HTH.

4

I thought the compiling is done outside of arduino IDE, in order to recompile, and create a new libmbed.a file.

Once that file is created, it would then be brought over into your Arduino15.. folder.

Is that not the case - or have I been looking at it wrong all along.

5

I ignored the ArduinoCore-mbed instructions (because I did not notice them) and simply tried putting a file in the Arduino mbed directory - it will be compiled and eventually added to core.a in the cache file directory. (You can tell because there is only one source file mstd_mutex.cpp in the Arduino mbed tree installation, and it also shows up in core.a - that's how I noticed it.) The linker will then detect that libmbed.a and core.a have duplicate modules. So then when you remove those duplicates from libmbed.a (after making a backup), the build will succeed.

6

In my case, I was told to recomipile libmbed.a, in order to make some changes that are requested in the mbed_app.json file (decreaase main stack size, add more lwip sockets, and increase the lwip-thread stack size - as it hits the maximum 1200 in my case immediately).

In addition, the new variants have the code for the support of the external 32.768 kHz oscillator (which is disabled in the default configuration - and the internal 32kHz oscillator is used - off by 1 second every 60 seconds). Apparently rev A of the Portenta board was wired wrong, so it was disabled, and has not been enabled since (you would think they would simply look at the board version - or see if the clock oscillates, and enable the right source).

It is less of a debugging issue as opposed to getting above features available or enabled.

So, I am more looking for a way to compile the whole thing into a new libmbed.a file.