CrossWorks with nRF5 SDK
Hello,
So — I recently got the new Nordic DK for the nRF52832 and installed the appropriate Package in Crossworks. in just trying to get the blink example working, I've come across all kinds of toolchain weirdness. When I start a Project by selecting 'An executable for Nordic Semiconductor nRF52.' the project is created and expects to find nrf_delay.c, but it can't because my SDK doesn't contain it.
In the Nordic SDK version nRF5_SDK_12.2.0_f012efa there is an nrf_delay.h but no nrf_delay.c, causing an error in my build because, well — there's no code to compile for referenced functions.
If I back out to an older SDK, say nRF5_SDK_11.0.0_89a8197 there is an nrf_delay.h AND nrf_delay.c, but no boards.c..although there is a boards.h. So now boards.h is missing.
I can find no mention of these changes — or why, or how to deal with them — in the release notes of any of the SDK's between 11.0 and 12.2.
I'm not sure how to fix this problem. It seems either that there is an inconsistency in the SDK or more likely I'm doing something terribly wrong.
Any helps or suggestions from other CrossWorks users or any one with special insight into the how and why-fors of the SDK would be greatly appreciated.
Julian
-
The Nordic Semi SDK is very helpful for making the radio work. Less helpful for everything else.
Biggest problem I ran into was that the SDK_Config.h file in each example has been stripped down to only enable the functionality you need for that example. Makes merging examples infuriating. Before I figured it out, I basically gave up and returned to the Keil toolchain which was ok since my app fit in Keil's free 32K code size limit.
There is a complete (almost) SDK_Config.h file lurking somewhere in the SDK. Check the documentation on Nordic Semi's website to help you find it.
That and the SDK's annoying structure (nested folder paths get so deep that windows environment limitations can break you). Me sure to make the SDK a root folder on your C: drive.
Another issue with the SDK is the rediculous level of indirection for the simplest of things. Toggling an LED means making 5 nested call/returns. I tried using the SPI demo in the SDK to read an ADC and it was faster to just read the data by bit bang GPIO (once I had stripped all the nested call crap from GPIO access).
The ESB radio app in the SDK is excellent (and it can run packets twice as fast if you make the change below). Nordic Semi claims this change breaks backwards compatibility with the nRF51. I don't see why it would since the change is inside an #ifdef NRF52 block.
nrf_esb.c
static ret_code_t apply_address_workarounds()
{
#ifdef NRF52
// Set up radio parameters.
//NRF_RADIO->MODECNF0 = (NRF_RADIO->MODECNF0 & ~RADIO_MODECNF0_RU_Msk) | RADIO_MODECNF0_RU_Default << RADIO_MODECNF0_RU_Pos;
NRF_RADIO->MODECNF0 = (NRF_RADIO->MODECNF0 & ~RADIO_MODECNF0_RU_Msk) | RADIO_MODECNF0_RU_Fast << RADIO_MODECNF0_RU_Pos;
// Workaround for nRF52832 Rev 1 Errata 102 and nRF52832 Rev 1 Errata 106. This will reduce sensitivity by 3dB.
*((volatile uint32_t *)0x40001774) = (*((volatile uint32_t *)0x40001774) & 0xFFFFFFFE) | 0x01000000;
#endif
return NRF_SUCCESS;
}
Please sign in to leave a comment.
Comments
1 comment