Using embOS with Nordic BLE

From SEGGER Wiki
Revision as of 13:38, 18 May 2021 by Martin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Shipments of embOS for Cortex-M contain several start projects for Nordic Semiconductor's nRF51 and nRF52 devices. Those projects may be used to utilize Nordic's Bluetooth Low Energy (BLE) soft devices, but require a few modifications to do so because of concurrent concepts within embOS and the BLE stack.

Affected functionality Problem description Solution
embOSView via J-Link embOSView communication via J-Link will reserve 32 bytes on the system stack.
Nordic's BLE, however, will also utilize that stack and is not aware of any reserved bytes.
Effectively, the stack gets corrupted by concurrent accesses and the application will fail.
Configure the define OS_VIEW_IFSELECT in the source file RTOSInit_nRF5x.c to any value but OS_VIEW_IF_JLINK (e.g., OS_VIEW_DISABLED, or OS_VIEW_IF_UART if available).
NVIC VTOR All interrupts are routed through the BLE, which also configures the vector table offset register (VTOR). Reconfiguration of that register will cause the application to fail. Comment or delete the line SCB->VTOR = (OS_U32)&__Vectors; from the function OS_InitHW() inside the source file RTOSInit_nRF5x.c.
__WFI() Issuing a wait for interrupt instruction from outside the BLE will cause the BLE to fail. By default embOS will not call __WFI(). However, a commented __WFI() instruction is included in the function OS_Idle() inside the source file RTOSInit_nRF5x.c for demonstration purposes. Check that it still is commented when utilizing the BLE.
NRF Logger via RTT No output is shown in the ES terminal or RTT Viewer. Make sure output via RTT is enabled by setting NRF_LOG_BACKEND_RTT_ENABLED to 1 in the sdk_config.h.

If NRF_LOG_DEFERRED is set to 1, NRF_LOG_FLUSH() has to be called by the application in order to flush the output and make it visible. In an application without embOS, this is usually done within an endless loop in the main() function. With embOS, this can be done from a task or OS_Idle(). If NRF_LOG_FLUSH() is called from OS_Idle(), then it has to be called within a critical region to prevent tasks from canceling the execution of NRF_LOG_FLUSH().

If the output shall be flushed directly, NRF_LOG_DEFERRED can be set to 0. Additionally, NRF_LOG_NON_DEFFERED_CRITICAL_REGION_ENABLED has to be set to 1 to ensure thread safety.

embOS system tick Some SoftDevice examples put the device in sleep mode. If, as part of entering the sleep mode, the timer which is responsible for the embOS system tick is disabled, system ticks that would occur during sleep mode don't incrment the system tick, and thus the embOS time stands still until the timer is enabled again. It is the application's responsibility to ensure that the timers are handled correctly, the device returns from sleep mode if a task has to be scheduled and the embOS system tick is adjusted properly after returning from sleep mode. The embOS provides API functions for starting the tickless mode and adjusting the embOS system tick after a tickless period has ended. For more information please take a look into the "Tickless support" section of the "Low Power Support" chapter in the embOS manual.

Please be aware that in previous shipments of embOS, __WFI() may not be commented by default and the line to configure VTOR may read slightly different; the given solutions to enable the embOS project for usage with the BLE, however, are still the same.

An example project for the nRF52 Development Kit (PCA10040) that integrates the BLE with embOS is available on request.