Getting started with Mbed OS on MAX32630

[TijnLosekoot]

Hello,
I've been trying to get a bootloader working with Mbed OS on our MAX32630 MCU for quite a while now. We do not use the FTHR board but rather a custom PCB.
I've tried to follow @AGlass0fMilk 's demo for MCUboot but I can't get very far because he uses another board that apparently does support the FlashIAPBlockDevice class. For testing purposes I made a new, completely empty, project in Mbed OS, and made the following mbed_app.json configuration (it's pretty much a copy-paste of Glass0fMilk's work):

{
    "target_overrides": {
        "MAX32630FTHR": {
            "platform.stdio-baud-rate"          : 115200,
            "platform.stdio-buffered-serial"    : true,
            "target.device_name"                : "MAX32630",
            "target.mbed_app_start": "0x21000",
            "target.mbed_app_size": "0xBE000",
            "target.bootloader_supported": true,
            "target.c_lib": "small",
            "mcuboot.primary-slot-address": "0x20000",
            "mcuboot.slot-size": "0xC0000",
            "mcuboot.scratch-address": "0xE0000",
            "mcuboot.scratch-size": "0x20000",
            "mcuboot.max-img-sectors": "0x180",
            "mcuboot.read-granularity": 4
        }
    }
}

This throws up an error at the end of compilation, stating that the file doesn't exist when flash_map_backend.cpp attempts to include it.
I've then tried adding this to my mbed_app.json:

            "target.features_add": [
                "STORAGE"
            ],
            "target.components_add": [
                "SD",
                "FLASHIAP"
            ]

but sadly this doesn't fix it.
So then I attempted to add the whole path like so: #include "COMPONENT_FLASHIAP/include/FlashIAP/FlashIAPBlockDevice.h" in flash_map_backend.cpp.

Now the following error comes up and it's got me really stumped:

[Error] kv_config.cpp@289,12: unknown type name 'FlashIAPBlockDevice'
[Error] kv_config.cpp@1025,5: unknown type name 'FlashIAP'
[Error] kv_config.cpp@1053,78: use of undeclared identifier 'FLASHIAP_APP_ROM_END_ADDR'
[Error] kv_config.cpp@1053,29: use of undeclared identifier 'FLASHIAP_APP_ROM_END_ADDR'
[Error] kv_config.cpp@1078,5: unknown type name 'FlashIAP'
[Error] kv_config.cpp@1090,101: use of undeclared identifier 'FLASHIAP_APP_ROM_END_ADDR'
[Error] kv_config.cpp@1090,52: use of undeclared identifier 'FLASHIAP_APP_ROM_END_ADDR'
[ERROR] .\mbed-os\storage\kvstore\kv_config\source\kv_config.cpp:289:12: error: unknown type name 'FlashIAPBlockDevice'

What I'd really like to know is, is there a way to just not use the FlashIAPBlockDevice class at all? After all, it inherits from BlockDevice and the flash_map_backend.cpp file just always casts it back to the BlockDevice class.

[AGlass0fMilk]

Hi @TijnLosekoot,

Even though the MCUboot port casts the FlashIAPBlockDevice to a simple BlockDevice, this is just taking advantage of polymorphism -- you need FlashIAPBlockDevice (ie: to be able to reprogram internal program memory) to be able to do firmware updates.

If I get the time, I will see if I can get a build working for the MAX chip soon. I will not adjust the other parameters (memory addresses, etc) to make it functional, but it shouldn't be too hard to get it building at least.

You seem to be doing everything correct, so it could be something simple breaking your build.

[AGlass0fMilk]

@TijnLosekoot

Okay, I think the problem is this:

Unfortunately, the MAX32630 does not have support for internal flash reprogramming via Mbed's APIs. This is to say: the MAX32630 target does not have the following in it's mbed-os/targets/target.json entry:

...
"device_has": [
    ...
    "FLASH"
]
...

This API support is required when using the FLASHIAP driver.

I quickly adapted the similar MAX32660 flash driver implementation and got rid of most of the errors. You can check out my branch of mbed-os here:

https://github.com/AGlass0fMilk/mbed-os/tree/max32630-flash-support

You will need to check out my latest patch to MCUboot: https://github.com/AGlass0fMilk/mcuboot/tree/boot-record-add-stddef

Also check out how I modified the mbed_app.json here: https://github.com/AGlass0fMilk/mbed-mcuboot-demo/tree/max32630-support

There is still a problem though: the build compiles fine but fails at the linker stage whenever target.restrict_size is set to anything. For some reason, the MAX32630 linker script outputs multiple flash sections so the Mbed build scripts think the application is ~580kB. An analysis of a .hex file produced from the .elf build output shows the following regions:

(python3-mbed) gdbeckstein@magic-man:~/Documents/temp/mbed-mcuboot-demo$ arm-none-eabi-objcopy -O ihex BUILD/MAX32630FTHR/GCC_ARM/mbed-mcuboot-demo.elf out.hex
(python3-mbed) gdbeckstein@magic-man:~/Documents/temp/mbed-mcuboot-demo$ hexinfo.py out.hex 
- file: 'out.hex'
  entry: 0x000065B1
  data:
  - { first: 0x00000000, last: 0x0000D3D7, length: 0x0000D3D8 }
  - { first: 0x00010920, last: 0x0008BFFF, length: 0x0007B6E0 }

It seems that the first section is the actual code being generated for the bootloader (~50kB). I'm not sure what the second section is. It is over 500kB.

I have also not tested the flash API implementation (I don't have this target) so you may encounter issues there. I just used the Maxim HAL API for reprogramming flash, based on the implementation for the MAX32660 target.

At this point, I don't have time to further debug this so I would check with Maxim support to see why this section of flash is always being output by the linker script.

This gets you very close I think. I hope it helps.

[TijnLosekoot]

Thanks a lot for the quick reply and quickly trying to get a working version!
I'll be trying the changes you've made and see what might be going wrong, however I have also noticed this giant size of files before. When using the ARMC6 compiler, the file sizes are as expected, it's only when compiling with GCC_ARM that the sizes get much bigger. So thanks for analysing the file generated by compiling with GCC_ARM because I couldn't figure out why the size is so much different between the two compilers.

Is it perhaps possible to compile with ARMC6 instead as a temporary fix?
I'll be contacting Maxim support soon anyway to try and figure out why there is such a large second section.

[TijnLosekoot]

I've been able to get farther but not yet to the point of successfully building the project. Making a new project and then replacing the regular mbed-os folder with your fork. Then adding the patched mcuboot and mbed_app.json for building the bootloader (so the main.cpp is in mcu-boot/boot/main.cpp) like so:

Results in an error with python all the way at the end of compilation. It gives a bunch of warnings about the signing_keys.c and then

[mbed] ERROR: "c:\users\tijn\appdata\local\programs\python\python38\python.exe" returned error.
       Code: 1
       Path: "C:\Users\Tijn\Bootloader testing\bootloader"
       Command: "c:\users\tijn\appdata\local\programs\python\python38\python.exe -u C:\Users\Tijn\Bootloader testing\bootloader\mbed-os\tools\make.py -t GCC_ARM -m MAX32630FTHR --source . --build .\BUILD\MAX32630FTHR\GCC_ARM"

What could possibly be going wrong now?

[TijnLosekoot]

@AGlass0fMilk I've let it dry for a while, but I figured I'd just try to run it again and I should've checked better earlier. It seems the issue definitely has to do with the signing_keys.c file. There's some errors earlier too. See the output:

Using ROM regions application, post_application in this build.
  Region application: size 0x20000, offset 0x0
  Region post_application: size 0x1e0000, offset 0x20000
Compile [100.0%]: signing_keys.c
[Error] signing_keys.c@1,1: stray '\377' in program
[Error] signing_keys.c@1,2: stray '\376' in program
[Error] signing_keys.c@1,3: expected identifier or '(' before '/' token

Then it gives warnings for every null character ignored in signing_keys.c... followed by that same error again:

[mbed] ERROR: "c:\users\tijn\appdata\local\programs\python\python38\python.exe" returned error.
       Code: 1
       Command: "c:\users\tijn\appdata\local\programs\python\python38\python.exe -u C:\Users\Tijn\Bootloader testing\bootloader\mbed-os\tools\make.py -t GCC_ARM -m max32630fthr --source . --build .\BUILD\MAX32630FTHR\GCC_ARM"

So it turns out something is going wrong with Imgtool, the .c file looks fine though. I have Imgtool 1.8 (the latest version) installed and Python 3.8 on Windows 10.
The stray '\377' and '\376' errors seem to be because the signing_keys.c file has been encoded incorrectly for the compiler, source. I suspect the error following that also has to do with this.
So I'm just wondering: do you use a different setup perhaps? How could I make sure this error with Imgtool doesn't happen.

[AGlass0fMilk]

Hi @TijnLosekoot, that's a strange error. I am running on Ubuntu 20.04 using python 3.8, not doing much else. Perhaps try regenerating the signing keys if possible?

Another issue you will face is that the linker script for the MAX32630 is not setup to relocate the application based on the target.mbed_app_start and such. You will need to take a look at the approprate linker script for the toolchain you are using. I attempted to set it up for GCC in this commit here: AGlass0fMilk/mbed-os@5d8b05b#diff-ab2dbe1aded718ffd012fdbc4a003f7654d9689c0f6f87595f96afa8a24d9850R38

Specifically, see the max3263x.ld file.

If you want to try using the ARMC6 compiler, you will have to modify this file here: https://github.com/AGlass0fMilk/mbed-os/blob/max32630-flash-support/targets/TARGET_Maxim/TARGET_MAX32630/device/TOOLCHAIN_ARM_STD/MAX3263x.sct

It looks like it might already be compatible with relocating the application though... so check for that. I'm not familiar enough with the ARMC6 memory region configuration syntax.

I'm still not certain what the extra section is in the generated hex file from the GCC build. Perhaps you can try removing it with the python intelhex library and see if the application still functions properly...