Rick Altherr wrote:
>
> On Dec 27, 2008, at 11:23 AM, Dirk Behme wrote:
>
>>
>>>> * 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_chain
>> TapName | 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
>>
>
> This appears to be correct now. The omap3530.jrc tap is configured as
> a 6-bit IR with the IDCODE being IR value 0x4.
>
>> > 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.
>>
>
> So, 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.
Not really:
-- cut --
> scan_chain
TapName | 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 --
>>
>> 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??
>>
>
> 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.
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
?
> 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_ICEPICK
So you propose as next step to implement (a new function) to wait 10
TCLK without touching anything else?
Best regards
Dirk
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
