mBed port to M33 Cortex

Mbed OS Best practice
1

Hello,

We are looking at using the Nordic Semi nRF5340 part. We are currently running on the nRF52840 part. Is there a porting guide available and/or, does anyone have experience porting to the M33 core ?

Thx,

Aidan

2

Hi Aiden,

(FYI not an ARM guy, just a fellow engineer :slight_smile: I haven’t ported nRF parts specifically, but I have ported other parts. When the vendor has an SDK for the part you’re interested in, the port is pretty easy, but you just have to understand the mbed internals and how the exporter and compiler picks the right files for the right target.

I wrote this guide for my company as a supplement to this doc from mbed: https://os.mbed.com/docs/mbed-os/v6.2/porting/porting-custom-boards.html

Now, they talk about some custom_boards.json file, and I’ve never gotten that to work. I just modify mbed’s targets.json directly to add my target.

My guide speaks to porting a Kinetis part, but the idea is similar. Since there’re already nordic parts in mbed, it’s very easy to add a folder with any extra code you need for the nRF5340 (or the code might already be in there and you just have to get the right macros picked out!) Here’s the guide:
“”"
So, starting with adding a new part to the targets.json file
 (If you don’t know what that means,read the porting guide​) The thing they don’t mention is that “extra_labels” are parsed top to bottom, and it looks recursively. So if you look at, for instance,

MCU_K22F512, then you can traverse the directory structure under “targets” in mbed-os ( the TARGET_ part is left out of the json keys ) as follows:

“Freescale”, ← adds just the mbed_rtx.h header, note all the other folders under TARGET_Freescale aren’t added ( yet ) b/c those folders start with TARGET_.

“MCUXpresso_MCUS”, ← this folder is NOW available for adding b/c the previous line added a folder that contains it. If you were to swap the two entries above, it would not work.The TARGET_MCUXpresso_MCUS folder adds a top layer of “generic” code that all the folders below will share. api folder has the mapping from mbed HAL to Kinetis SDK HAL for most drivers. Some other drivers are done farther down the hierarchy. Meaning each folder below will have to have its own copy of any file missing at this level. Example: serial.c"

KSDK2_MCUS", ← I think this is legacy, ignore

“MCU_K22F”, ← Next level. Here you see serial, spi, us_ticker
and these drivers are SPECIFIC to K22F. Also, you see a folder called drivers. Here is the meat of the driver layer. They’ve basically copied the Kinetis SDK folder called “drivers” into here. They all start with “fsl_” The mbed HAL files ( ex serial.c ) simply provide glue logic into the Kinetis HAL drivers. You can download this “drivers” folder from NXP ( alongside some other folders you won’t need )

“MCU_K22F512”, < even more specific. The main thing you find here is “fsl_device_registers.h” and some other h files that define the processor specific register map, defining symbols that the Kinetis SDK understands

“FRDM”, < now we’ve gone beyond processor specific to actual BOARD specific. Hence, all you see here is a pin map ( stuff like SD_SPI_OUT, etc ), and some clock management ( b/c each board clock file has to be tweaked based on what kind of crystal is on the board to provide a time base )

And that’s it
you start with generic files, and any c files they can get away with writing once for ALL processors. Then it gets more specific
what can they write that will work for all K22’s. Finally, you get to the specific flavor of K22, and you end up with a dumping ground for pretty much the entire Kinetis SDK, as generated BY NXP FOR that SPECIFIC processor. Finally, folders are added to support a specific board

Roughly, the layers are like so, but just remember, THE directories DON’T exactly match this hierarchy
but the c files that are ultimately included DO:

mbed-hal
Kinetis SDK
Processor specific register map files
Board specific pin maps and clock stuff

So then, how to port? Roughly


Add to the targets.json file. Don’t forget to choose the correct macros for the FSL ( see a “cousin” chip for an example )
Go to NXP and download the Kinetis SDK for your specific processor. Keep the folder handy, but out of the mbed tree for now. You’ll want to copy things in piecemeal.
Find out the “least common denominator” between your proc and an mbed supported one. For my case, I added code starting at the TARGET_MCU_K22F level, so I was able to not have to write any new mbed_hal stuff
the existing HAL code works because the Kinetis SDK has the same function names across processors
just different guts based on the specific part you picked when you downloaded the Kinetis SDK from NXP
Files of note: cmsis_nvic and cmsis aren’t from the Kinetis SDK. You can copy them from another TARGET, but you MUST change the number of interrupt vectors to the correct one based on your proc
TOOLCHAIN: You can start with files provided via the Kinetis SDK. Pick the right toolchain when you download, and you’ll get what you need. Now, mbed adds some special sauce to these files ( I think to support their bootloader? )
so you’ll want to look at a similar file from another TARGET already in mbed, and kind of merge what you get from Kinetis SDK with what mbed. The design pattern was fairly obvious, they’re just adding an extra section to the linker file
.s file stays more or less the same
.icf file needs the extra bootloader? related section
​Additional IAR steps: Add correct key value pair to iar_definitions.​json
Add your own Pinmap, clock files, etc, by copying from another TARGET and using it as a template. You’ll be changing those files to match your specific board.
​The kinetis clock config tool ( MCUXpresso Config Tools ) is very useful. It will generate clock_config .h/.c for you based on your board and desired clock rates. Rename those files to fsl_clock_config.h ( b/c the rest of the API is going to be looking to include “fsl_clock_config.h” ) These files will live at your “board” level TARGET_ folder ( the bottom most folder in the hierarchy )
Also to note about that tool
the “auto” divider calculation didn’t really work for me. Kept yelling about conflicting constraints. I ended up just manually calculating all the dividers and such
but the GUI, rules checking, and code gen is still definitely worth it

1 Like
3

Hello Alex,

Thanks for taking the time to reply and the detailed answer. I will dig into the detail you provided and take a look at the NXP m33 SDK.

Aidan

4

Hi Aidan,

Did you manage to get the nRF5340 up and running with Mbed OS? We are also looking into doing the porting now.

Thanks a lot in advance.

Kind regards,
Jeppe