JTAG UART repeating characters on Cyclone IV Transciever Kit

[Altera_Forum]

I am not sure what is up ... I have tried JTAG_UART with interrupt and polling ( with small model ) and there doesn't seem much difference. 

If I fun printf("Hello\n"); ten times through a loop, the result is similar but not the same number of repeated characters.  HHHHHHHHHeeeeeeeeeeeeeeeelllllllllllllllllllllllllllllllloooooooo instead of Hello. It is like the JTAG UART is picking up extra but correct charaters. I have run memory tests and may try output to the LCD ... but I believe the data and text side of things are fine since the program execution is fine just the stdio via the JTAG UART seems to be problematic.  Any ideas ?  Thanks, Bob.  PS: I checked via the Eclispse Debugger the string constant "Hello" in memory and it looked fine .

[Altera_Forum]

I'm thinking this JTAG UART is similar to semi-hosting .. the stdio is directed to hardware buffers and the buffer is unloaded via the JTAG connection to Eclipse. If the characters get to the buffer correctly then repeating characters could be on the JTAG / Eclipse driver side.  

To debug I have tried reducing the buffer depth and threshold and changing from interrupt mode to polled mode.  I guess I can try to debug in Eclipse and see if the correct number of characters are delivered by the putc routing called from printf.  Th other thing I could do is to switch to a real UART and would like to use a "USB JTAG" conenction but don't think the Cyclone kit has such a facility ?  All the time I worked with Arria , the JTAG UART worked fine.

[Altera_Forum]

Check the stack isn't hitting the heap. 

printf() will use a lot of stack and it might all be going horribly wrong.

[Altera_Forum]

Thanks Dave, 

 I can check that in the debugger... Would you examine the stack pointer value as the printf progresses ? I am not familiar with all the debug hooks in Eclipse but for a JTAG debugger I would add a barrier or waypoint at the top of the stack to trap such a nasty event.  However, if there was such a collision I would expect more to go off into the weeds unless all I did was a single printf. I added the printf to a loop with an count value that I would expect was on the heap and I got the printf called the expected number of times  all with the similar but not identical signature of repeated characters.  To isolate this I really need to redirect the stdio to something apart from the JTAG UART, like a real UART. If I get the same result then I would say it is something more pervasive.  I have other variables on the heap that control the printf being called so I would expect them to be corrupted by a stack -> heap collision.   I also have a recursion test to load up the stack and I can try running that to see if bad things happen without calling printf.

[Altera_Forum]

I believe this was a weird "side-effect" of the wrong clock driving the JTAG_UART component. 

Looks to be back together now.  Thanks, Bob.