Sent from my iPhone
On Dec 26, 2008, at 3:44 AM, Dirk Behme <[email protected]> wrote: > Dirk Behme wrote: >> Rick Altherr wrote: > >> The idcode IR (of jrc) is unknown > > Testing all IRs, I get > > -- cut -- > > scan_chain > TapName | Enabled | IdCode Expected IrLen > IrCap IrMask Instr > --- > |-- > --- > --- > --- > --- > --- > ---|---------|------------|------------|------|------|------|--------- > 0 | omap3530.jrc | Y | 0x0b7ae02f | 0x0b7ae02f | 0x06 | > 0x01 | 0x0f | 0x3f > 1 | omap3530.cpu | n | 0x00000000 | 0xffffffff | 0x04 | > 0x01 | 0x00 | 0x0f > > > irscan omap3530.jrc 4 > > > drscan omap3530.jrc 32 0x0 > 0b7ae02f > > > -- cut -- > > jrc's ID code is at IR 4 then? Possibly. Had you tried other IR value before 4 without resetting the board? If irscan 4 was the first command sent after a reset, it was ignored and you just read the default IR. > > >>> For any CoreSight device, the IDCODE should be obtainable by: >>> >>> irscan <tap> 0xFE >>> drscan <tap> 32 0x0 >>> >>> The drscan should return the IDCODE. >> Testing with above 3 configurations I then did (thanks for the hint): >> jtag tapenable omap3530.cpu >> irscan omap3530.cpu 0xFE >> drscan omap3530.cpu 32 0x0 > > Some (stupid? sorry!) questions: > > * In "irscan omap3530.cpu 0xFE" above: Why 0xFE ? IrLen is 0x4, so > only 16 possible addresses? > I probably was just in a mood for a byte :-). The value is 0xE and the upper nibble is just dropped. > * As I understand it, by enabling omap3530.cpu, we add CoreSight > device into scan chain. This is what TI doc describes as > > -- cut -- > ## Function : Update the JTAG preamble and post-amble counts. > Parameter : The IR pre-amble count is '0'. > Parameter : The IR post-amble count is '6'. > Parameter : The DR pre-amble count is '0'. > Parameter : The DR post-amble count is '1'. > Parameter : The IR main count is '4'. > Parameter : The DR main count is '1' > -- cut -- > > Where in OpenOCD code is this done? Is it done correctly? > This is done when the tap is enabled in jtag.c. > * 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. > E.g. > > -- cut -- > Open On-Chip Debugger > > 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 -- > > Seems that something is "corrupted" by enabling omap3530.cpu ? Maybe > we correctly insert CoreSight device correctly into scan chain but > then fail to handle it correctly? Just an idea ;) > If the idcode IR is wrong in the tap creation, then this could happen. If 0x4 is the correct value, then try using that and see if the drscan of the CPU succeeds. > Best regards > > Dirk _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
