Part Number: TMS320F28035-EP
Tool/software:
Our customer was performing systems integration and lost communication with our board. The customer captured a break detect event on the oscilloscope and showed it to us. Our board did not recover once the break detect condition went away.
Upon reviewing our firmware, we found we correctly checked and cleared comm errors:
interrupt void SCIRXINTA_ISR (void)
{
if(SciaRegs.SCIRXST.bit.RXERROR == 1)
{
//*****************
// Comm Error
// Don't care which
//*****************
SciaRegs.SCICTL1.bit.SWRESET = 0; // Toggle SW_RESET Low then high to clear flags
SciaRegs.SCICTL1.bit.SWRESET = 1; // and state machine.
SciaRegs.SCICTL1.bit.SLEEP = 1; // go back to sleep and wait for Idle
}
We tested our board in the lab using Windows driver commands to create a break detect condition:
PCAS_SerialPort.BreakState = true;
.. and then to remove the break condition.
PCAS_SerialPort.BreakState = false;
Running the firmware through the XDS 100v3 debugger, we placed breakpoints and observed the BRKDT, FE, and RXERROR flags being set and cleared correctly. We clicked the resume button (or F8) in Code Composer. Our Windows test GUI never generated time out errors when we sent commands to the board.
We cycled power to the board so it was no longer running in debug mode. We restarted the GUI and recreated the same break detect conditions as previously stated. Unfortunately, the board never recovered from the break detect condition and failed to respond to commands from the GUI. The GUI reported comm timeout errors.
Why did our board recover from a comm break when in the debugger environment, but fail to respond in real life?
Thank you,
