On Thu, Apr 7, 2011 at 1:09 PM, Laurent Gauch <laurent.ga...@amontec.com> wrote: >> >> >/ <drasko.draskovic at gmail.com >> > <https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: >> />>/ Hi all, >> />>/ I have one general question regarding OpenOCD scans. >> />>/ >> />>/ What happens when we set some field.in_value = NULL, and in reality >> />>/ there are some bits that re shifted out on the scan chain ? Are they >> />>/ just ignored ? Does that pose the problem ? >> />/ >> />/ This tells the JTAG drivers to throw away the bits that are clocked in >> />/ (read from the TAP). The target hardware/TAP does not see a >> difference. >> />/ >> />>/ To give a concrete example, in the mips_ejtag.c we have something >> like : >> />>/ >> />>/ /* fastdata 1-bit register */ >> />>/ fields[0].num_bits = 1; >> />>/ fields[0].out_value = &spracc; >> />>/ fields[0].in_value = NULL; >> />>/ >> />>/ /* processor access data register 32 bit */ >> />>/ fields[1].num_bits = 32; >> />>/ fields[1].out_value = t; >> />>/ >> />>/ if (write_t) >> />>/ { >> />>/ fields[1].in_value = NULL; >> />>/ buf_set_u32(t, 0, 32, *data); >> />>/ } >> />>/ else >> />>/ { >> />>/ fields[1].in_value = (uint8_t *) data; >> />>/ } >> />>/ >> />>/ So, no values are received (because fields[0].in_value = NULL and >> />>/ fields[1].in_value = NULL), but in reality MIPS EJTAG shifts out 33 >> />>/ bits (one SPrAcc and 32 bits of DATA) upon this operation. >> />>/ >> />>/ My question is, in general, could not accepting these bits lead to >> />>/ some problems or collisions on data lines (or USB bus) ? >> />/ >> />/ The bits are simply ignored rather than stored in memory. The >> />/ protocol or target hardware is not affected as such. >> / >> Thanks Øyvind, >> this is what I thougth... >> >> Is there a special reason why not ignoring one bit, like : >> fields[0].in_value = &spracc_in instead fields[0].in_value = NULL in >> previos example gives : >> downloaded 361540 bytes in 182.220215s (1.938 KiB/s) in the place of >> previous downloaded 361540 bytes in 182.220215s (1.938 KiB/s) when >> fields[0].in_value was ignored (NULL) ? >> > > both 361540 bytes in 182.220215s ??? please correct.
Whoops, sorry... Without reading in SPrAcc bit (fields[0].in_value = NULL) I can obtain up to : 182.220215s (1.938 KiB/s). However, when I read it in (fields[0].in_value = &spracc_in) I get : downloaded 361540 bytes in 12.489729s (28.269 KiB/s) Note that jtag_execute_queue() is called in both cases. Not calling jtag_execute_queue() (which also implies ignoring the SPrAcc bit) get us bigger throughput (but this is expected and no surprise : downloaded 361540 bytes in 4.989900s (70.756 KiB/s) So, as you see, my main interest is the difference between 12.489729s when in_value ignored and 182.220215s when it is clocked in memory. This difference is way too big. While jtag_execute_queue() latency can not be avoided if we want to do the status check on the shifted-out bit, this additional latency just to write shifted-out bit in memory is really suprising for me... > If you do not need to read TDO please use fields[0].in_value = NULL , ever ! Yes, off course. It can prevent segfaults, unless you correctly allocated placeholder in the moment of queue execution. I just tried here to do the tests. BTW. SPrAcc bit should be read, if we want robust implementation. > If you use fields[0].in_value = &spracc_in instead fields[0].in_value = > NULL, the communication USB to Amontec JTAGkey dongles could be slower, > because the TDO must be returned back to host computer, and more USB access > will be generated. Difference is pretty big - 12s versus 182s. Is this normal and expected ? BR, Drasko _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
