Migrating nRF52840 to nRF52833

[Joel V]

Hi DevZone !

I am currently trying to migrate from nRF52840 to nRF52833 because of a backorder problem with the former.

My application consist of a Mesh configurations with the ESB protocole between multiple devices. 

It is using SPIM to read on external devices and RTC to periodically send packets.

I am using the SDKs:

• nRF5_SDK_15.0.0_prf
• nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac_min

I am currently trying to program a nRF52833-DK to make some test before implementing it with my real board.

I have already talked to one of your collegues to verify the hardware validity and it seems ok. 

Now, I have been able to program my DK by adding the dependencies of the nRF52833 in my SDK. 

I am not using any softdevice and I use a makefile to compile and program the device.

Now, I can't use my clock or my mesh library to send anything on the ESB protocole. I was wondering what could cause that problem.

Thanks you,

Joel V.

[Vidar Berg]

Hello,

Are you able to debug the application to see if the program hangs or crashes? It should generally be fairly straight forward port FW from the 52840 to 52833. The most important step is probably to remember to include the correct startup files and update the linker settings to reflect the new memory address ranges.

The relevant startup files are:

$(SDK_ROOT)/modules/nrfx/mdk/gcc_startup_nrf52833.S

$(SDK_ROOT)/modules/nrfx/mdk/system_nrf52833.c

Also remember to replace the preprocessor flag "NRF52840_XXAA" with NRF52833_XXAA in your makefile.

Now, I have been able to program my DK by adding the dependencies of the nRF52833 in my SDK. 

Did you update the MDK files in  /nRF5_SDK_15.0.0_a53641a/modules/nrfx/mdk/ with files with one of the more recent MDK releases here: https://www.nordicsemi.com/Products/Development-tools/nRF-MDK?

Best regards,

Vidar

[Joel V]

Hi Vidar,

First, thanks for the quick answer !

Vidar Berg said:

The relevant startup files are:

$(SDK_ROOT)/modules/nrfx/mdk/gcc_startup_nrf52833.S

$(SDK_ROOT)/modules/nrfx/mdk/system_nrf52833.c

Also remember to replace the preprocessor flag "NRF52840_XXAA" with NRF52833_XXAA in your makefile.

Those are the exact changes I did, and I changed the board from PCA10059 to PCA100100

Vidar Berg said:

Did you update the MDK files in  /nRF5_SDK_15.0.0_a53641a/modules/nrfx/mdk/ with files with one of the more recent MDK releases here: https://www.nordicsemi.com/Products/Development-tools/nRF-MDK?

I took the MDK in a more recent SDK (17 I think), but now I did the test by using the latest MDK in  https://www.nordicsemi.com/Products/Development-tools/nRF-MDK and I still have the same problem.

Vidar Berg said:

Are you able to debug the application to see if the program hangs or crashes?

I debugged it and it hangs in the gcc_startup_nrf52833.S on line:

.type   Default_Handler, %function

in the IRQ handler.

I changed the linker script to have the memory:

MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x80000
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x20000
}

Thanks,

Joel V.

[Vidar Berg]

Hi Joel,

No problem!

Joel V said:

I debugged it and it hangs in the gcc_startup_nrf52833.S on line:

.type   Default_Handler, %function

This is helpful. It indicates you have an enabled IRQ source without a corresponding IRQ handler. Were you debugging with GDB? In that case, please run  "info registers" to get the xPSR register while you are inside the exception handler. You can use "nrfjprog --readregs" for the same if you are not using GDB. The last byte of this register will hold the current ISR number, and that will tell us which one of the IRQs caused the program to enter Default_Handler.

Here is an example where xPSR shows that the program running inside the UARTE0_UART0_IRQHandler:

Note that you have to subtract ISR number by 16 to get the IRQ number as listed in the nrf52833.h header. This is because cortex specific interrupts are starting at -15 instead of 0.

Best regards,

Vidar