This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Correct handling of UART overrun error

Hello,

I'm using a LPC2478. I have a little problem with handling a UART buffer overrun error only during debugging. when the program is stopped on a breakpoint several times, and the line status register indicates "overrun error", reseting the contents of the RX FIFO (it is 8 byte long) causes CTI interrupts to start bombarding the system so often than it becomes inert. If I do not reset the contents of the RX FIFO debugging is possible. Note that when it goes wrong, I do not see any traffic on the serial bus (it is a RS485). Can you help me explain this?

Tamir

  • Debugging with breakpoints is usually intrusive in respect to the peripherals. The ARM core is stopped when you hit a breakpoint however what happens with peripherals depends on the silicon vendor (integration of the core with peripherals). Majority of peripherals are usually still running also when the core is stopped (some chips like STM32 have special debug registers which configure for some peripherals what happens when the core is stopped).

    As far as I know the LPC2xxx peripherals will continue to run also when the core is stopped. This can lead to debugging side effects which alter the behavior of the application being debugged. So you should keep this in mind and not be surprised if the application behaves differently when debugging with stopping the core.

    Alternative would be to use a monitor program like RT Agent which allows to access memory even while the core is running (Cortex-M offers this by default - no monitor required).

  • Tamir,

    I realize you probably read up on this, and I may be missing your point/question, but I'll post this anyway...

    On page 430 of:
    www.nxp.com/.../UM10237_3.pdf

    CTI is explained, and it looks like you need to flush the FIFO buffer anyway.

    As far as 'proper operations' when you are in a debug mode, and break-points are hit, a lot of micros will act/function differently than the specifications indicate. For that reason alone, it is hard to 'explain' why this is occuring without knowing the chip's guts. If this is a really big problem, try asking NXP about it: hopefully you can get through to one of their LPC2478 experts.

    --Cpt. Vince Foster
    2nd Cannon Place
    Fort Marcy Park, VA