Migrating S112 to S113 and nRF52832 to nRF552840?

[samsam]

I have application developed that works ok on nRF52 DK (nRF52832) with S112 and now want to migrate it to a custom board with nRF52840.

1. Could you confirm that S113 is applicable to nRF52840, because on this page S113 is listed only for nRF52833?
2. Is there any migration guide or examples that are written for both S112 and S113 that can ease this migration?
3. Can the old application with S112 with adjusting only the SOC defines and memory addresses work (at lest partially) on nRF52840 as I see plenty of examples for pca10056e with S112 ?

Thanks

[Einar Thorsrud]

Hi,

Could you confirm that S113 is applicable to nRF52840, because on this page S113 is listed only for nRF52833?

Yes. You can look at the SDKs and SoftDevices compatibility matrix for the nRF52840 to see all the details on which versions are compatible. 

Is there any migration guide or examples that are written for both S112 and S113 that can ease this migration?

There is no migration guide that explains this explicitly. The main things you need to remember are (of which you :

• Change include path to the path of the new SoftDevice
• Update defines for SoC type and SoftDevice type
• Update memory (flash and RAM) addresses
• Replace startup and system files in the project as you go from nRF52833 to nRF52840

Can the old application with S112 with adjusting only the SOC defines and memory addresses work (at lest partially) on nRF52840 as I see plenty of examples for pca10056e with S112 ?

It may work partially and can be used during development, but the combination should not be used in production. The S112 has not been tested on the nRF52840, so you should expect some issues and missing errata workarounds in the SoftDevice. Also, we have not doen BLE qualification for this combination.

[samsam]

Hi Einar,

Sorry for the wrong positioning of this answer, but devzone forum is again screwed and this was the only your posting that I was able to get “Reply” button after at lest 5 minutes banging on the F5, so could post 

Thanks to the link you gave me for the memory settings I moved successfully couple steps further, but still hitting the wall with exception and unfortunately still only migrating S112 to S113 on the same hardware PCA10040 / nRF52832 

So the problem I score to trace so far starts from line 219 of ss_clock.c  that is actually modified version of

https://github.com/NordicPlayground/nrf5-calendar-example with major modification as: Added soft device, changed NRF_RTC2 as source, and there is FreeRTOS added. With S112 the code works Ok, with S113  line219 NRF_CLOCK->EVENTS_HFCLKSTARTED = 0; is the line where starts problems – never can reach the breakpoint on the next line 220.

So after hit Go/F5 while at breakpoint @ 219, SES send me to a place which is shown on screenshot Step2.png,

then hitting again Go/F5 SES moves me to what is seen on Step3.png

and then next Go/F5 lead me to the breakpoint at line that prints the error message (Step4.png).

Any idea where is the problem or at least how could trace it, because what is shown   Step2.png and Step3.png doesn’t give me any clue, even why SES debugger stops there without breakpoint?

Thank you and best regards

[Einar Thorsrud]

Hi,

I do not see enough of your code to get a full context. However, I see you are modifying clock registers directly, and that is not allowed when the SoftDevice is enabled. So it is expected that you get NRF_FAULT_ID_APP_MEMACC when doing NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;. I suggest you use the clock driver instead. Alternatively you could call sd_clock_hfclk_request() if there are no libraries that use the clock driver. This should also fail with S112, though.

Regarding your previous comments about values in the tutorial about RAM and flash adjustment, the SoftDevice size (which would be the app start address) is always found in the SoftDevice specification. for S113 that is 0x1C000 byte. The RAM usage is configuration dependent, so you should set it to whatever the log indicates. You could increase the SoftDevice RAM a bit to start with (setting the RAM start address of the APP a bit higher), if that seems to be a problem. And then adjust as indicated by the log.

[samsam]

Hi Einar,

Regarding FLASH and RAM, after I carefully read what you've sent me before, I think I did it right and don't see any problems. so far, but my question was regarding  the heap and stack: arm_linker_heap_size and arm_linker_stack_size if there is some guide how to adjust them properly?

With my implementation of FreeRTOS in this code I need at least configTOTAL_HEAP_SIZE 10240, not quite sure where FreeRTOS get this space, but my wild guess is that it comes from arm_linker_heap_size, so I'm curious do I need to adjust those 2 values for the heap and stack that are fixed at 2048 for most of the SDK examples?

___________________________

Now for the RTC code - I'll  look on the driver if can find substitution for NRF_CLOCK->***, but what is the story  for CAL_RTC->***. Is it safe to use them or have to substitute them also with what? 

Is there any example - I actually need some RTC with 1 minute wakeup to update clock/timer shown on a display?

void nrf_cal_init()
{
NRF_LOG_DEBUG("nrf_cal_init 0");
// this was in main:
NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
NRF_CLOCK->TASKS_HFCLKSTART = 1;
while(NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

// Select the 32 kHz crystal and start the 32 kHz clock
NRF_CLOCK->LFCLKSRC = CLOCK_LFCLKSRC_SRC_Xtal << CLOCK_LFCLKSRC_SRC_Pos;
NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
NRF_CLOCK->TASKS_LFCLKSTART = 1;
while(NRF_CLOCK->EVENTS_LFCLKSTARTED == 0);

// Configure the RTC for 1 minute wakeup (default)
CAL_RTC->PRESCALER = 0xFFF;
CAL_RTC->EVTENSET = RTC_EVTENSET_COMPARE0_Msk;
CAL_RTC->INTENSET = RTC_INTENSET_COMPARE0_Msk;
CAL_RTC->CC[0] = m_rtc_increment * 8;
CAL_RTC->TASKS_START = 1;
NVIC_SetPriority(CAL_RTC_IRQn, CAL_RTC_IRQ_Priority);
NVIC_EnableIRQ(CAL_RTC_IRQn);

m_rtc_increment = CLOCKINTRVL_S;
m_time += CAL_RTC->COUNTER / 8;
CAL_RTC->TASKS_CLEAR = 1;
CAL_RTC->CC[0] = CLOCKINTRVL_S * 8;

if (pdPASS == xTaskCreate(clock_display_task, "clock_display_task", configMINIMAL_STACK_SIZE + 100, NULL, 1, NULL)){
NRF_LOG_DEBUG("nrf_cal_init 2: %d", xEventGroupGetBits(appss_event_group));
} else {APP_ERROR_HANDLER(NRF_ERROR_NO_MEM);}

}

Major part is almost identical to this example: https://github.com/NordicPlayground/nrf5-calendar-example 

Thank you and best regards

 

[Einar Thorsrud]

Hi,

samsam said:

arm_linker_heap_size and arm_linker_stack_size if there is some guide how to adjust them properly?

Stack and heap are configured under Runtime Memory Area:

samsam said:

Now for the RTC code - I'll  look on the driver if can find substitution for NRF_CLOCK->***, but what is the story  for CAL_RTC->***. Is it safe to use them or have to substitute them also with what? 

As you use the SoftDevice, this is all handled for you. The SoftDevice will start and regularly calibrate the LFCLK, so there is no need to use any CLOCK registers directly.

Personally I would opt for using the nrf5-calendar-example code as inspiration and use the app_timer (or just a FreeRTOS timer as you use FreeRTOS) instead of the RTC directly. But if you have a spare RTC and want to keep most of the example as is, then that also works.