JTAG is running but ...
OK, I have got the JTAG stuff running fairly well.
I can read the DCC registers in the EmbeddedICE and communicate with the
target in this way.
I also have access to the run control: I can halt the ARM code and clock
instructions into the pipeline - but here is were things get messed up:
After halting the core by asserting the DBGRQ bit in the debug control
register of the EmbeddedICE I am waiting for the core to halt and result
in assertion of the DBGACK bit in the debug status register, also the
TRANS[1] bit is asserted (1).
So far so good.
Now I start feeding scan chain 1 with instructions (STMIA R0,{R0-R15}
followed by a bunch of NOPs) while reading back data from that same scan
chain.
Weird things happen at this time ... I am only reading back 0x0000,0000
all the time. Now I reset the whole JTAG interface, select scan chain 1
again and repeat the procedure of clocking in the same set of instructions.
This now results in the following values being read back: 0x12345678,
0x12345678, 0x12345678, 0x12345678, 0xdeadbeef, 0xdeadabba, 0x9abcdef0,
.... Which corresponds to the contents of the registers: R0, R0, R0, R0,
R1, R2, R3, ... R14, R15
(the first 3 values of R0 read may/will be coincidental - the
instruction has still to be fed into the pipeline and to be executed)
All register values (except R15) read as the correct values at this
point. I'm not sure why R15 differs but this may have to do with the
mode I am in when the targer is halted compared to the mode my program
is running in.
The question is why I am only reading the correct values after applying
a full JTAG reset?
The program does following things:
1) Reset JTAG by pulsing TRST low, sending 5 TCK pulses with TMS=1,
followed by 2 times TMS=0 (get the TAP controller into Test-Run/Idle)
2) Selecting scan chain 1 and setting it up between TDI/TDO: Feed IR
with SCAN_N instruction, DR with the scan chain value (1) and IR with
INTEST.
3) (only the first time) select halt mode by selecting scan chain 2
(like in point 2) and writing 6 into the Debug Control Register, then
wait for the DBGACK bit in the Debug Status Register
4) (only the first time) select scan chain 1 again (like in point 2)
5) Clocking out the instructions into scan chain 1 and clocking in the
results at the same time
6) After clocking in/out all data continue from Update-DR into
Test-Run/Idle to generate a DCLK pulse (this is de debug clock needed by
the core to clock in the instruction)
What am I doing wrong? As far as i know one must not reset the whole TAP
controller before the ARM core operates properly in Halt mode?
Anyone with in depth ARM / EmbeddedICE knowledge who can help me out in
this one?
(and yes, I am reverting the bit order of scan chain 1 - otherwise I
would not get any sensible data since I already tried this)
Regards,
Rob
Problems with JTAG / Embedded ICE module
Started by ●October 11, 2005
Reply by ●October 11, 20052005-10-11
You have to take DBGRQ low again, after the target entered debug state
(DBGACK
high).
Regards,
Dominic
On Tuesday 11 October 2005 09:45, Rob Jansen wrote:
> JTAG is running but ...
>
> OK, I have got the JTAG stuff running fairly well.
> I can read the DCC registers in the EmbeddedICE and communicate with the
> target in this way.
> I also have access to the run control: I can halt the ARM code and clock
> instructions into the pipeline - but here is were things get messed up:
> After halting the core by asserting the DBGRQ bit in the debug control
> register of the EmbeddedICE I am waiting for the core to halt and result
> in assertion of the DBGACK bit in the debug status register, also the
> TRANS[1] bit is asserted (1).
> So far so good.
>
> Now I start feeding scan chain 1 with instructions (STMIA R0,{R0-R15}
> followed by a bunch of NOPs) while reading back data from that same scan
> chain.
>
> Weird things happen at this time ... I am only reading back 0x0000,0000
> all the time. Now I reset the whole JTAG interface, select scan chain 1
> again and repeat the procedure of clocking in the same set of instructions.
> This now results in the following values being read back: 0x12345678,
> 0x12345678, 0x12345678, 0x12345678, 0xdeadbeef, 0xdeadabba, 0x9abcdef0,
> .... Which corresponds to the contents of the registers: R0, R0, R0, R0,
> R1, R2, R3, ... R14, R15
> (the first 3 values of R0 read may/will be coincidental - the
> instruction has still to be fed into the pipeline and to be executed)
>
> All register values (except R15) read as the correct values at this
> point. I'm not sure why R15 differs but this may have to do with the
> mode I am in when the targer is halted compared to the mode my program
> is running in.
> The question is why I am only reading the correct values after applying
> a full JTAG reset?
>
> The program does following things:
>
> 1) Reset JTAG by pulsing TRST low, sending 5 TCK pulses with TMS=1,
> followed by 2 times TMS=0 (get the TAP controller into Test-Run/Idle)
> 2) Selecting scan chain 1 and setting it up between TDI/TDO: Feed IR
> with SCAN_N instruction, DR with the scan chain value (1) and IR with
> INTEST.
> 3) (only the first time) select halt mode by selecting scan chain 2
> (like in point 2) and writing 6 into the Debug Control Register, then
> wait for the DBGACK bit in the Debug Status Register
> 4) (only the first time) select scan chain 1 again (like in point 2)
> 5) Clocking out the instructions into scan chain 1 and clocking in the
> results at the same time
> 6) After clocking in/out all data continue from Update-DR into
> Test-Run/Idle to generate a DCLK pulse (this is de debug clock needed by
> the core to clock in the instruction)
>
> What am I doing wrong? As far as i know one must not reset the whole TAP
> controller before the ARM core operates properly in Halt mode?
> Anyone with in depth ARM / EmbeddedICE knowledge who can help me out in
> this one?
>
> (and yes, I am reverting the bit order of scan chain 1 - otherwise I
> would not get any sensible data since I already tried this)
>
> Regards,
>
> Rob
high).
Regards,
Dominic
On Tuesday 11 October 2005 09:45, Rob Jansen wrote:
> JTAG is running but ...
>
> OK, I have got the JTAG stuff running fairly well.
> I can read the DCC registers in the EmbeddedICE and communicate with the
> target in this way.
> I also have access to the run control: I can halt the ARM code and clock
> instructions into the pipeline - but here is were things get messed up:
> After halting the core by asserting the DBGRQ bit in the debug control
> register of the EmbeddedICE I am waiting for the core to halt and result
> in assertion of the DBGACK bit in the debug status register, also the
> TRANS[1] bit is asserted (1).
> So far so good.
>
> Now I start feeding scan chain 1 with instructions (STMIA R0,{R0-R15}
> followed by a bunch of NOPs) while reading back data from that same scan
> chain.
>
> Weird things happen at this time ... I am only reading back 0x0000,0000
> all the time. Now I reset the whole JTAG interface, select scan chain 1
> again and repeat the procedure of clocking in the same set of instructions.
> This now results in the following values being read back: 0x12345678,
> 0x12345678, 0x12345678, 0x12345678, 0xdeadbeef, 0xdeadabba, 0x9abcdef0,
> .... Which corresponds to the contents of the registers: R0, R0, R0, R0,
> R1, R2, R3, ... R14, R15
> (the first 3 values of R0 read may/will be coincidental - the
> instruction has still to be fed into the pipeline and to be executed)
>
> All register values (except R15) read as the correct values at this
> point. I'm not sure why R15 differs but this may have to do with the
> mode I am in when the targer is halted compared to the mode my program
> is running in.
> The question is why I am only reading the correct values after applying
> a full JTAG reset?
>
> The program does following things:
>
> 1) Reset JTAG by pulsing TRST low, sending 5 TCK pulses with TMS=1,
> followed by 2 times TMS=0 (get the TAP controller into Test-Run/Idle)
> 2) Selecting scan chain 1 and setting it up between TDI/TDO: Feed IR
> with SCAN_N instruction, DR with the scan chain value (1) and IR with
> INTEST.
> 3) (only the first time) select halt mode by selecting scan chain 2
> (like in point 2) and writing 6 into the Debug Control Register, then
> wait for the DBGACK bit in the Debug Status Register
> 4) (only the first time) select scan chain 1 again (like in point 2)
> 5) Clocking out the instructions into scan chain 1 and clocking in the
> results at the same time
> 6) After clocking in/out all data continue from Update-DR into
> Test-Run/Idle to generate a DCLK pulse (this is de debug clock needed by
> the core to clock in the instruction)
>
> What am I doing wrong? As far as i know one must not reset the whole TAP
> controller before the ARM core operates properly in Halt mode?
> Anyone with in depth ARM / EmbeddedICE knowledge who can help me out in
> this one?
>
> (and yes, I am reverting the bit order of scan chain 1 - otherwise I
> would not get any sensible data since I already tried this)
>
> Regards,
>
> Rob
Reply by ●October 11, 20052005-10-11
