TMS320F28386D: CM lost a UART interrupt during CM FLASHAPI erasing flash

Hi Frederick,

Based on the function comments in uart.h, if UART_clearInterruptStatus() isn't called somewhere in the ISR, the interrupt will be triggered immediately upon exiting the ISR.  I think removing the clear function is masking another issue where your UART is getting out-of-sync in such a way that no additional RX occur.  I think the logical next step would be to leave that function in, but then examine the state of the UART module to determine if any of the error flags are set.  

Hi 

"but then examine the state of the UART module to determine if any of the error flags are set."

Which register should I check for the error flag? UARTRIS?

Thanks

Hi,

I check the UARTRIS in the last Rx interrupt and after the next interrupt missing, there is no error flag(no Error Raw Interrupt Status).

After the next interrupt missing, I pop each remain data(UART_readChar()) in the FIFO and read UARTRSR, there is no error flag too.

Any else register I can check for this status?

Thanks

Hi Frederick,

Sorry for the lack of specifics.  It looks like the errors would best be observed in the UARTDR or UARTRSR directly.  My interpretation of the UARTRIS register is that this would only show errors if they are explicitly enabled via the UARTIM register (enabling the error interrupts may also be an option, but I think if you don't see them directly, this is probably not very likely to provide additional information).

Some other avenues of debug:

• Where are the incoming messages coming from?  Have you confirmed via scope or logic analyzer that the messages are still coming in?
• Are you sure the messages are still getting from the RX pin to the UART module?  The main concern here would be that the GPIO settings have somehow been changed such that the GPIO mux is no longer routing the pin to the module.
• Any other settings have been changed in the UART module?  It may make sense to dump all the configuration registers (use the memory browser in CCS set to the base of the UART module, then save all the memory to a file, then save again and compare after running the flash API).
• Is the RX flag being set in the UART, but not propagating to the CPU?  This could be from an un-acknowledged flag in the CPU interrupt HW or from another interrupt continuously occurring and starving the UART ISR. 
• Is the ISR vector still mapped to the expected location in RAM? It would kinda make sense that ISR is intended to be mapped to RAM (copied from flash) but it actually ends up mapped to the original flash; thus it works until the flash is erased?  

Hi  Devin,

I can not find any abnormal in your suggest avenues.

I descript my reproduced steps below.

Does the below time sequence cause no next Uart Rx interrupt?

The initial Interrupt FIFO Level is 2.(UARTIFLS = 0x4)

1. The Rx FIFO had 13 bytes data.

2. The interrupt was triggered(more than 2 data in the FIFO).

3. In the interrupt handler, read UART_getInterruptStatus() and UART_clearInterruptStatus().

4. In the same interrupt handler, pop 2 bytes data from Rx FIFO(11 left), and set Interrupt FIFO Level to 8 (UARTIFLS =0x2).

5. return from the interrupt handler.

6. No next interrup triggered.( I think that 11 data in FIFO more than the level 8, it will trigger the next interrupt.)

Then my problem is reproduced after above. Does it make sense?

If it make sense, how can I fix my problem. For our program's efficacy, we need to pop 2 data from the FIFO first and pop the left data in the next interrupt. 

Thanks

Hi Devin ,

Ok, it 'no problem. It work perfectly.

Thank you.