06:54 <Hammdist> through FT232H using openocd, is there a maximum size of JTAG DR shift that can be done in a burst without stopping the clock, and if so what is the approximate number of bits for this?

07:28 <Hammdist> maybe I should just use the additional signals on JTAGG module to do it proper

08:16 <PaulFertser> Hammdist: but the clock comes from FT232H so why would you care even if it's stopped for a little bit?

09:03 <Hammdist> in some setups the clock would be used to sample a stream of bits from a different clock domain. interruptions => bits lost => bad

09:05 <PaulFertser> Hm, ok. Not sure, guess you can easily just try doing e.g. drscan with 4096 bits and see it on oscilloscope to get first impression.

09:07 <PaulFertser> The buffer in RAM has 16384 bytes but how many are sent at a time and whether ftdi inserts any real pause I do not know.

12:22 <Hammdist> drscan gives no output. I loaded an svf file, is it possible that it has somehow disabled echoing of values to the terminal? if so, how to re-enable this?

13:18 <Hammdist> Info : JTAG tap: auto0.tap tap/device found: 0x41112043 (mfg: 0x021 (Lattice Semi.), part: 0x1112, ver: 0x4)

13:18 <Hammdist> Error: IR capture error at bit 3, saw 0x05 not 0x...3 <-- is this normal?

13:25 <Hammdist> PaulFertser: ^

13:26 <jancoow> mhm, any idea of the NVM rows are also wiped by chip erase on the atsaml?

13:28 <jancoow> PaulFertser also, seems that when locking the security bit, our magic cold plug thingy doesn't work and unable to chip erase

13:40 <Haohmaru> aww

13:40 <Haohmaru> maybe you need that openocd "10" with the special patch?

13:41 <Haohmaru> there is typically some calibration values in some areas of the NVM that should not be erased by chip erase, (at least on the other families it's like that)

13:42 <Haohmaru> hm, or maybe it wasn't

13:52 <Hammdist> so I found by accident that if I connect to openocd with telnet (rather than stuffing commands in cfg file) I actually get output from drscan

13:52 <Hammdist> but now the output from drscan is all zeroes when I expect it not to be

13:59 <PaulFertser> Hammdist: no, svf shouldn't affect any output of the other commands.

14:00 <PaulFertser> Hammdist: ir capture means it's reading the contents of IR and checking it against a mask, by default it's supposed to be exactly matching the JTAG standard.

14:00 <PaulFertser> jancoow: yeah, right, that's expected as we discussed.

14:01 <jancoow> PaulFertser ye

14:01 <jancoow> exactly

14:01 <jancoow> so probably becuase of the atmel ice

14:01 <PaulFertser> jancoow: not, just because it's really locked and you do not engage code to do real cold-plug.

14:02 <PaulFertser> jancoow: of course you do not need "openocd 10" but yes, there's a patch which was not properly finished which you can use for inspiration to make OpenOCD support cold-plug proper.

14:05 <Haohmaru> "0.10.0" or something

14:05 <Hammdist> now I've hardcoded the verilog on the FPGA to always produce 1s, like so: JTAGG prim(.JTDO1(1'b1)). yet when I do: svf ...; irscan auto0.tap 0x32; drscan auto0.tap 32 0; I still just get 0s out

14:05 <PaulFertser> Hammdist: yeah, I despise this idea of yours ;)

14:06 <PaulFertser> Hammdist: you have an LA handy? Probably it's indeed 0 there and there's a problem with some part of Verilog code, probably it's not really attached to JTAG pins or something.

14:07 <Hammdist> you sure that the device won't be reset between svf and irscan?

14:07 <Hammdist> when entered on a telnet session

14:08 <Hammdist> maybe there's an enable for the user JTAG somewhere that I have to enable. like in the lpf or ecppack or something could be

14:12 <PaulFertser> Hammdist: well, svf just plays back commands, what's inside your file you can see there. Nothing more.

14:13 <Hammdist> as usual it's all my fault then :)

14:20 <PaulFertser> Hammdist: having some tool to check what's there happening on the wire is always nice in cases like that for sanity-checking and being able to concentrate on digging in the right direction, hence why I asked about LA.

14:28 <Hammdist> have only digital multimeter. also no test points on my board so not easy to even connect the digital multimeter to anything

14:29 <Hammdist> actual command I am running in telnet: svf ./toplevel_test1.svf -tap auto0.tap ; irscan auto0.tap 50 ; drscan auto0.tap 32 0 ... I believe 50 is 0x32 which is correct for ER1 register on ECP5

14:33 <Hammdist> hm. haven't found any enable/disable bits for JTAG in LPF format or ecppack

14:36 <Hammdist> autodetected jtag settings did not match ulx3s config files. changing to match ulx3s settings

14:38 <Hammdist> ffffffff <-- nice

15:00 <PaulFertser> You can use 0x in Tcl for hex notation, no problem with that.

15:01 <PaulFertser> Hammdist: so you got the expected results now? What was the difference?

15:02 <Hammdist> the JTAG autodetection thing had resulted in recommending -irlen 3 for some reason and I didn't notice that's a bad thing

15:03 <PaulFertser> Oh that would explain strange effects.

15:03 <Hammdist> copying -irlen 8 from ulx3s project was the bulk of the fix (and -ircapture 0x5 also suppresses that error message I had pasted above)

15:03 <PaulFertser> You also see the right irlen inside the SVF file.

15:03 <PaulFertser> Probably it would be nice to have a warning when they mismatch.

20:32 <antto> ah sh*t, daplink firmware uses a RTOS, doesn't it