Is SEGGER_RTT_printf() thread safe with FreeRTOS?

RE: Is SEGGER_RTT_printf() thread safe with FreeRTOS?

leonhart88 — Wed, 21 Mar 2018 16:31:37 GMT

Great! Thanks for confirming this. As an aside, are the NRF_LOG functions also thread safe? I'm assuming yes for RTT as they probably use the same RTT functions, but am not sure about UART logging. Thanks!

RE: Is SEGGER_RTT_printf() thread safe with FreeRTOS?

natersoz — Wed, 21 Mar 2018 15:19:55 GMT

Ah, that is what is going on with the call to d_nvic_critical_region_enter(nested)

It is easier to understand once the motivation is known. Thanks!

RE: Is SEGGER_RTT_printf() thread safe with FreeRTOS?

Rune Holmgren — Wed, 21 Mar 2018 13:04:58 GMT

Hi,

I agree with Nathaniel here. It should be safe both with and without the SoftDevice enabled. sd_nvic_critical_region_enter will still allow interrupts reaching the SoftDevice, but there will not be any events for the application in the critical region. This means that timing is not reliable even in critical regions, but that shouldn't be a problem for RTT since it's essentially just data being pushed.

Best regards,
Rune Holmgren

RE: FreeRTOS Tasks, SEGGER_RTT_printf() and semaphores

leonhart88 — Wed, 21 Mar 2018 00:40:43 GMT

You're right that does seem to be the case. I didn't bother to step that deep into the definitions initially.

Hopefully a Nordic support member can comment and confirm this.

RE: FreeRTOS Tasks, SEGGER_RTT_printf() and semaphores

natersoz — Wed, 21 Mar 2018 00:17:39 GMT

Actually, you should be safe. Here is why:

SEGGER_RTT_printf() calls into

unsigned SEGGER_RTT_Write(unsigned BufferIndex, const void* pBuffer, unsigned NumBytes)

file: SEGGER_RTT.c

And here SEGGER_RTT_LOCK() is called, which is #defined to CRITICAL_REGION_ENTER() and there is an UNLOCK which is #defined to _EXIT() ...

// This gets weary, all the sdk_config.h, macro hell.

This gets #defined to app_util_critical_region_enter()

If SOFTDEVICE_PRESENT is defined then sd_nvic_critical_region_enter(nested) is called which looks quite deliberate and scary. (Someone appears to either really know what they are doing or ... I'll assume they know what they are doing).

if not defined then app_util_disable_irq() is calledwhich is #defined to the intrinsic __disable_irq();

---

So bottom line: they took care of it. Just so long as you have your sdk_config.h set they way Nordic expects and did not over-write something critical. The C preprocessor is a horrible tool.