Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
782 Views

JTAG USB dropping data when printing to terminal

I've got a system setup to print out ADC samples via a NIOS processor (standard) and JTAG USB. The ADC samples at 48Khz and the samples are streamed to the NIOS processor to be printed through PIO. However, samples are dropped and skipped without any pattern.  

 

I've done some tests with a 1Khz clock generating some values counting from 0 to 100, and printing to terminal drops data. 1Hz, 10Hz, and 100Hz clock all work but anything 1Khz and above results in dropped data. I've tried using printf(), alt_printf(), and putchar() but it still drops data. 

 

Does anyone know what the problem is or how I can fix it?
0 Kudos
7 Replies
Highlighted
Valued Contributor III
2 Views

The JTAG uart isn't a very fast interface, so you are probably reaching its limit. 

It isn't very easy to do a custom USB endpoint on the development kits, so if you have lots of data to stream it could be a good idea to use an interface such as Ethernet to transmit it to the PC.
0 Kudos
Highlighted
Valued Contributor III
2 Views

Generating counter data (ie just a for loop counting up to 1000) inside the C program and then printing it out via alt_printf() and JTAG USB shows no speed issues (no drops or jumps or stutters when printing to terminal). Only when data is transferred from the FPGA/Verilog system through the PIO to NIOS does data loss occur.

0 Kudos
Highlighted
Valued Contributor III
2 Views

The thing is that writing to the JTAG UART takes some time, especially once the hardware buffer is full, and the driver needs to wait until there is room again to write. You don't see that when you do a loop because the driver is configured to wait. 

What could happen in your case is that the software misses some samples because it is waiting in the JTAG UART driver.
0 Kudos
Highlighted
Valued Contributor III
2 Views

Increasing the JTAG UART buffer from the default 64 bytes to 8192 bytes shows no difference. Changing from a NIOS/s to NIOS/f processor causes the same numbers to be repeated every time (ie they are never updated as shown below): 

 

1hz 10hz 100hz 1khz 10khz 100khz 1Mhz 27Mhz 50Mhz C counter 74 24 40 96 40 95 33 18 37 1 74 24 40 96 40 95 33 18 37 2 74 24 40 96 40 95 33 18 37 3 74 24 40 96 40 95 33 18 37 4 74 24 40 96 40 95 33 18 37 5 74 24 40 96 40 95 33 18 37 6 74 24 40 96 40 95 33 18 37 7 74 24 40 96 40 95 33 18 37 8 74 24 40 96 40 95 33 18 37 9 74 24 40 96 40 95 33 18 37 10 74 24 40 96 40 95 33 18 37 11 74 24 40 96 40 95 33 18 37 12 74 24 40 96 40 95 33 18 37 13 74 24 40 96 40 95 33 18 37 14 74 24 40 96 40 95 33 18 37 15 74 24 40 96 40 95 33 18 37 16  

 

NIOS/s, 8192 JTAG UART buffer: 

1hz 10hz 100hz 1khz 10khz 100khz 1Mhz 27Mhz 50Mhz C counter 39 83 9 92 0 97 54 96 76 1991 39 83 9 93 16 53 16 85 2 1992 39 83 9 94 19 86 47 97 5 1993 39 83 10 95 35 44 28 97 79 1994 39 83 10 96 39 80 83 49 70 1995 39 83 10 99 67 55 41 53 37 1996 39 83 10 99 70 91 95 68 56 1997 39 83 10 101 95 28 75 52 0 1998
0 Kudos
Highlighted
Valued Contributor III
2 Views

Increasing the JTAG UART buffer will only delay the inevitable. It will be faster at the beginning, but once the buffer is full you will again be limited by the UART's low speed. 

Changing the Nios to a faster core probably won't have any effect since the speed limitation is from the hardware and not the CPU. The problem with the constant values could come from a data cache problem.
0 Kudos
Highlighted
Valued Contributor III
2 Views

So it looks like the only solution is to switch to regular USB instead of JTAG USB? I noticed that Terasic provides a demonstration project using the Device USB port on the DE2 board so I'll take a look at that.

0 Kudos
Highlighted
Valued Contributor III
2 Views

Yes I think you should switch to a faster interface that would be more adapted to this bandwidth, either plain USB or Ethernet.

0 Kudos