[dorkbotpdx-blabber] GuruPlug / Sheevaplug JTAG Experience?
63 views
Skip to first unread message
David Madden
Aug 15, 2012, 4:12:27 PM8/15/12
to dorkbotpd...@dorkbot.org
Do any of you have experience getting JTAG to work on a
GuruPlug/Sheevaplug? I have the FTDI2232 dongle that GlobalScale sells,
and I built OpenOCD on Linux, and I've had enough success that I think
things are close to working, but I can't get JTAG to halt the processor.
The RS232 part of the dongle works fine. When I use the low-level
jtag_reset command to set/reset the SRST and TRST lines, I can reset the
GuruPlug. But I haven't been able to get the processor into halt state
after a reset -- it always continues on to the bootloader.
Any tricks or tips for getting past this?
Thanks!
--
Mersenne Law LLC · www.mersenne.com · +1-503-679-1671
- Small Business, Startup and Intellectual Property Law -
1500 SW First Ave. · Suite 1170 · Portland, Oregon 97201
GuruPlug/Sheevaplug? I have the FTDI2232 dongle that GlobalScale sells,
and I built OpenOCD on Linux, and I've had enough success that I think
things are close to working, but I can't get JTAG to halt the processor.
The RS232 part of the dongle works fine. When I use the low-level
jtag_reset command to set/reset the SRST and TRST lines, I can reset the
GuruPlug. But I haven't been able to get the processor into halt state
after a reset -- it always continues on to the bootloader.
Any tricks or tips for getting past this?
Thanks!
--
Mersenne Law LLC · www.mersenne.com · +1-503-679-1671
- Small Business, Startup and Intellectual Property Law -
1500 SW First Ave. · Suite 1170 · Portland, Oregon 97201
Paul Stoffregen
Aug 15, 2012, 4:52:09 PM8/15/12
to A discussion list for dorkbot-pdx (portland, or)
On 08/15/2012 01:12 PM, David Madden
wrote:
Do any of you have experience getting JTAG to work on a GuruPlug/Sheevaplug? I have the FTDI2232 dongle that GlobalScale sells, and I built OpenOCD on Linux, and I've had enough success that I think things are close to working, but I can't get JTAG to halt the processor. The RS232 part of the dongle works fine. When I use the low-level jtag_reset command to set/reset the SRST and TRST lines, I can reset the GuruPlug. But I haven't been able to get the processor into halt state after a reset -- it always continues on to the bootloader. Any tricks or tips for getting past this?
With openocd, I have no experience.
From a low-level protocol point of view, you use 35 bit JTAG DR captures to two different scan chains (via the JTAG IR), one called the "debug port" and the other is a "memory access port". On both DR scan chains, 32 bits are data, 1 is read/write, and 2 are address bits, so you can read/write 4 registers in each port. The debug port has a 32 bit "select" register which combines together with the 2 address bits, to give a 64 register space on the memory access port. In theory, there could be up to 256 access ports (addressed by the top 8 bits of the "select" register), but usually there's only 1 which provides access to the entire 4 gigabyte address space. The memory access port only uses 7 of those 64, where one of the 7 is the actual 32 bit address to be used on the bus inside the chip, 1 is a auto-inc read/write register, and 4 are address+offset read/write, and 1 is for control+status. The procedure is not fun. Most things take 2 or 3 DR scans: start the operation, read a result, then check for pass/fail status. You can pipeline them if you care about speed. There's a debug spec document from ARM that gives the full protocol.
This stuff works, or should work, while the processor is in reset. You might not be able to access any actual memory while a hardware reset is asserted, but you should have access to the ARM core's debug registers and other stuff on the "private peripheral bus" (address range 0xE000xxxx). You need to write 0xA05F0003 to DHCSR (address 0xE000EDF0) to enable halting debug. Then write 0x01000401 to DEMCR (address 0xE000EDFC) to enable the watchpoint unit and set vector catch on reset. Each read or write on the bus is 2 or 3 Update-DRs. Remember to always check the ack/wait/fault status bits.
Then release the reset line, and the processor will reset but halt at the first instruction.
From a low-level protocol point of view, you use 35 bit JTAG DR captures to two different scan chains (via the JTAG IR), one called the "debug port" and the other is a "memory access port". On both DR scan chains, 32 bits are data, 1 is read/write, and 2 are address bits, so you can read/write 4 registers in each port. The debug port has a 32 bit "select" register which combines together with the 2 address bits, to give a 64 register space on the memory access port. In theory, there could be up to 256 access ports (addressed by the top 8 bits of the "select" register), but usually there's only 1 which provides access to the entire 4 gigabyte address space. The memory access port only uses 7 of those 64, where one of the 7 is the actual 32 bit address to be used on the bus inside the chip, 1 is a auto-inc read/write register, and 4 are address+offset read/write, and 1 is for control+status. The procedure is not fun. Most things take 2 or 3 DR scans: start the operation, read a result, then check for pass/fail status. You can pipeline them if you care about speed. There's a debug spec document from ARM that gives the full protocol.
This stuff works, or should work, while the processor is in reset. You might not be able to access any actual memory while a hardware reset is asserted, but you should have access to the ARM core's debug registers and other stuff on the "private peripheral bus" (address range 0xE000xxxx). You need to write 0xA05F0003 to DHCSR (address 0xE000EDF0) to enable halting debug. Then write 0x01000401 to DEMCR (address 0xE000EDFC) to enable the watchpoint unit and set vector catch on reset. Each read or write on the bus is 2 or 3 Update-DRs. Remember to always check the ack/wait/fault status bits.
Then release the reset line, and the processor will reset but halt at the first instruction.
Thanks!
_______________________________________________ dorkbotpdx-blabber mailing list dorkbotpd...@dorkbot.org http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber
David Madden
Aug 15, 2012, 5:38:37 PM8/15/12
to A discussion list for dorkbot-pdx (portland, or)
On 8/15/2012 13:52, Paul Stoffregen wrote:
> you should have access to the ARM core's debug registers and other stuff
> on the "private peripheral bus" (address range 0xE000xxxx). You need to
> write 0xA05F0003 to DHCSR (address 0xE000EDF0) to enable halting debug.
> Then write 0x01000401 to DEMCR (address 0xE000EDFC) to enable the
> watchpoint unit and set vector catch on reset. Each read or write on
> the bus is 2 or 3 Update-DRs. Remember to always check the
> ack/wait/fault status bits.
Thanks, Paul. That explains this big block of stuff in the "init"
> you should have access to the ARM core's debug registers and other stuff
> on the "private peripheral bus" (address range 0xE000xxxx). You need to
> write 0xA05F0003 to DHCSR (address 0xE000EDF0) to enable halting debug.
> Then write 0x01000401 to DEMCR (address 0xE000EDFC) to enable the
> watchpoint unit and set vector catch on reset. Each read or write on
> the bus is 2 or 3 Update-DRs. Remember to always check the
> ack/wait/fault status bits.
section of the configuration file. I'll have to look at it more
closely. I suspect that OpenOCD has low-level routines to do the
reading & writing you're talking about, so I just ("just!") need to
narrow my focus to figure out where the problem is.
Regards,
Reply all
Reply to author
Forward
0 new messages