sdRead fails to unblock after missing a packet

[austin_boulderes]

I'm working on a project which, among other things, uses XBee wireless modules for communication between nodes. The code runs on an STM32F103, and I'm using ChibiOS 2.6.6.

To talk to the modules, I'm using the standard chbios serial HAL, (sdRead and sdWrite). This works consistently and reliably most of the time, but if I pause the debugger and miss a packet I can get the firmware in a state where my serial recieve thread blocks -- there's serial data coming in, I can verify the underlying ISR is firing correctly, but nothing comes through to the thread itself. I wouldn't worry about this much, since it's produced by a debugging context, but it also reliably occurs when I attempt a transaction with a high-volume of serial data -- in this case, sending a firmware image to a bootloader.

I've found that this seems to only affect the call to sdRead which was blocking at the time that the interruption occurs -- adding a timeout allows me to fall back into normal communication. However, this still results in a dropped packet, which is not really acceptable in the bootloader context.

I was hoping I could get some insight as to possible solutions. I note one place where Giovanni says the UART driver rather than the serial driver should be used for high-speed, packet based communications. Could this be an acceptable alternative?

[Giovanni]

It is the normal behavior of "read" functions on streams, those always return the specified number of characters or on timeout. It is suggested to wait for an event from the serial driver (data available, tx queue empty, errors) and then read/write/geterrors using TIME_IMMEDIATE as timeout. The waiting is done on the event source, I/O operations are always non-blocking.

For packet based protocols it is recommended the use of the UART driver, closer to the need of a protocol state machine (but generally harder to use).

Giovanni

[austin_boulderes]

Thanks! I implemented something which uses sdGetWouldBLock rather than simply blocking the thread, and it at least allows the system to recover after missing a packet.

I found that the problem kicking it into this state was a mutex'd resource multiple threads were competing over; it was blocking my recieve thread and causing it to miss a packet.