Hi,
I am somewhat new to RIOT. I have used RIOT on nRF52840-dongle for now and it’s working quite well compared to my expectations and impression for other RTOSes out there.
I have an nRF5340-dk board as well but unfortunately, RIOT support is not there!!
Soon or letter I wish to port RIOT for this board as well. The challenge is that the CPU which is ARM Cortex-m33 is also not listed in the supported CPUs lists. This might make porting difficult.
Anyone can tell me how much time and energy it will take to do this task?
Also,
The list of CPUs is probably not up to date - better look at the code
nrf9160 and stm32f5 use a Cortex-M33 too and they work fine.
So to port the nRF5340 you only have to take care of the clock setup, interrupts, maybe some peripheral need modification. Take a look at cpu/nrf9160, that might be closest related (better compare the data sheets).
But I imagine it should be pretty straightforward. Feel free to open a Pull Request at any time to get some feedback on your approach!
Oh yes, that is going to complicate things as there is currently no multi-processor support in RIOT.
AFAIR the two cores on the nRF5340 will also see a different set of peripherals.
The easiest solution might be to run two instances of RIOT that then somehow communicate. Ideally we could just have the network related threads on the network core - GNRC is already based on message passing, so it would be quite a natural fit.
But that would only be the second step. First try getting the application core up and running with nrf5x_common peripheral drivers. Once we have that, the matter of multi-processor support becomes more pressing
Phew, that’s gonna be interesting. The blockdiagrams show that some peripherals are shared (but accessed through different buses), and others not.
As more control is with the application core (eg. which core a GPIO is assigned to is set from the application core), starting off with just the network core (which would otherwise seem to me like the easiest way to go) could be tricky :-/
I agree that two RIOT programs would be the way to go, with one core running the application and one running a RIOT that primarily serves to pass through abstracted peripherals. Definitely doable within RIOT, but more than just another board to port.
I was working on the porting of the board.
I made a folder in boards/nrf5340dk and started to create files in this folder. As the board nrf9160dk also has the same CPU, I am using some that for some of the parameters.
Currently, I have an error related to "No rule to make target ". Could anyone have an idea?
make[3]: *** No rule to make target ‘vectors_cortex-m33.c’, needed by ‘/user/Downloads/RIOT/examples/saul/bin/nrf5340dk/nrf9160_vectors/vectors_cortex-m33.o’. Stop.
make[2]: *** [/user/Downloads/RIOT/Makefile.base:31: ALL–/user/Downloads/RIOT/cpu/nrf9160/vectors] Error 2
make[1]: *** [/user/Downloads/RIOT/Makefile.base:31: ALL–/user/Downloads/RIOT/cpu/nrf9160] Error 2
make: *** [/user/Downloads/RIOT/examples/saul/…/…/Makefile.include:675: application_saul_example.module] Error 2
make: Leaving directory ‘/user/Downloads/RIOT/examples/saul’
It’s hard to tell what’s wrong without seeing the code.
Where does the vectors_cortex-m33.c come from? RIOT only has vectors_cortexm.c which is shared among all Cortex-M cores.
I got the solution and that was due to the naming of files. Inside a folder /RIOT/cpu/nrf9160/vectors there is a makefile with the line
SRC_FILE = vectors_$(CPU_MODEL).c
And because I have defined somewhere a CPU_MODEL as cortex-m33 somewhere inside my makefiles, the error was popping up. Finally, I have built the /saul application for the nRF5340, now it is time to upload it properly.
Well the core is the same that’s true but nRF53 and nRF9160 are not the same MCU. You need to write a vectors_nrf53_application.c + vectors_nrf53_network.c (I guess the latter can be optional for the time being).
Looking at the isr map for nRF9160 and nRF53_application, some IRQs are shared there is also a lot of difference.
Once this is done, you should look if peripherals driver (UART, GPIO, etc.) defined in cpu/nrf5x_common can be reuse for nRF53.
Sure, Didn’t consider the fact that ISR would be different for the different MCUs. Thanks for pointing it out.
If we look at the starting sequence of an MCU then there are power management settings, clock settings, and then also the Flash memory address and ISR maps settings. Is there anything else I am missing?
Finally, the peripherals can then be configured right?
If nRF53 is really that close to nRF9160, cpu_init() is really littleweight. You can have a look at cpu/nrf9160/cpu.c but then you should be ready to look at peripherals drivers.
nrf9160 and stm32f5 use a Cortex-M33 too and they work fine.
