QG8 - SCI stops receiving bytes

[Yaw]

Hello group, I am developing a commercial product using the QG8 processor; some details I cannot discuss due to IP considerations.  The problem that we are experiencing is as follows:

-Using P&E USB Multilink debugger and CW 3.1 IDE

Following a seemingly random time frame of expected operation, the processor seems to no longer accept/receive bytes into it's internal RX buffer.  I have confirmed that when this problem occurs, data is in fact properly presented on the receive pin.  Other than the inability to receive bytes, all other operations are as expected (Physical interaction with the board and data transmission).  The processor recovers and exhibits normal behavior following a power cycle.

Thank you all in advance, I would appreciate any nudges in the right direction to resolve this issue.

[mke_et]

Whenever I have a problem with something even remotely associated with interrupts, I go back and closely examine my interrupt stream.

There have been so many times I've found what's best called a 'self race' condition that now I always write my ISRs with that consideration in mind.

The mindset I use is to write the ISR so that it always can occur for no reason at all, or for multiple reasons. The structure is to do all the EOI processing at the beginning of the routine. THEN fall into a loop that loops until there is nothing to do. If you do something, stay in that loop. So what if you have to loop 5 or 6 times to get out, even getting multiple characters. Finally, nothing is there to be done, but you have an interrupt pending. You get out, bang, another interrupt, but nothing to do and you fall through quickly.

The other thing I do, and again this is a personal thing, is try to limit what happens in the ISR. For comm stuff, I set up a ring buffer, and all the ISR does is set data into the buffer IF there is room. If not, throw it away and set an overflow flag.

Unless something is holding parts of my body to a painful object, I really resist trying to do any management or processing of data in the ISR. Get in, get it, get out.

Mike

[Yaw]

Hello all!  The problem we were encountering has been resolved.  The source of the problem was a case of nested interrupt calls (oops).  I have changed the program flow to take care of the issue and the problem has been resolved.  Thanks to all for the help, this forum has proved to be a great source of information!

[AlfredoRobles]

Hello: I have the same problem and I can not find solution. You could give more information? Thanks.

[allawtterb]

If you can't resolve your problem from information already posted, then it would be best if you started a new thread.  Make sure you post as much information about the problem and what you have already done to debug it up to this point.  Also make sure to include which exact device you are using.

[fabio]

Maybe you are forgetting to clear the error flags in the SCIS1 register. When a receive error occurs, the flags the corresponding error flags are set. Look the FE flag, because once set it prevents the SCI receiver from receiving new data.

Best regards,

Fábio Pereira

[Yaw]

Thank you for your prompt answers, I will perform tests using your suggestions to see how things go.  I'll report back when new developments occur. 

[tonyp]

We've been using QG8 SCI without any problems.

Things I'd check:

1. A subtle software bug.  Is the same SCI driver fully tested and known to work well in other applications?
2. Using internal oscillator with less than perfect trimming that ends up with a marginal baud mismatch tolerance.  It could be getting in and out of margin, and depending on the protocol used, you could either recover or get lost for good.  [We had to use an external oscillator just to be sure the SCI would always work OK.  A trimmed internal oscillator should work in theory if using the center frequency but in practice, trimming wasn't always very accurate for us (it might have been the tools we use)].