CCS/TMS570LS3137: Three questions about SCI receive interrupt, CAN transmission interrupt, GIO interrupt

Hello Maxr,

Sorry for the delayed response. The first thing I would check with your application is how much of the actual work is being done in your ISRs. i.e., how much time is spent in the ISRs servicing the requested function? In general, the best use of ISRs is to get in, clear the IF, set a flag or move some data, then get out. There shouldn't be any long drown out data processing in these interrupts.

Do you have any type of profile of the timing of your interrupts and the bandwidth they are consuming? The issues you are seeing are indicative of interrupts firing when another interrupt is being serviced so this should be checked to make sure the ISR is available when needed.

In regard to the GIO interrupts, you can select interrupt on rising, falling or both edges. What functionality are you looking to gain with regard to level triggered that cannot be achieved with the edge triggered modes provided?

Hi Chuck Davenport,

Thanks for your response.

1、SCI
I have found that some higher priority interrupt may delay the SCI interrupt. So I upgrade the priority of SCI interrupt to FIQ simply by HALCoGen configuration. And Overrun-error interrupt is not generated in a long time.
However, transmission problem is still left behind.
In fact, I have fixed a mistake:
Before moving a byte to the SCITD register in main process, to start a new package data transmission, I must check the TX EMPTY bit, instead of checking the TXRDY bit. When TX EMPTY bit is 1, transmitter buffer and shift registers are both empty. That means SCI is free for a new package transmission. When TXRDY bit is 1, SCITD is ready to receive the next character. That doesn't mean the end of last package transmission.
Additionally, all package datas are saved in a ring buffer befor transmission. And before moving a byte to the SCITD register in main process, I disable the transmission interrupt to avoid the competition of accessing the data buffer.
After this modification, transmission error has reduced, but sometimes there is still a loss of data. For example,a package data losts one byte.
Is there anything else I need to pay attention to when operating SCI ?

2、DCAN
The DCAN transmission process I using is similar to SCI.
I'm afraid that checking of Tx Message Pending using Transmission Request X Register, is not enough, before starting a new package data transmission in main process. That doesn't mean DCAN is free for a new package transmission.
I'm confused how to get the end state of the last package transmission, like checking the TX EMPTY bit in SCI.

3、GIO
The level of the GIO interrupt pin is controlled by an external chip. The pin goes to high level, only if there are no soures of interrupt on external chip. TMS570 clears the external chip interrupt state in ISR via SPI communication. The interrupt pin may remain low level, if ISR goes out and new soures of interrupt on external chip are generated before the pin going to high level. This mains falling edge interupt will never generated.

Hello Maxr,

maxr said:

1、SCI
I have found that some higher priority interrupt may delay the SCI interrupt. So I upgrade the priority of SCI interrupt to FIQ simply by HALCoGen configuration. And Overrun-error interrupt is not generated in a long time.
However, transmission problem is still left behind.
In fact, I have fixed a mistake:
Before moving a byte to the SCITD register in main process, to start a new package data transmission, I must check the TX EMPTY bit, instead of checking the TXRDY bit. When TX EMPTY bit is 1, transmitter buffer and shift registers are both empty. That means SCI is free for a new package transmission. When TXRDY bit is 1, SCITD is ready to receive the next character. That doesn't mean the end of last package transmission.
Additionally, all package datas are saved in a ring buffer befor transmission. And before moving a byte to the SCITD register in main process, I disable the transmission interrupt to avoid the competition of accessing the data buffer.
After this modification, transmission error has reduced, but sometimes there is still a loss of data. For example,a package data losts one byte.
Is there anything else I need to pay attention to when operating SCI ?

to understand what is going on you will need to understand what is happening causing the data to be lost. i.e., is it an interrupt priority issue or a latency issue in servicing the received data. As I have mentioned previously, you would usually need to spend as little time in the interrupt as possible. i.e., move the data to the buffer and re-enable the interrupt and get out. To accommodate this approach, your ring buffer would need to be large enough to keep up with the data stream. Generally, a good way to test this is to set up a simple PC application to send data repeatedly to the MCU. The data stream should be a simple count or some other pattern that would allow you to see the bytes and detect dropped data. i.e., 0-9, 9-0 repeat pattern. Note that this is further complicated when other interrupts and data streams are also going on such as CAN so this needs to be taken into account in your application.

maxr said:

2、DCAN
The DCAN transmission process I using is similar to SCI.
I'm afraid that checking of Tx Message Pending using Transmission Request X Register, is not enough, before starting a new package data transmission in main process. That doesn't mean DCAN is free for a new package transmission.
I'm confused how to get the end state of the last package transmission, like checking the TX EMPTY bit in SCI.

Yes, CAN is a different animal due to the arbitration and the multi-node bus. DCAN has to make sure it is clear to send before transmitting. The TxOK bit in the DCAN ES register. It can be tied to an interrupt as well using the SIE (Status change interrupt enable). bit in the DCAN CTL register.

maxr said:

3、GIO
The level of the GIO interrupt pin is controlled by an external chip. The pin goes to high level, only if there are no soures of interrupt on external chip. TMS570 clears the external chip interrupt state in ISR via SPI communication. The interrupt pin may remain low level, if ISR goes out and new soures of interrupt on external chip are generated before the pin going to high level. This mains falling edge interupt will never generated.

Level triggered interrupts are not supported on Hercules devices. You could use some combination of the edge triggered interrupts and the RTI counter to look for a falling edge when an interrupt is cleared via SPI command. i.e., once you issue the SPI command, there is a specified amount of time that the signal to the GPIO would be raised. If after that specified time, it doesn't, you could assume a second interrupt had been signaled and jump to your handler. This all depends on your latency requirements and how quickly you would need to service it.