Feasibility of Using SPI as Transport Layer for mcumgr Firmware Updates on nRF52820

[Lezhi]

Hello,

I am considering implementing SPI communication as the transport layer for mcumgr in my application. The setup involves an nRF52820 as an SPI slave and an nRF52840 as the SPI master. The goal is to transmit the new firmware image via SPI, using the SMP protocol to facilitate firmware updates.

Given that the SPI slave functionality in nRF Connect SDK(2.7.0) is currently marked as experimental, I would like to know more about the feasibility of this approach. Specifically:

1. Are there known limitations or stability issues when using SPI as the transport layer for mcumgr in this configuration?
2. Does the experimental status of the SPI slave in NCS imply potential issues or limitations with data integrity or reliability during firmware updates?
3. Any recommendations or best practices for setting up SPI-based mcumgr firmware updates with this hardware configuration?

P.S. The implementation of the nRF52840 is not involved in this discussion, it uses a different stack. 

Thank you in advance for any insights or guidance.

Lezhi

[Menon]

hello,

AFAIK, the SMP protocol used by Mcumgr does not natively support SPI as a transport layer. SMP supports BLE and UART out of the box. I believe it might be possible to add SPI, but I haven't tested it or worked on it. You may need to implement a custom transport driver for SPI, using the transport abstraction layer in the SMP protocol to support new transport types like SPI. Check  smp.c which shows core implementation of the SMP protocol.

Kind Regards,

Abhijith

[Lezhi]

Hello,

Thank you for your response. I will review the SMP implementation as suggested. Additionally, if there are any known limitations with the SPI_Slave functionality, I would appreciate it if you could share those details.

Regards,

Lezhi