09:47 <Guest92> anyone with expierience on multicore debug, f.i iMX8mm5 with 4xA53 + 1xM4 ?

09:49 <PaulFertser> Guest92: some probably are, so you should probably ask your question right away. Also consider writing to the devel mailing list if you get no answer here.

10:28 <karlp> or not then :)

19:12 <elSegundo> Hi all, I reached out to this chat a few weeks ago regarding the imx-native bitbang interface. I was having issues connecting to a target when using an adapter speed greater than 100KHz with 100KHz even not working occasionally. I performed a variety of GPIO configuration changes such as high slew rate, max drive strength, etc and nothing seemed to

19:12 <elSegundo> resolve the connection issue. Here is a few screen captures of the clock signal at different adapter speeds: https://imgur.com/a/ypIFjrc. The rising edges have overshoot but otherwise look to have minimal noises -- nothing looks radically different from signals below 100 KHz when the target connects and above 100KHz when it does not connect to the

19:12 <elSegundo> target. The OpenOCD output when I cannot connect to the target is the following: https://imgur.com/a/lgGZOej.

19:12 <elSegundo> In the imx-gpio.c driver file, the author makes the following note: "Transition delay coefficients. Tuned for IMX6UL 528MHz. Adjusted experimentally for: 10kHz, 100Khz, 500KHz. Speeds above 800Khz are impossible to reach via memory mapped method (at least for IMX6UL@528MHz)." I am also using an IMX6UL @ 528MHz and it seems the author was able to

19:12 <elSegundo> achieve a working connection at 500KHz, so I am unsure what I am doing differently than the author. Would I have to alter the transition delay coefficients? Thanks in advance.

20:37 <PaulFertser> elSegundo: with modern SoCs bitbanging protocols can be tricky, and there are might be glitches at certain transitions that spoil all the fun.

20:38 <PaulFertser> elSegundo: if you feel like debugging it then you should most probably attach an LA to record the session. And then using some other debug adapter (e.g. FTDI-based or a jlink) do the same. And then compare carefully. It might give enough clues to fix the driver.

20:41 <PaulFertser> elSegundo: also, the overshoots look severe, probably you need lower drive strength and slew rate? Or you need to add series termination resistors to each data line as real debug adapters do.

20:41 <PaulFertser> -1 V might confuse the target just by the amount of it.

20:42 <PaulFertser> I'd first start with fixing the signal integrity by adding series termination.

21:18 <elSegundo> PaulFertser, thanks for the response! I'll see what I can do about fixing the signal integrity and then if that doesn't work, I'll look at the two different LA sessions. Do you think it will be necessary to alter the transition delay coeffecients?

21:19 <PaulFertser> elSegundo: no idea what they really do, I haven't checked the relevant sources yet.

21:20 <PaulFertser> elSegundo: I'm surprised you tried to use max drive strength when you saw the overshoot.

21:21 <PaulFertser> elSegundo: you might really need something like ee87f2b4a9cac084903087aed6ff8e3a691c674b for that driver though.

21:27 <elSegundo> PaulFertser: I was trying a variety of GPIO configuration changes to see if it would cause a successful connection but I agree that a lower drive strength is what I should try to reduce the overshoot. And hm, that's a good point. A memory barrier might be needed in this situation, but I was under the impression that a hardware memory barrier

21:27 <elSegundo> shouldn't be needed for a single core CPU. Not entirely sure though

21:29 <PaulFertser> elSegundo: it can be out-of-order single core

21:31 <PaulFertser> elSegundo: and no matter what you try please do not forget to cross-check with a regular JTAG adapter. To see that you're able to connect to the same target with the same speed.

21:32 <PaulFertser> elSegundo: because who knows, probably your TMS570 is clocked really low by default, and that affects JTAG too.

21:52 <elSegundo> Ah, true it could be out-of-order. And I actually crossed checked with a RPi to TMS570 and was easily able to connect to the target at high speeds such as 500KHz. I'll try to take a capture of the RPi to TMS570 transaction too to see if I can spot any differences, but at least I know it is possible to connect to the target at those higher speeds.

21:52 <elSegundo> I'll check the signal integrity on it as well