On Dec 27, 2008, at 12:06 PM, Dirk Behme wrote:
Rick Altherr wrote:On Dec 27, 2008, at 11:23 AM, Dirk Behme wrote:This appears to be correct now. The omap3530.jrc tap is configured as a 6-bit IR with the IDCODE being IR value 0x4.* If I manuall access omap3530.cpu or omap3530.jrc by irscan/ drscan commands like above, the other device has to be put into bypass automatically? E.g. doing 'irscan omap3530.jrc 4' after 'jtag tapenable omap3530.cpu' has to put omap3530.cpu into bypass? Is this done?Bypass isn't required specifically. It just happens to convienient. We try to use the idcode IR instead for any enabled device in the chain that we aren't specifically accessing. Since the idcode IR specified for the JRC is wrong when the tap is created, we will be accidentally putting the JRC in bypass (0x1 appears to be bypass) but still sending the full 32 idcode bits for the drscan to the JRC.How would this look like? Is this 0x04 | 0x00 for IrCap IrMask what you talk above about? E.g.: -- cut -- > scan_chainTapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr ---| --------------------| ---------|------------|------------|------|------|------|--------- 0 | omap3530.jrc | Y | 0x0b7ae02f | 0x0b7ae02f | 0x06 | 0x04 | 0x00 | 0x3f 1 | omap3530.cpu | n | 0x00000000 | 0xffffffff | 0x04 | 0x01 | 0x00 | 0x0fSo, we probably have not actually turned on the DAP and so when you do the last drscan, we shift 32 bits too many. That causes the JRC IDCODE to be interpreted as the result from the DAP and the value we shifted in will become the JRC's result. If you ran 'drscan omap3530.jrc 32 0x55aa55aa' for example, I would expect the result to be 0x55aa55aa.> irscan omap3530.jrc 0 > drscan omap3530.jrc 32 0x0 00000000 > irscan omap3530.jrc 4 > drscan omap3530.jrc 32 0x0 0b7ae02f > jtag tapenable omap3530.cpu Enabling Cortex-A8 @ OMAP3 Cortex-A8 @ OMAP3 enabled 1 > irscan omap3530.jrc 4 > drscan omap3530.jrc 32 0x0 00000000 // <====== !! > -- cut -- Still zero.Not really: -- cut -- > scan_chainTapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr ---| --------------------| ---------| ------------|------------|------|------|------|-------- - 0 | omap3530.jrc | Y | 0x0b7ae02f | 0x0b7ae02f | 0x06 | 0x04 | 0x00 | 0x3f 1 | omap3530.cpu | n | 0x00000000 | 0xffffffff | 0x04 | 0x01 | 0x00 | 0x0f> irscan omap3530.jrc 0 > drscan omap3530.jrc 32 0x0 00000000 > irscan omap3530.jrc 4 > drscan omap3530.jrc 32 0x0 0b7ae02f > irscan omap3530.jrc 4 > drscan omap3530.jrc 32 0x55aa55aa 0b7ae02f > jtag tapenable omap3530.cpu Enabling Cortex-A8 @ OMAP3 Cortex-A8 @ OMAP3 enabled 1 > irscan omap3530.jrc 4 > drscan omap3530.jrc 32 0x0 00000000 > irscan omap3530.jrc 4 > drscan omap3530.jrc 32 0x55aa55aa 00000000 -- cut --
Sorry, off by one error on my part. If the DAP isn't really enabled, but OpenOCD thinks it is, OpenOCD will try to shift 64 bits for the last drscan. Specifically, it will be:
0x55aa55aa00000000The bits will be shifted LSB first. Since only the JRC is in the chain, the 64-bits are being shifted into a 32-bit register. As the 0x0 is shifted in, the IDCODE of the JRC is shifted out but discarded by OpenOCD as it thinks it is the result from the DAP. Then, as the 0x55aa55aa is shifted in, the the 0x0 is shifted out and captured by OpenOCD as the result from the JRC.
Removing the 't->enabled = e' line just causes OpenOCD to never think the DAP is enabled. It will change the number of bits we shift out and since the JRC remains the first and only tap in the chain according to OpenOCD, it will "work" by accident. The real problem is that the DAP does not appear to be enabled after sending the appropriate ir/dr scans to the JRC.Other observation: As mentioned in the previous mail, for test, in jtag.c in JTAG_CMD_TAPENABLE I disabled "t->enabled":case JTAG_CMD_TAPENABLE: jtag_tap_handle_event( t, JTAG_TAP_EVENT_ENABLE); e = 1; //t->enabled = e; // <====== !! break; This results in: -- cut -- > irscan omap3530.jrc 4 > drscan omap3530.jrc 32 0x0 0b7ae02f > jtag tapenable omap3530.cpu Enabling Cortex-A8 @ OMAP3 Cortex-A8 @ OMAP3 enabled 1 > irscan omap3530.jrc 4 > drscan omap3530.jrc 32 0x0 0b7ae02f // <====== !! > -- cut --I.e. after tapenable JRC is still "usable" (if t->enabled is removed). I know that this is no solution, but maybe this could be a hint for the experts??Yes, something similar came to my mind ;) But how could we distinguish between a) the DAP isn't enabled correctly or b) the DAP is enabled but we configure the scan chain not correctly ?
Well, what is happening above lines up with the DAP not being enabled but not with the DAP being enabled and the scan chain being incorrect. Your experiment of commenting out the line that tells OpenOCD the DAP is enabled as well as the output of scan_chain indicates that OpenOCD believes both the JRC and DAP are enabled. Thus, OpenOCD will be shifting out 64 bits total for a drscan at that point.
Now, one thing that we are missing is a set of clock pulses _after_ the scans have been sent to the JRC. It may be that trying to do operations immediately after are failing because the logic in the JRC hasn't finished updating yet. The TI Doc has some details on what needs to happen after the ir/dr scans.The TI doc tells us -- cut -- ## Function : Wait for a minimum number of TCLK pulses. Parameter : The count of TCLK pulses is '10'. -- cut -- http://elinux.org/OMAP3530_ICEPICKSo you propose as next step to implement (a new function) to wait 10 TCLK without touching anything else?
It is certainly another piece of the puzzle. According to the TAP state machine, after an Update IR or Update DR, it returns to IDLE. It should be possible to use a 'runtest' command to stay in IDLE and clock a certain number of TCLK pulses. This isn't a guarantee that the DAP will turn on, but it should do that portion of the sequence.
Best regards Dirk
-- Rick Altherr [email protected]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
