Which functions are thread-safe?

[Predielis]

Is it possible to call uMemcpy and fnSendUDP from inside a PIT timer interrupt handler? At the same time I would be receiving through a callback function set up with fnGetUDP_Socket.

From time to time the application stops in the unhandled interrupt function, and it seems that a memory corruption happens inside uMemcpy.
uMemcpy does not seem to be reentrant, when using DMA. I did a quick test disabling and enabling interrupts inside of this function, but I still have crashes. This event is rare, so it's not easy to debug.
fnSendUDP too seems to be risky.

What is the best way to handle this problem?

Thanks.

[mark]

Hi

uMemcpy() should be safe. It is also re-entrant due to the fact that it only uses DMA when the DMA channel is free - if there is a DMA operation in progress it will fall-back to a normal loop copy.

I wouldn't recommend using Ethernet writes from an interrupt due to the fact that a write into the Ethernet Tx buffer could be interrupted by another write - the result being a corrupted Ethernet frame. I don't see why this would result in an exception but there may be a chance somewhere that is more difficult to see.
Note that writes to the Ethernet buffer are not protected since they can take several hundred us - depending on processor speed - and it is assumed that all Ethernet writes are from code and not interrupts.

Therefore I would use the interrupt routine that you have to flag that the UDP transmission is required (eg. sending an event to a task). The task can then send the data, which will avoid any risks.

This risk is also present when using fnDebugMsg() on a TELNET connection when the debug output is from an interrupt routine. I have in fact been thinking that fnDebugMsg() - as well as fnDebugHex() etc. could identify whether it is being called from within an interrupt routine (not sure how yet but probably possible) and, if it is, do a deferred debug output write rather than a direct TELNET one (meaning that it probably calls an Ethernet transmission). That would probably result in it putting the output message to a temporary buffer and sending an event to the debug task. The debug task would then send the buffer content to the debug output (in a safe fashion).

Regards

Mark

[Predielis]

Thanks, very clear as always.
I don't think my code ever have the TX interrupting TX behaviour, so why the exception happens is still not clear. It seems TX over RX breaks things.
Anyway the TX inside a task seems to solve the problem.

Regards.