UART Data coming in faster than I expect - K10

[ignisuti]

I'm creating a UART driver and had intially disabled the FIFO buffers at first. I was only receiving the first of 5 bytes of data.

I eventually decided to try and enable the FIFO buffers and find that ALL of the expected 5 bytes are present during my first interrupt. 

How can this be if I'm running my core clock at 100MHz? My MCU should be fast enough to get the interrupt after the first byte, pull the byte out of the buffer, increment the counter, and then go about it's business long before the 2nd byte arrives. Am I wrong here?

Note: I'm using UART 1.

[ignisuti]

Also... I'm using baud rate of 115200.

[rhyttr]

I had same problem before, cause i do something delay (eg. printf) in interrupt, so the next interrupt can not trigger

just remind you 

[mjbcswitzerland]

Hi

Have you tried changing the receive watermak register setting to configure how many bytes need to be received before an interrupt is generated?

Regards

Mark

[ignisuti]

Hi guys. Thanks for the suggestions.

I removed all printf statements from my interrupt to test, but that did not correct things.

Also, I have my RXWATER set to 1.

What else can I check?

[comsosysarch]

Do you have any very large temprorary variables declared inside the ISR?

[ignisuti]

Nope...

Now, I did come across something that looks suspect. There are a lot of printf commands processing in the background which the debugger is using to show data in the CW 10.2 terminal. 

Those printf commands seem to be super slow. I can watch the text being typed in the terminal. 

Maybe that's blocking/delaying so much that my interrupt isn't triggering fast enough... Any thoughts on this theory?

[TomE · Accepted solution]

> Any thoughts on this theory?

The first time I say a debugger connected through the debug port with a window showing the results of "printf()" I had no idea how it could be doing that, so I looked further.

For this system (a long time ago on an MPC860) the debugger setup "secretly" put a breakpoint on a function deep in the printing code. The embedded printing code printed to a named ram-based buffer then called the function with the breakpoint on it. The CPU *STOPPED*, the debugger special-cased that breakpoint to mean "don't tell the user, just read the buffer, show in the window and then continue".

All this debugger interaction took a long time - like 1/2 second or more. With the CPU halted for all that time it can't do anything "real time".

is your one doing the same thing? If you need any "real time response" you can't have any of this sort of debugging. it may be time to replace it with printing to a real buffered and interrupt driven serial port, to a network connection, a file system or to a HUGE RAM-based print buffer that you look at later.

Tom

[ignisuti]

TomE,

Yes, that sounds exactly like what's going on. I was seeing huge BLOCKING delays in the neighborhood of seconds.