I would like to switch from the nRF52832 to the nRF5340.

[giun.kim]

I have code developed for the nRF52832 based on the Zephyr RTOS. If I switch to the nRF5340 with Zephyr RTOS, would it be possible to develop by simply uploading the additional source code? Are there any specific considerations I should keep in mind for this transition?

[Susheel Nuguru]

Switching your code from the nRF52832 to the nRF5340 with Zephyr RTOS is definitely possible, but there are a few differences between the two chips to keep in mind.

• The nRF5340 has two cores: one for the main application and another specifically for things like Bluetooth. Since the nRF52832 only has one core, your original code may need some adjustments if you want to take advantage of this dual-core structure. For example, protocol stacks on nRF5340 are compiled and running on network core and interact with the app core using RPMSg, there is nothing you need to do in the application to handle this apart from choosing the right board and configs based on the nRF5340 chip. The application code (main.c) will look very similar for both nrf52840 and nrf5340.
• Zephyr uses a DeviceTree file to manage hardware details, and each chip has its own setup. The nRF5340’s configuration will look a little different from the nRF52832’s, so you’ll need to make sure these files are set up to match the new chip’s peripherals and memory layout.
• The nRF5340 splits memory between its two cores, which is different from the single-core memory setup on the nRF52832. You may need to update how your code handles memory and flash to align with the nRF5340’s memory map.
• If you are using Zephyr API, then you should see little difference in how you access the peripherals through this API. If you are trying to access a peripheral in nrf5340 which is not available in nrf52840, then you ofcourse need to change you application to handle that difference..
• Some configuration settings specific to the nRF52832 may not directly apply to the nRF5340. You may need to update things like interrupt priorities or power management settings to better fit the new chip’s capabilities.
• If your nRF52832 code includes features to save power, be sure to review them for the nRF5340. Most of the system on idle power saving is handled by the RTOS in idle thread but if you want some more fancier power management, check if there is any differences/additions to the behavior of power management with the two chips.
• With these differences in mind, make sure to test everything thoroughly on the nRF5340. Debugging dual-core systems can be a little more complex than single-core ones, so it’s helpful to check that your tools and methods are all set up for the nRF5340.

Overall, while you should be able to reuse much of your code, expect to spend a bit of time adjusting things like memory, peripherals, and settings. A good approach might be to start with a Zephyr sample project for the nRF5340 and bring your code in step-by-step from there. This will help you catch any differences early on and ensure a smoother transition.

[Susheel Nuguru]

saying that, we have a lot of samples in our nRF Connect SDK that run without any change to the application code on both chips. So do not be scared by the differences I showed you up, most differences apply to more complex application that utilize the key upgrades provided by nRF5340. If you are making such application, you should already know what difference you need since you should already know what made you upgrade from nRF52840 to nRF5340. If it is only the memory and CPU performance you were seeking, then your application most likely needs minimalistic changes.