UART intterup stop working

HI,

Thanks for your post.

In order to respond to your request, we need certain details to move forward.

1. Are your using TI LCDK/EVM board or your own custom board?

2. If TI board, Which software package like starterware/CSL/BSL/BIOS SDK are you using?

Your UART0 interrupt is mapped to event #38 which is fine. But as you say, IPEND remains zero, there could be situation where IPEND would be forced to 0 when any of the high priority interrupt sources are not cleared.

In UART, there are different interrupt types and ofcourse, receiver line status would be serviced with highest priority followed by, receiver data-ready& receiver time-out and transmitter holding register empty. We recommend you to ensure the priority of interrrupt sources and interrupt type, sothat, you could find a way to clear all pending interrupts.

For more details, please refer Table 30-11 & 30-5 and Section 30.2.8 in the c6748 TRM as below:

http://www.ti.com/lit/ug/spruh79a/spruh79a.pdf

Please check the status of interrupt ID (INTID) in IIR register to know the interrrupt type and ensure whether FIFO enabled or not. Also, check the priorities of interrupts configured in the code.

Do you see any overrun or parity or framing error status if your interrupt type is receiver line status?

Do you see any trigger level reached if FIFO enabled if your interrupt type is receiver data-ready or any receiver time-out condition?

Do you see any Tx. FIFO empty condition if your interrupt is THR empty?

Kindly ensure the interrupt pending status condition on any of the above probable usecases.

Thanks & regards,

Sivaraj K

----------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

----------------------------------------------------------------------------------------------------------

Hi ,

Thanks for the answer,

Regarding your replay :

1. Are your using TI LCDK/EVM board or your own custom board? - NO - It is our own board with our own software.

2. If TI board, Which software package like starterware/CSL/BSL/BIOS SDK are you using? - NO - see (1)

When the UART stop working , I halted the CPU and looked at the registers.

The IPEND was 0  (meaning pending) , FIFO enabled ,with Receiver Line Status ON and in the LSR there is an indication of an overrun. That is exactly what I expect when the UART stop working. I have an external device which is transmitting data to me and my UART interrupt stop working (stopped getting into the interrupt service routine) so I am not reading data from the FIFO and therefore there is a situation of an overrun. In my code , In my service routine , I do deal with all cases of Receiver line Status and clear all error if needed.

What I still do not understand , and please correct me if I am wrong , If the IPEND is in pending state , than when I get out of the interrupt service routine , I should get into it again , Isn’t it ? Or In other words as long as EVENT #38 has not been cleared , I should return to the interrupt service routine until cleared. (very similar to a level interrupt….).

Thanks ,

Eran.

Eran,

The most likely answer is that you are not properly servicing and clearing all of the event flags in the Event Combiner. You can download and study the interrupt source code in software packages mentioned above (whichever are provided for the C674x) and the TMS320C674x DSP Megamodule Reference Guide for more information.

The easiest solution will be to move the UART0 event to a dedicated interrupt to the DSP instead of going through the Event Combiner.

TI has already debugged the software we provide. These are made available to you so you can avoid situations like this one. At the least, you can use these as an example or copy portions into your code as needed. I do not know an exact filename to tell you, but you may find some experience of others by searching this E2E Forum for keywords like EVTFLAG.

It is very difficult to debug custom code, so we provide the libraries to allow you to avoid this class of problem.

Regards,
RandyP

Hi  Randy ,

Thanks for the replay.

I am not using the event combiner.

As I wrote , I am using event 38 on  INT4. without the combiner. All the configuration is done with the CCS5 gui.

thanks ,

Eran

Hi ,

I also so that in http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/274366.aspx someone has the same thing.

Was the problem cause found ? (Because polling the registers as the "workaround" suggested in that post is not prefferable).

Thanks ,

Eran.

Eran,

Since you mentioned the DSPINTC0 Event Combiner registers, I mistakenly assumed you were using the Event Combiner. It appears now that those registers have no relevance, other than indicating that the event occurred at least one time; this assumes you are not clearing those bits in your ISR.

Since I already made that mistake in assumptions, please clarify that you are using the CCSv5 GUI to enable your interrupts but you are not using any of the TI software. Is that a SYS/BIOS GUI? Are you using SYS/BIOS but not the BIOS SDK?

If that is true, then please build a version of your project using the BIOS SDK for the UART and see if you get different results. I assume that there is a BIOS SDK since it was brought up earlier by Sivaraj. The other thread you referenced used Starterware and then switch to BIOS and solved his problem by changing task priorities.

Lower your baud rate by at least /4 or /8 and see if you still get the errors. This will tell you if it is logic related or timing related.

If the problem is timing related, then you need to improve the performance of your code. That might happen by using some of the TI libraries that we have mentioned, or by letting the compiler optimize the code better, or by using the built-in FIFO differently, or by minimizing what is done in the ISR, or by moving when interrupt-hardware-related code executes within the ISR.

If the problem is logic related (it still happens at the much slower speeds), then you should also try using some of the TI code to see if you can make the problem go away. Then you can examine the differences to see how to modify your own code if you want to return to it.

Regards,
RandyP

Hi Randy ,

I am using only SYS/BIOS with SYS/BIOS gui. all other code/drivers are our own code (there is no use of any SDK).

I don’t think it is a performance issue as correct logic should deal with any situation. (It happens in 921600bps and also in 115200bps) 

I am just trying to understand the behavior of the UART inside the DSP. If the IPEND is in PENDING state than what happens? Is it like a Level interrupt which means that until it is not cleared it should return to the interrupt procedure or is it a trigger interrupt which means that it is only happens once for each event? (As I know from other processors and UART chips, the UART interrupt is a level interrupt).

Thanks ,

Eran.