SX1272 / SX1276: Delay required inside TimerIrqHandler

[NovaNekmit]

During SX1272OnTimeoutIrq, SX1272Reset is called here.

An implementation of the reset function will typically require waiting for some amount of milliseconds (as ie implemented here ).
This is a problem when rtc-board.c is implementing timers by calling TimerIrqHandler from inside the interrupt handler.

I understand that resetting is a workaround and should not happen in regular use.

Is there a intended way to request a call to RtcProcess through the stack (similar to MacProcessNotify), or does the application have to interface directly with the board hal or "poll" by blindy calling RtcProcess in a loop?

[mluis1]

The RtcProcess was introduced in order to be able to handle the SAMR34 RTC peripheral. For all other platforms this function is empty.
The RtcProcess can be called as it is done under the SAMR34 examples.

LoRaMac-node/src/apps/LoRaMac/periodic-uplink-lpp/SAMR34/main.c

Lines 301 to 304 in 05353ff

	while( 1 )
	{
	// Tick the RTC to execute callback in context of the main loop (in stead of the IRQ)
	TimerProcess( );

You can modify the code to run the timer interrupts handling under the main context, However this may introduce unwanted delays which could break the LoRaWAN required timing precision.

It has to be noted that this workaround is implemented like this since some time now and we never noticed issues with it.
Also, there should not be a problem to call a delay function under an interrupt context. As one can observe there are also SPI transactions being done under IRQ context. It is not an ideal situation however the advantages overcome the drawbacks.

In the future it would be nice if you could post this kind of questions on the project Discussions tab. It is a better place to engage discussions and then we can agree if it is an issue or not.
If you don't mind I move this issue to the Discussions tab.

[NovaNekmit]

I was not aware GitHub had discussions now, thanks for moving.

I implemented DelayMs via FreeRTOS (leading to a failed assert when called from ISR), but I see now it is called with very low delays, so I will implement it as blocking, that should fix my issue.

[mluis1]

Just for info FreeRTOS published a repository using this project. It may give you some ideas.
https://github.com/FreeRTOS/Lab-Project-FreeRTOS-LoRaWAN