01:10 <Guest42> Hi all, I'm currently using the imx-native bitbang interface to flash a target via JTAG. I can find the JTAG TAP of the target when I reduce the adapter speed to 100KHz or less. This speed is too slow to properly perform flash operations successfully, but when I attempt to increase the adapter speed I get a "Warn : Invalid ACK 0x6 in JTAG-DP

01:10 <Guest42> transaction" or a "Error: IR capture error at bit 6, saw 0x81 not 0x...3" error.

01:10 <Guest42> I have the IMX6UL set to operate at 528MHz as specified in the imx-native.cfg in which the speed coefficients are already calibrated to the IMX6UL at 528MHz. Will this require altering the speed coefficients in some way or would anyone know how to resolve this kind of issue?

02:32 <Guest42> Would this potentially indicate a signal integrity issue or mean that the IMX6 is too slow?

02:32 <Guest42> Any insight would be very much appreciated.

08:12 <PaulFertser> guest42: hi

08:13 <PaulFertser> guest42: do you have any line termination in your connections?

08:13 <PaulFertser> guest42: do you have an oscilloscope to check how the signals look and how fast they are?

18:22 <guest> PaulFertser I do not have line terminations. That is something I will go ahead and add. I have a logic analyzer that I have been using to investigate the signals and they look clean to me. I'll send a screenshot of how they look. Also, for what it is worth, I was able to use a RPi4's GPIO to the target and successfully was able to connect to the

18:22 <guest> target at higher adapter speeds and perform the flash operations. That setup was also with no line terminations.

18:28 <guest> Here is a screenshot of the capture of the IMX6 to the target at a lower speed in which it was able to connect to the target (adapter speed 100khz):

18:28 <guest> https://freeimage.host/i/HCirABt

18:29 <guest> And here is a screenshot of the capture of the IMX6 to the target at a higher speed in which it does not work(500khz):

18:29 <guest> https://freeimage.host/i/image.HCir63g

18:30 <karlp> a logic analyser will always "look good" because it pretends everything's square, but it's not a good representation of what the other device is actually seeing.

18:31 <karlp> those captures are zoomed way too far out to see anythign meaningufl anwyay.

18:33 <guest> Fair point, I'll take a look at an analog capture and see if anything looks unusual.

18:37 <PaulFertser> guest: different SoCs have different drive strength sometimes.

18:37 <PaulFertser> guest: usually JTAG adapters have like 47 -- 100 Ohm in series on each data line.

18:37 <PaulFertser> (and maximum drive strength)

19:17 <guest> After doing an analog capture, it seems pretty clear that it is a signal integrity issue.

19:17 <guest> Here is what the signals look like at 500khz speed: https://freeimage.host/i/HCs3M4n

19:17 <guest> And at 100khz: https://freeimage.host/i/HCsFjKF

19:17 <guest> I'll go ahead and add termination resistors and see if that resolves things. Thanks!

21:40 <karlp> well, it gets the same clock pulses at least?

21:40 <karlp> what on earth are you using that's giving uyou +- 10V ranges for what's a, 3.3 at best range signal?

21:41 <karlp> that's horrible :|

23:03 <maribu[m]> Hi. I have been fighting hard to flash a CC2650 with an XDS110 with OpenOCD. It worked just find the first time, but it failed for every subsequent try. (The config it is trivial as it gets: It sources interface/xds110.cfg, then sets the adapter speed and selects JTAG, then sources target/ti_cc26x0.cfg.)

23:07 <maribu[m]> I could reproduce the behavior with two different boards. I updated the XDS110 firmware. I am almost sure that connecting under reset would fix the issue. However, any sort of reset_config that is not none results in bad things to happen. I believe that a correct reset sequence does require some extra magic due to the ICEPick, but I have now idea what exactly is needed. Any suggestion how I can actually connect unter reset?

23:09 <maribu[m]> (I am using a fairly recent (last commit from the 15th of November 2022) version of OpenOCD build from source, rather than an official release or release candidate.)