Altered Silabs RAIL wrapper to avoid parameter error

[ryankurte]

Fix for #5680, thread now initialised prior to interrupt handlers being enabled to ensure osThreadFlagsSet is not called with an invalid (uninitialised) thread ID.

Could alternately guard the signal calls if that was preferred, but this seemed easier.

[kjbracey]

I think this could still have some issues - the interrupt handler/thread now can reference the device_driver before it's fully initialised, and rf_radio_driver_id before it's initialised at all.

You should probably suppress the interrupts during initialisation - either in software or hardware.

Also, I see your interrupt routine is calling malloc? Or is that case not called from interrupt?

My recommendation for RX buffer allocation is to use Nanostacks ns_dyn_mem_temporary_alloc - that would then be useable from interrupt in the non-RTOS case. And for the RTOS case it should be part of the work deferred to the thread.

[ryankurte]

Yeah, that's probably not ideal. I should be able to mask off the signals in software prior to there being a thread to catch them. Will have a go at that.

And yes, there is a malloc at NanostackRfPhyEfr32.cpp#L966 which loads the message from the radio and is always in an interrupt routine. We have to load the packet to determine whether to ACK (or cancel the ACK as it were), so IMO it's appropriate the loading occurs there.

I will note that it's not related to these changes, and I suspect it exists because previously RAIL was managing memory for pending packets. TBQH I prefer static allocation in /all/ cases, we could maybe adopt a static memory pool (@stevew817)?

[mbed-ci]

Automatic CI verification build not done, please verify manually.

[ryankurte]

Wrapped signals so they're only emitted once a thread has been registered.

[ryankurte]

Having a go with an OS MemoryPool instead of malloc here but I currently have both CMSIS-RTOS error: Stack underflow (status: 0x1, task ID: 0x200017F8, task name: (null) and the classic Thread 0x0 error -4: Parameter error occuring, going to need more work but out of time for today.

[stevew817]

Yes, a static memory pool is probably in order, given that malloc is not officially IRQ-safe. I've made the quick-and-dirty implementation, which combined with your changes from this PR no longer throws errors in debug mode.
Ergo, the stack underflow and reappearance of the thread error might have something to do with the memorypool usage?

[cmonr]

@ryankurte Thoughts on @stevew817 comment?

[ryankurte]

I'm still getting the errors mentioned earlier, have been working on debugging em.

Thread 0x0 error -4: Parameter error appears to originate in the pool.free() operation but I haven't worked out why, and it only occurs on receipt of a particular packet type (which is probably why you haven't seen it @stevew817, need a set of communicating devices and time for it to occur). I suspect the RTX Memory pool might be like the RTX Queue and not interrupt safe as it seems to use OS events (🙄)?

Other thought is that it might be this line in rtx_evr.h:1495, but yeah, I haven't got my head around it or tried it yet.

#if (!defined(EVR_RTX_DISABLE) && (OS_EVR_MEMPOOL != 0) && !defined(EVR_RTX_MEMORY_POOL_FREE_DISABLE))
extern void EvrRtxMemoryPoolFree (osMemoryPoolId_t mp_id, void *block);
#else
#define EvrRtxMemoryPoolFree(mp_id, block)
#endif

CMSIS-RTOS error: Stack underflow (status: 0x1, task ID: 0x200017F8, task name: (null) is /I think/ because the aforementioned memory pool is allocated on the limited thread stack rather in global space and disappears when I drop the size of the pool by a bunch.

As an aside, is there a reasonable way of teaching the debugger about syscalls / kernel space? Because debugging these things is at least for me a bit of a nightmare 😂. The error occurs in the kernel, and the only ways to trace I have found are to either get lucky and break before the occurrence of it, or rewrite state with he debugger until you return to application space.

[stevew817]

Well, when I said quick-and-dirty, I meant implementing a rudimentary static pool, not using the RTX Memory pool, which is probably why the issues were gone for me.

As far as debugging goes, I don't know of any debugger other than uVision (which costs money) and DS5 (even more money) supporting RTX. Supposedly Segger's Ozone (free to use with all Silicon Labs kits) is extensible to support different RTOS'es, but AFAIK they only have plugins for embOS and FreeRTOS as of now.

[ryankurte]

Updated to static memory allocated in the queue in my efr32-wip branch and am still getting the CMSIS-RTOS error: Stack underflow (status: 0x1, task ID: 0x20001718, task name: (null)) from somewhere, but I have /no idea/ how to debug that tbh :-(

[cmonr]

@kjbracey-arm @SeppoTakalo Do you all have any ideas on how to help @ryankurte move forward with the PR?

[cmonr]

@ryankurte, I take it you're still stuck with your last issue?

[cmonr]

Closing for now. Please reopen when updates are available.