nRF52832: Use external MCU to run nRF's application & SDK via SPI

[BitsAndBytes]

I'm working with a client's existing product. It has an external MCU connected to nRF52832 via SPI.

The nRF application & SDK code are compiled inside the external MCU source code and processed on the nRF. I have done similar setups with other chip brands using integration libs but didn't realize this is available with Nordic BLE.

I have not been able to find documentation or an example of how to reproduce this. I found info related to SPIS (SPI slave) but nothing implying that the nRF app/SDK are compiled on the external MCU.

2 questions:

1) Where can I find information on this? ... ie what firmware actually lives on the nRF that is able to process the softdevice cmds, etc from SPI?

2) Updating the nRF application code is easily done inside the external MCU source, but is it possible to update the softdevice and bootloader on the nRF? If yes, how? I understand normal Button-less DFU Service updates and have created many projects using it, but for some reason I'm struggling with the concept of how this path will work when the application code is on external MCU and softdevice/bootloader is on nRF chip.

The client does not have implementation details for this part of their product because this portion was done several years ago and not the same dev team nowadays. All they have is a .hex file that the manufacturing facility flashes on nRF during production.

Any help is appreciated.

[Amanda Hsieh]

Hi, 

Check out my colleague's answer in this post. 

Regards,
Amanda H.

[BitsAndBytes]

Thanks Amanda Hsieh for the quick response.

And thanks for the post link. That answers #2 question.

What are your thoughts on #1? How can a nRF application/SDK live on an external MCU and processed via SPI during runtime?

[Amanda Hsieh]

BitsAndBytes said:

How can a nRF application/SDK live on an external MCU and processed via SPI during runtime?

Could you elaborate in more detail? What is your external MCU? Is it nRF7002 or Nordic chip? Why would you need NCS to work on an external MCU? What is the use case/application?

[BitsAndBytes]

The external MCU is an NXP. The NXP communicates with nRF52832 via SPI.

Its an existing product with 7+ year old code base and the original designers are no longer part of the company. So the scope of the 'why' isn't fully known. But here is the scenario and the benefits I see for doing it.

How it works:

1) NXP source code contains Nordic SDK 14, as if it is just another 3rd party C library which is compiled with the rest of the NXP application source.

2) Softdevice + some unknown application is flashed to the nRF.

3) Since the Nordic SDK is compiled on NXP, the logic processing of the SDK occurs on the NXP ... but when actual softdevice calls are made they are passed thru SPI to the nRF. And when nRF softdevice call backs occur, they are passed back to the NXP via the SPI.

4) There is DMA usage on the SPI to reduce NXP interrupt overhead. The msgs sent are somehow serialized.

So effectively its a serialized link across SPI that allows the Nordic SDK to live on an external MCU.

Benefits:

- For years now, BLE related logic changes have been able to be made without every reflashing the nRF chip ... but have been made only inside the NXP since that is where the Nordic SDK lives.

- Code functionality compatibility between the NXP and nRF is much easier to maintain.

- Never get in the situation where NXP is updated and the nRF is not and grid lock them, for example.

- Debugging is much easier since the logs & breakpoints are all coming from the same source even when dealing with nRF related operations.

Hope the above helps with understanding the setup.

So what I'm interested in knowing is does Nordic have a similar solution path for this? And I ask because I've seen this exact same type of setup with other products, such as back in the day with Bluegiga's BGLib. It was great to develop with because you tossed in a C lib to the external MCU, connected the UART or SPI to the Bluetooth module ... and the lib serialized the calls & callbacks back/forth seamlessly. It offloaded BLE stack from main processing unit, but gave seamless integration.

I'm a contract engineer and have I've done somewhere between 20 to 30 nRF implementations and this project is the first time I've seen it done with a Nordic part. Some of my client's projects are machine control related and must have an external MCU to have true real-time operations without underlying interrupts for Bluetooth stacks. The above type of setup has design advantages.

Curious to hear your thoughts.

[Amanda Hsieh]

Hi, 

There is the SPI Master Slave Example shows how to use the SPI master and slave async drivers in Zephyr, and sets up a separate master and slave interface in order to allow sending data from the master to the slave and vice versa, on the same board. 

You can use the SPIM driver for SPI communication with EasyDMA between nRF52 devices and external MCUs.

-Amanda H.

[BitsAndBytes]

Hi Amanda Hsieh , thanks for the above.

I regularly use SPI for projects, so it's not the actual SPI comms of interest. The question is more related to 'how' SPI is being used. And whether or not Nordic has a supported path for having the Nordic SDK compiled on an external MCU that acts as a master driving the soft device calls made on the slave nRF chip.

After researching more into the client's code that does this, I'm seeing that it wasn't something supported by Nordic but was an internal development project.

It is an interesting way to work with nRF's, but I'm not finding this as a common path. I have a path forward so we can close this out.

Thanks for you time.