Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed syslink unhandled overrun bug #121

Merged
merged 1 commit into from Jun 17, 2016
Merged

Fixed syslink unhandled overrun bug #121

merged 1 commit into from Jun 17, 2016

Conversation

mikehamer
Copy link
Contributor

This commit fixes a bug, whereby an overrun of the syslink UART buffer was not handled in the interrupt routine, causing constant retriggering and reentry, stalling the system.

Overruns are caused when high CPU/interrupt load causes the syslink UART data buffer to not be processed fast enough.

This bug was fixed by:

  1. handling unhandled conditions in the ISR, and
  2. reordering/simplifying instructions in the ISR to reduce latency before data read.

As it is currently implemented, every received byte causes the CPU to be interrupted, and the byte to be sent to the syslink for processing (this is due to a variable packet size and hence unknown transaction length).

TODO: A nicer implementation would be to fix the packet length at its maximum (32 bytes), and use DMA for the entire RX transaction. This would entirely avert the problem of an overrun causing packet loss. I assert (without evidence) that the time required to interrupt the CPU every byte, is less than the overhead due to fixing the packet size at its maximum length.

Signed-off-by: Mike Hamer mike@mikehamer.info

This commit fixes a bug, whereby an overrun of the syslink UART buffer was not handled in the interrupt routine, causing constant retriggering and reentry, stalling the system.

Overruns are caused when high CPU/interrupt load causes the syslink UART data buffer to not be processed fast enough.

This bug was fixed by:
 1. handling unhandled conditions in the ISR, and
 2. reordering/simplifying instructions in the ISR to reduce latency before data read.

As it is currently implemented, every received byte causes the CPU to be interrupted, and the byte to be sent to the syslink for processing (this is due to a variable packet size and hence unknown transaction length).

A nicer implementation would be to fix the packet length at its maximum (32 bytes), and use DMA for the entire RX transaction. This would entirely avert the problem of an overrun causing packet loss. I assert (without evidence) that the time required to interrupt the CPU every byte, is less than the overhead due to fixing the packet size at its maximum length.

Signed-off-by: Mike Hamer <mike@mikehamer.info>
@ataffanel ataffanel merged commit 21b7c66 into bitcraze:master Jun 17, 2016
@ataffanel
Copy link
Member

Thanks a lot for the fix. I agree, sending fixed sized packet would make things easier and I actually though about doing it from the beginning but back then it would have been over-optimisation.

It is possible to switch to fixed sized packet right now without changing the protocol: we just have to pad the packets with zeros until we reach the wanted size. Then on the receiving side we can "synch" the DMAs (ie. at the beginning we might end up having one packet in the middle of a transaction, this can be fixed for the following transactions).

@ataffanel ataffanel modified the milestone: next release Jun 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants