fsl_usart.c: How to properly handle RX FIFO overflows, i.e., kStatus_USART_RxError

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

fsl_usart.c: How to properly handle RX FIFO overflows, i.e., kStatus_USART_RxError

110 Views
danielholala
Senior Contributor II

Hello,

on LPC5528/LPC5526/LPC55xx, I'm using the USART driver from the SDK, see

https://github.com/nxp-mcuxpresso/mcuxsdk-core/blob/main/drivers/flexcomm/usart/fsl_usart.c#L1123

The code works properly when requesting to receive single bytes using 

USART_TransferReceiveNonBlocking()

It also recovers on RX FIFO overflows by reinitiating reception.

Situation is different when using  

USART_TransferReceiveNonBlocking()

with xfer->dataSize  > 1. For example, the receive callback inspects the RX FIFO level and if the RX FIFO level is > 1, it calls  USART_TransferReceiveNonBlocking()  with the exact number of bytes of in the RX FIFO to retrieve these bytes more efficiently, say 10 bytes.

However, if the system is busy handling other interrupts, the RX FIFO might overflow. Then 

void USART_TransferHandleIRQ(USART_Type *base, usart_handle_t *handle)

clears the RX FIFO overflow bit, empties the FIFO and calls the callback with kStatus_USART_RxError. All the bytes from the FIFO are therefore discarded and cannot be received any more.

However, it does not reset rxDataSize. So the callback will not be called again until the number of bytes (in the example ten bytes) have been received. Until this, the receive mechanics hangs.

How do you recover from this situation?

Resetting the dataSize by calling USART_TransferReceiveNonBlocking() with xfer->dataSize = 1does not work as the receive mechanics is still in status kUSART_RxBusy.

 

So I wonder what is the proper way to handle RX FIFO overflows with the SDK drivers.

Thanks.

Daniel

 

PS: sorry for the strange text formatting. I tried to markup code so it is easier to read but screwed up.

 

 

 

0 Kudos
Reply
0 Replies
%3CLINGO-SUB%20id%3D%22lingo-sub-2295145%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3Efsl_usart.c%3A%20How%20to%20properly%20handle%20RX%20FIFO%20overflows%2C%20i.e.%2C%20kStatus_USART_RxError%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2295145%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHello%2C%3C%2FP%3E%3CP%3Eon%20LPC5528%2FLPC5526%2FLPC55xx%2C%20I'm%20using%20the%20USART%20driver%20from%20the%20SDK%2C%20see%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fnxp-mcuxpresso%2Fmcuxsdk-core%2Fblob%2Fmain%2Fdrivers%2Fflexcomm%2Fusart%2Ffsl_usart.c%23L1123%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noreferrer%22%3Ehttps%3A%2F%2Fgithub.com%2Fnxp-mcuxpresso%2Fmcuxsdk-core%2Fblob%2Fmain%2Fdrivers%2Fflexcomm%2Fusart%2Ffsl_usart.c%23L1123%3C%2FA%3E%3C%2FP%3E%3CP%3EThe%20code%20works%20properly%20when%20requesting%20to%20receive%20%3CSTRONG%3Esingle%20bytes%26nbsp%3B%3C%2FSTRONG%3Eusing%26nbsp%3B%3C%2FP%3E%3CP%3E%3CFONT%20face%3D%22andale%20mono%2Ctimes%22%3E%3CSPAN%3EUSART_TransferReceiveNonBlocking()%3C%2FSPAN%3E%3C%2FFONT%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EIt%20also%20recovers%20on%20RX%20FIFO%20overflows%20by%20reinitiating%20reception.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3ESituation%20is%20different%20when%20using%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3CP%3E%3CFONT%20face%3D%22andale%20mono%2Ctimes%22%3E%3CSPAN%3EUSART_TransferReceiveNonBlocking()%3C%2FSPAN%3E%3C%2FFONT%3E%3C%2FP%3E%3CP%3E%3CSPAN%3Ewith%26nbsp%3B%3CSTRONG%3Exfer-%26gt%3BdataSize%26nbsp%3B%20%26gt%3B%201%3C%2FSTRONG%3E.%20For%20example%2C%20the%20receive%20callback%20inspects%20the%20RX%20FIFO%20level%20and%20if%20the%20RX%20FIFO%20level%20is%20%26gt%3B%201%2C%20it%20calls%26nbsp%3B%26nbsp%3B%3CFONT%20face%3D%22andale%20mono%2Ctimes%22%3EUSART_TransferReceiveNonBlocking()%20%3C%2FFONT%3E%26nbsp%3Bwith%20the%20exact%20number%20of%20bytes%20of%20in%20the%20RX%20FIFO%20to%20retrieve%20these%20bytes%20more%20efficiently%2C%20say%2010%20bytes.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EHowever%2C%20if%20the%20system%20is%20busy%20handling%20other%20interrupts%2C%20the%20RX%20FIFO%20might%20overflow.%20Then%26nbsp%3B%3CBR%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3CDIV%3E%3CDIV%3E%3CP%3E%3CFONT%20face%3D%22andale%20mono%2Ctimes%22%3E%3CSPAN%3Evoid%3C%2FSPAN%3E%20%3CSPAN%3EUSART_TransferHandleIRQ%3C%2FSPAN%3E%3CSPAN%3E(%3C%2FSPAN%3E%3CSPAN%3EUSART_Type%3C%2FSPAN%3E%3CSPAN%3E%20*base%2C%20%3C%2FSPAN%3E%3CSPAN%3Eusart_handle_t%3C%2FSPAN%3E%3CSPAN%3E%20*handle)%3C%2FSPAN%3E%3C%2FFONT%3E%3C%2FP%3E%3CP%3E%3CSPAN%3Eclears%20the%20RX%20FIFO%20overflow%20bit%2C%20empties%20the%20FIFO%20and%26nbsp%3B%3C%2FSPAN%3E%3CSPAN%3Ecalls%20the%20callback%20with%26nbsp%3B%3CSTRONG%3EkStatus_USART_RxError%3C%2FSTRONG%3E.%20All%20the%20bytes%20from%20the%20FIFO%20are%20therefore%20discarded%20and%20cannot%20be%20received%20any%20more.%3C%2FSPAN%3E%3C%2FP%3E%3C%2FDIV%3E%3C%2FDIV%3E%3CP%3E%3CSPAN%3EHowever%2C%20it%20does%20not%20reset%26nbsp%3B%3CSTRONG%3ErxDataSize%3C%2FSTRONG%3E.%20So%20the%20callback%20will%20not%20be%20called%20again%20until%20the%20number%20of%20bytes%20(in%20the%20example%20ten%20bytes)%20have%20been%20received.%20Until%20this%2C%20the%20receive%20mechanics%20hangs.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3EHow%20do%20you%20recover%20from%20this%20situation%3F%3C%2FP%3E%3CP%3E%3CSPAN%3EResetting%20the%20dataSize%20by%20calling%20%3CFONT%20face%3D%22verdana%2Cgeneva%22%3EUSART_TransferReceiveNonBlocking()%20%3C%2FFONT%3E%3CFONT%20face%3D%22helvetica%22%3Ewith%3C%2FFONT%3E%20%3CFONT%20face%3D%22verdana%2Cgeneva%22%3Exfer-%26gt%3BdataSize%20%3D%201%3C%2FFONT%3E%3C%2FSPAN%3Edoes%20not%20work%20as%20the%20receive%20mechanics%20is%20still%20in%20status%26nbsp%3B%3CSPAN%3EkUSART_RxBusy.%3C%2FSPAN%3E%3C%2FP%3E%3CBR%20%2F%3E%3CP%3E%3CSTRONG%3ESo%20I%20wonder%20what%20is%20the%20proper%20way%20to%20handle%20RX%20FIFO%20overflows%20with%20the%20SDK%20drivers.%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3EThanks.%3C%2FP%3E%3CP%3EDaniel%3C%2FP%3E%3CBR%20%2F%3E%3CP%3EPS%3A%20sorry%20for%20the%20strange%20text%20formatting.%20I%20tried%20to%20markup%20code%20so%20it%20is%20easier%20to%20read%20but%26nbsp%3Bscrewed%20up.%3C%2FP%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E