On Mon, Feb 3, 2020 at 4:18 PM Antonio Borneo <[email protected]> wrote: > > On Mon, Feb 3, 2020 at 3:58 PM Leonard Crestez <[email protected]> > wrote: > > > > On 01.02.2020 10:02, Tomas Vanek wrote: > > > On 01.02.2020 1:38, Leonard Crestez wrote: > > >> Hello, > > >> > > >> It seems that calling "adapter deassert srst" from TCL does not flush > > >> the jtag queue, is this intentional? It is extremely confusing and if > > >> this is motivated by performance the benefit seems low. > > >> > > >> I was adding support for a new board and assumed that "adapter > > >> assert/deassert srst" should reset the board and spent quite a while > > >> assuming by signal config was wrong. > > >> > > >> * Running "poll" after "deassert" can fix the issue. > > >> * Calling "jtag_set_signal nSRST 0/z" directly works. > > >> > > > Leonard, > > > > > > could you check if > > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenocd.zylin.com%2F5405&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cc9e6c6969d184a0848fe08d7a6ed12c5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637161409462276269&sdata=26ucyz3mq%2BFP0ecFp4iRufIWLaCFXstvF25X32r9vq4%3D&reserved=0 > > > solves the problem? > > > > That patch does not solve my problem. > > > > This is with an on-board FTDI interface > > (http://openocd.zylin.com/#/c/5426/) but an external olimex adapter > > shows the same issue. My board does not have a TRST line connected. > > > > To reproduce I run with the following arguments: > > > > openocd -c $MYSETUP -d4 -c init -c 'poll off' -c 'adapter assert srst' > > -c 'after 100' -c 'adapter deassert srst' > > > > And log ends with the following: > > > > Debug: 15131 288 command.c:143 script_debug(): command - adapter adapter > > deassert srst > > Debug: 15133 288 mpsse.c:643 mpsse_set_data_bits_high_byte(): - > > Debug: 15134 288 mpsse.c:458 buffer_write_byte(): 82 > > Debug: 15135 288 mpsse.c:458 buffer_write_byte(): 0b > > Debug: 15136 288 mpsse.c:458 buffer_write_byte(): 0b > > Debug: 15137 288 mpsse.c:643 mpsse_set_data_bits_high_byte(): - > > Debug: 15138 288 mpsse.c:458 buffer_write_byte(): 82 > > Debug: 15139 288 mpsse.c:458 buffer_write_byte(): 03 > > Debug: 15140 288 mpsse.c:458 buffer_write_byte(): 0b > > Debug: 15141 288 mpsse.c:858 mpsse_flush(): write 9, read 0 > > Debug: 15142 288 mpsse.c:832 write_cb(): transferred 9 of 9 > > Debug: 15143 288 mpsse.c:834 write_cb(): 82 03 0b 82 0b 0b 82 03 0b > > Debug: 15144 288 ftdi.c:525 ftdi_reset(): reset trst: 0 srst 0 > > Debug: 15145 288 mpsse.c:643 mpsse_set_data_bits_high_byte(): - > > Debug: 15146 288 mpsse.c:458 buffer_write_byte(): 82 > > Debug: 15147 288 mpsse.c:458 buffer_write_byte(): 01 > > Debug: 15148 288 mpsse.c:458 buffer_write_byte(): 0b > > Debug: 15149 288 ftdi.c:553 ftdi_reset(): trst: 0, srst: 0 > > Debug: 15150 288 core.c:830 jtag_add_reset(): SRST line released > > Info : 15151 288 server.c:311 add_service(): Listening on port 26666 for > > tcl connections > > Info : 15152 288 server.c:311 add_service(): Listening on port 24444 for > > telnet connections > > Debug: 15153 288 command.c:143 script_debug(): command - init init > > > > As far as I can tell this just puts the "82 01 0b" in the queue but does > > not send it to the FTDI adapter. It works if I call `jtag_set_signal > > nSRST z` directly because internally it always does mpsse_flush. > > > > Debug: 14595 283 command.c:143 script_debug(): command - ftdi_set_signal > > ftdi_set_signal nSRST z > > Debug: 14597 283 mpsse.c:626 mpsse_set_data_bits_low_byte(): - > > Debug: 14598 283 mpsse.c:458 buffer_write_byte(): 80 > > Debug: 14599 283 mpsse.c:458 buffer_write_byte(): d8 > > Debug: 14600 283 mpsse.c:458 buffer_write_byte(): 0b > > Debug: 14601 283 mpsse.c:858 mpsse_flush(): write 3, read 0 > > Debug: 14602 283 mpsse.c:832 write_cb(): transferred 3 of 3 > > Debug: 14603 283 mpsse.c:834 write_cb(): 80 d8 0b > > > > I can fix my problem with the following patch: > > http://openocd.zylin.com/#/c/5429/ > > > > I don't know if this is the appropriate level for queue flushing. > > > > I'm surprised of this issue on FTDI. > I have prepared another patch, submitted as > http://openocd.zylin.com/5430 but now I have some doubts. > Let me check again with a FTDI > I prefer to not patch in jtag_add_reset() because it will flush the > queue twice on some drivers, but it should not be an issue anyhow. >
The issue is in ftdi driver. I'm sending out a patch for that .... Then will re-test all the other interfaces. Antonio _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
