NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
tsal has quit [Ping timeout: 272 seconds]
tsal has joined #openocd
nerozero has joined #openocd
Hawk777 has quit [Quit: Leaving.]
cp- has joined #openocd
RoganDawes has joined #openocd
<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> I have based my configuration on the one found here: https://web.archive.org/web/20180831004104/http://jalderman.org/?p=348
<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.
<RoganDawes> > reset; halt
<RoganDawes> JTAG tap: imx28.cpu tap/device found: 0x079264f3 (mfg: 0x279 (SigmaTel), part: 0x7926, ver: 0x0)
<RoganDawes> NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
<RoganDawes> target halted in ARM state due to debug-request, current mode: Supervisor
<RoganDawes> cpsr: 0x200000d3 pc: 0x43f6e2c0
<RoganDawes> MMU: enabled, D-Cache: enabled, I-Cache: enabled
<PaulFertser> Looks too late to me because "MMU: enabled"
<RoganDawes> ok, makes sense
<PaulFertser> Compare to the article comment you linked to: cpsr: 0x200000d7 pc: 0x00000010
<PaulFertser> MMU: disabled, D-Cache: disabled, I-Cache: disabled
<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> ftdi layout_signal nTRST -ndata 0x0010 -noe 0x0040
<RoganDawes> ftdi layout_signal nSRST -ndata 0x0020 -noe 0x0040
<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.
Hawk777 has quit [Quit: Leaving.]