<RoganDawes>
Hi folks. I am trying to use JTAG to access an imx28-based board (Wink Hub v1). I have an FTDI 2232 (CJMCU) dongle, which I have connected via a FoccaciaBoard breakout PCB, nd wired the appropriate signals through to the non-standard pinout on the Wink Hub (thanks to jalderman who did the hard work to figure out the connections!) It *kinda* works,
<RoganDawes>
but not reliably. In particular, I am having difficulty halting the board after reset.
<RoganDawes>
Obviously, that is 10+ years old, so I suspect that there are some configuration changes required to bring it up to date.
<PaulFertser>
RoganDawes: hi!
<RoganDawes>
Hi Paul!
<PaulFertser>
RoganDawes: please describe in more details how exactly it's not reliable.
<RoganDawes>
`halt` commands fail with "timed out while waiting for target halted"
<PaulFertser>
Do you observe target actually resetting after "reset"?
<PaulFertser>
(for the reference, reset means "reset run" that is, it should reset and then OpenOCD lets it run)
<RoganDawes>
I should add that I do not have a console uart on this board, as I stupidly put 12V through it (I think that is what happened), so I can't actually see board output.
<PaulFertser>
Damn that's a complication.
<PaulFertser>
What would be your plan if you manage to halt it?
<PaulFertser>
I suspect you didn't enable hardware reset or the line isn't actually connected where it should be.
<RoganDawes>
Use semihosting to get a console, load u-boot, transfer a flash image via USB (SDP/UMS/USB ACM ECM, whichever)
<RoganDawes>
it's possible, I guess. It does seem to behave initially after a power cycle.
<PaulFertser>
Also probably you want to use "reset; halt" (or with a command to sleep in-between) to have it more repeatable.
<PaulFertser>
Yes, just power cycling and "halt" right away might do the j.
<PaulFertser>
ob
<RoganDawes>
power cycle, then a leisurely execution of openocd, telnet, and `reset; halt` works
<RoganDawes>
i.e 10 seconds or more
<PaulFertser>
OK, so that's all you need at that point I guess?
<RoganDawes>
well, I then need to initialise the DDR, so I have an init sequence for that that does a bunch of mww commands.
<RoganDawes>
Just tried it now, and I get "memory read caused data abort (address: 0x43ff2000, size: 0x4, count: 0x1)"
<PaulFertser>
Hm, but whatever is already on the flash there should be doing it the first thing so by the time you halt it should be initialised already?
<RoganDawes>
I set `debug_level 3`, and could see a read to this address interspersed between each mww, which surprised me
<PaulFertser>
Probably you halt too late even when MMU is active?
<RoganDawes>
In theory, yes, the SPL on the flash should run the init. However, I want this to be functional even when the flash is erased
<PaulFertser>
Do you have oscilloscope to quickly check that "reset" actually toggles the physical reset line?
<RoganDawes>
I'm not sure what you mean "halt too late". Should reset not bring the board back to default? Assuming the pins are properly connected, of course.
<PaulFertser>
It should however I'm not sure it's happening .
<PaulFertser>
OpenOCD reports MMU state btw.
<RoganDawes>
I do, or a logic analyser.
<RoganDawes>
let me hook the LA up, and confirm that part at least.
<PaulFertser>
Also I recommend looking closely at the state reported after halting each time.
<PaulFertser>
To have the reset line doing anything you need "reset_config srts_only" (or trst_and_srst if you also want to use TRST).
cambrian_invader has quit [Ping timeout: 260 seconds]
<RoganDawes>
ok, so I added that reset_config, and now I get an immediate `reset; halt`, with the pc at 0x000000e8. Seems much better! Thanks for your help!
<RoganDawes>
PaulFertser: ^^
<RoganDawes>
and my wink1_init routine completes without issue. Looks fantastic! Thanks so much!
cambrian_invader has joined #openocd
<RoganDawes>
Looks like I celebrated too soon! Now that I have run the wink1_init routine to set up the DDR, I am still having trouble with halting.
urja has quit [Read error: Connection reset by peer]
urja has joined #openocd
RoganDawes has quit [Quit: Ping timeout (120 seconds)]
cambrian_invader has quit [Ping timeout: 244 seconds]
cambrian_invader has joined #openocd
xphn has quit [Remote host closed the connection]
rkta has left #openocd [#openocd]
tlwoerner has quit [Read error: Connection reset by peer]
tlwoerner has joined #openocd
RoganDawes has joined #openocd
nerozero has quit [Ping timeout: 244 seconds]
<RoganDawes>
PaulFertser: The logic analyser shows something really weird. TRST and SRST are simply not toggling at all. I have tried the default imx28 config `reset_config trst_and_srst`, changed it to `reset_config srst_only`, and nothing. I wonder if either my FocacciaBoard breakout is faulty, or else the interface/ftdi/um232h.cfg is not the correct base to
<RoganDawes>
start with.
<RoganDawes>
If I change to the original configuration I was using, which has:
<RoganDawes>
I see TRST toggle when I do a reset, but still nothing on SRST
<RoganDawes>
SRST is connected to a pin marked AD5 on the CJMCU breakout, and TRST is connected to a pin marked AD4 on the breakout, which suggests that maybe those should be 0x10 and 0x08 respectively!
<PaulFertser>
RoganDawes: TRST isn't really relevant normally, it's only to reset JTAG state machine but when OpenOCD knows there's no TRST it just does equivalent state transition (called Test Logic Reset).
<PaulFertser>
RoganDawes: you can assign SRST signal how you see fit for your specific ftdi hardware.
<RoganDawes>
I tried the change to map TRST using `-ndata 0x08` and SRST using `-ndata 0x10`, and then got no reset lines toggling
<RoganDawes>
which seems odd
<PaulFertser>
RoganDawes: you also need the corresponding change to ftdi_layout values to enable them as outputs I guess.
<RoganDawes>
you mean `ftdi layout_init 0x0078 0x017b` ?
<PaulFertser>
RoganDawes: and data and oe should be same mask if you are just connecting the signal directly to ftdi pin.
<PaulFertser>
RoganDawes: yes, that command
<RoganDawes>
they are directly connected
<RoganDawes>
ok, looking at the manual to see how to adjust those
<RoganDawes>
thanks for the help
<PaulFertser>
See e.g. tcl/interface/ftdi/tumpa-lite.cfg
<PaulFertser>
Which is trivial silly breakout board
<PaulFertser>
And if you have a breakout probably just connect reset line where the config expects it.
<PaulFertser>
RoganDawes: I do not see schematics for FocacciaBoard breakout.
<RoganDawes>
Yeah, me neither. Only the Gerbers. I can ask Luca for them, I guess. I suspect he is trying to avoid clones, perhaps.
<PaulFertser>
That's odd, and the config on github is odd, suggesting trst and srst go via a transistor.
<RoganDawes>
is it normal for the TRST to be toggling continuously while the JTAG connection is idle?
<PaulFertser>
No, but probably you shouldn't be connecting TRST at all (and not enabling it in reset_config).
<PaulFertser>
TRST is only to reset the JTAG state machine to the initial state.
<RoganDawes>
There are literally no active components on the FocacciaBoard, other than the CJMCU dongle, attached via pin headers. Everything else is just a pin header with labels.
<RoganDawes>
So it seems like Luca messed up the suggested dongle config in the repo.
<PaulFertser>
RoganDawes: should be easy to fix luckily
Hawk777 has joined #openocd
<RoganDawes>
Ok, I am going around in circles here. Decided to try my other JTAG adapters - I have a JLINK (clone/knock off) and a Bus Blaster v2. Made *sure* that the pins are mapped through correctly to the Wink. Both the JLink and the BusBlaster are reporting "JTAG scan chain interrogation failed: all ones". The only thing I can really think of is that the
<RoganDawes>
VTref wrong, and not powering the buffers.
<RoganDawes>
Which turned out to be the case - my soldering was not up to scratch, and the VTRef pin was a dry joint. :facepalm: The FTDI board didn't care, since VTRef wasn't even connected, but the fancier boards obviously did care.
<RoganDawes>
But no matter what I am doing, I am unable to get a transition on SRST.
<RoganDawes>
Is it possible that there is just a really strong pullup that is overwhelming the JTAG adapters?
<RoganDawes>
I suppose I could try and measure the resistance between SRST and Vcc ...
<RoganDawes>
Nothing. Guess the reset pin is controlled by something like an RC network, or else a PMIC. Makes sense, I suppose.