UART and DMA and handling Framing Errors

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

UART and DMA and handling Framing Errors

Jump to solution
2,224 Views
ivekengineer
Contributor III

Does anyone know how to successfully clear out a framing error when using DMA? There are several posts in this community but no clear solution. I can't use any solution that would disable the UART as it is possible data will still be in process of being received (which would just create another framing error). I've sort of been able to clear out a framing error, but then I seem to end up with an underflow or overflow error. I know there is a race condition when using the DMA between the read by the DMA and the read of the D register when attempting to clear the S1 errors. I also know that if I disable DMA for too long, I can end up with an overflow error.

I am using a K10 part, but that doesn't seem to matter based on some of the other posts.

 

 

0 Kudos
1 Solution
2,220 Views
mjbcswitzerland
Specialist V

Hi

I use

 

 

// UART 0 error interrupt
//
static __interrupt void _SCI0_Error_Interrupt(void)                      // independent error interrupt handler
{
    // Used to clear framing error in DMA rx mode
    //
    (void)UART0_S1;                                                      // read the error source
    (void)UART0_D;                                                       // read the data register (resets the framing error flag which otherwise inhibits further reception)
    ulFrameingErrors[0]++;                                               // count the number of framing errors detected for statistic purposes
}

 

 

However framing errors can lead to various other problems since the reaction to the interrupt handler can be delayed (when the UART speed is fast - eg. 5Mb/s) and so also overruns take place in the meantime.

In the worst case multiple bytes can be lost, during which you need to keep clearing errors and overruns until the input is synchronised again (either when there is a gap between reception bytes or it gets lucky).

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1064.html

View solution in original post

0 Kudos
4 Replies
2,221 Views
mjbcswitzerland
Specialist V

Hi

I use

 

 

// UART 0 error interrupt
//
static __interrupt void _SCI0_Error_Interrupt(void)                      // independent error interrupt handler
{
    // Used to clear framing error in DMA rx mode
    //
    (void)UART0_S1;                                                      // read the error source
    (void)UART0_D;                                                       // read the data register (resets the framing error flag which otherwise inhibits further reception)
    ulFrameingErrors[0]++;                                               // count the number of framing errors detected for statistic purposes
}

 

 

However framing errors can lead to various other problems since the reaction to the interrupt handler can be delayed (when the UART speed is fast - eg. 5Mb/s) and so also overruns take place in the meantime.

In the worst case multiple bytes can be lost, during which you need to keep clearing errors and overruns until the input is synchronised again (either when there is a gap between reception bytes or it gets lucky).

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1064.html

0 Kudos
2,209 Views
ivekengineer
Contributor III

Hello Mark,

Thank you for replying - I'm not surprised since I saw you respond to so many of the other posts that are similar to this!

Using an interrupt is a good idea for the framing error as it allows me to have a single area of code that reads the S1 register. But, I think there is still a potential problem as there could be a race condition between the read of the D register, and the read by the DMA (if there is still an active request). However, it does seem that a framing error causes the UART to stop receiving data (which is my problem), so perhaps there won't be a DMA transfer that can occur at this point? I'm not so sure about this because the UART has an 8-byte FIFO and there could still be data in it. Also, I have been stepping through my existing code and it does seem to have a DMA read occurring after my read of S1 because my FE bit is being cleared before I read the D register.

Any thoughts about that?

0 Kudos
2,200 Views
ivekengineer
Contributor III

This seems to be working for me. But, I turned off my RXFIFO so I didn't have to deal with either an overflow or underflow on the FIFO. Since I am using DMA, those FIFOs aren't as necessary. Plus, some UARTs only have a 1-byte FIFO so this is a more universal solution when using DMA.

This works for me too because I'm not worried about losing some of the data around the framing error. I have application level things in place to deal with those things and I have a guaranteed gap in transmission at some point so everything can resynchronize.

0 Kudos
2,195 Views
mjbcswitzerland
Specialist V

Hi

That sounds good.
I don't think it makes any different whether you disable Rx Fifo operation or not since the DMA operation is fast enough to ensure that there will never be more that 1 byte in it anyway (if it weren't it would overrun when the Rx Fifo is disabled).
It is also true that until you have cleared the framing error there will be no more data received and thus no more DMA triggers.
Re-synchronisation is the potential issue but if there are gaps between data or sporadic reception this is usually not a problem since it means there is a "message loss" which can happen on any connection due to noise etc. and so a higher level protocol will typically be able to handle it without serious consequences.

Regards

Mark

 

 

0 Kudos