I was hoping someone could help me locate the issue with this setup.
I am following this url: http://http://plume.redox.ws/article13/dockstar-debricking-jtag-with-buspirate
My buspirate.cfg:
~/openocd/tcl/interface$ cat buspirate.cfg
interface buspirate
buspirate_port /dev/ttyUSB0
buspirate_speed fast
buspirate_vreg 0
buspirate_mode open-drain
buspirate_pullup 0
reset_config srst_only
My dockstar.cfg which is taken off the same page:
cat dockstar.cfg
# Marvell SheevaPlug
# I'm using a wiggler compatible cable
source [find interface/buspirate.cfg]
source [find target/feroceon.cfg]
jtag_khz 500
jtag_nsrst_delay 500
$_TARGETNAME configure
-work-area-phys 0x10000000
-work-area-size 65536
-work-area-backup 0
# Disabled for the dockstar
#arm7_9 dcc_downloads enable
# this assumes the hardware default peripherals location before u-Boot moves it
set _FLASHNAME $_CHIPNAME.flash
nand device $_FLASHNAME orion 0 0xd8000000
proc dockstar_init { } {
# We need to assert DBGRQ while holding nSRST down.
# However DBGACK will be set only when nSRST is released.
# Furthermore, the JTAG interface doesn't respond at all when
# the CPU is in the WFI (wait for interrupts) state, so it is
# possible that initial tap examination failed. So let's
# re-examine the target again here when nSRST is asserted which
# should then succeed.
jtag_reset 0 1
feroceon.cpu arp_examine
halt 0
jtag_reset 0 0
wait_halt
arm mcr 15 0 0 1 0 0x00052078
mww 0xD0001400 0x43000C30
mww 0xD0001404 0x39543000
mww 0xD0001408 0x22125451
mww 0xD000140C 0x00000833
mww 0xD0001410 0x000000CC
mww 0xD0001414 0x00000000
mww 0xD0001418 0x00000000
mww 0xD000141C 0x00000C52
mww 0xD0001420 0x00000042
mww 0xD0001424 0x0000F17F
mww 0xD0001428 0x00085520
mww 0xD000147c 0x00008552
# 1st bank is 128 MB
mww 0xD0001504 0x07FFFFF1
# 2nd bank of DRAM is not used
mww 0xD0001508 0x00000000
mww 0xD000150C 0x00000000
# Commented the 3 following lines
#mww 0xD0001504 0x0FFFFFF1
#mww 0xD0001508 0x10000000
#mww 0xD000150C 0x0FFFFFF5
mww 0xD0001514 0x00000000
mww 0xD000151C 0x00000000
mww 0xD0001494 0x003C0000
mww 0xD0001498 0x00000000
mww 0xD000149C 0x0000F80F
mww 0xD0001480 0x00000001
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0020204 0x00000000
mww 0xD0010000 0x01111111
mww 0xD0010004 0x11113322
mww 0xD0010008 0x00001111
mww 0xD0010418 0x003E07CF
mww 0xD001041C 0x000F0F0F
mww 0xD0010470 0x01C7D943
}
proc sheevaplug_reflash_uboot { } {
# reflash the u-Boot binary and reboot into it
sheevaplug_init
nand probe 0
nand erase 0 0x0 0xa0000
nand write 0 uboot.bin 0 oob_softecc_kw
resume
}
proc sheevaplug_reflash_uboot_env { } {
# reflash the u-Boot environment variables area
sheevaplug_init
nand probe 0
nand erase 0 0xa0000 0x40000
nand write 0 uboot-env.bin 0xa0000 oob_softecc_kw
resume
}
proc sheevaplug_load_uboot { } {
# load u-Boot into RAM and execute it
sheevaplug_init
#load_image uboot.elf
#verify_image uboot.elf
load_image u-boot
verify_image u-boot
resume 0x00600000
}
proc dockstar_reset_cpu { } {
# System and User mode registers
# r0: 00000000 r1: 00000000 r2: 00000000 r3: 00000000
# r4: 00000000 r5: 00000000 r6: 00000000 r7: 00000000
# r8: 00000000 r9: 00000000 r10: 00000000 r11: 00000000
# r12: 00000000 sp_usr: 7dddee86 lr_usr: dffebe46 pc: ffff0a42
# cpsr: 400000f3
reg r1 0
reg r2 0
reg r3 0
reg r4 0
reg r5 0
reg r6 0
reg r7 0
reg r8 0
reg r9 0
reg r10 0
reg r11 0
reg r12 0
reg sp_usr 0
reg lr_usr 0
reg pc 0
# Set the CPU in Supervisor mode
reg cpsr 0x13
# FIQ mode shadow registers
# r8_fiq: fbcfff64 r9_fiq: d7dfafd6 r10_fiq: 1fff6d2e r11_fiq: 1db65df4
# r12_fiq: ff5a6de4 sp_fiq: 745fe7d5 lr_fiq: 89f7ae3e spsr_fiq: 00000000
reg r8_fiq 0
reg r9_fiq 0
reg r10_fiq 0
reg r11_fiq 0
reg r12_fiq 0
reg sp_fiq 0
reg lr_fiq 0
reg spsr_fiq 0
# Supervisor mode shadow registers
# sp_svc: fffeff84 lr_svc: ffff0a43 spsr_svc: 00000000
reg sp_svc 0
reg lr_svc 0
reg spsr_svc 0
# Abort mode shadow registers
# sp_abt: 51fe66f7 lr_abt: d7abaef7 spsr_abt: 00000000
reg sp_abt 0
reg lr_abt 0
reg spsr_abt 0
# IRQ mode shadow registers
# sp_irq: 7fdb4ed5 lr_irq: 6d41122e spsr_irq: 00000000
reg sp_irq 0
reg lr_irq 0
reg spsr_irq 0
# Undefined instruction mode shadow registers
# sp_und: 75ffef7e lr_und: d75b6cd1 spsr_und: 00000000
reg sp_und 0
reg lr_und 0
reg spsr_und 0
}
When I run openocd -f ./dockstar.cfg I get the following:
openocd -f ./dockstar.cfg
Open On-Chip Debugger 0.5.0-dev-00959-gd6c42bf (2011-07-23-18:11)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'buspirate' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
srst_only separate srst_gates_jtag srst_open_drain
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
500 kHz
adapter_nsrst_delay: 500
Warn : use 'feroceon.cpu' as target identifier, not '0'
dockstar_reset_cpu
Error: You need to specify port !
in procedure 'init'
I am also connecting the dockstar like so:
http://http://ferdinand-keil.de/wp-content/uploads/2011/06/debug_header.png
Using this chart as reference:
http://http://antibore.wordpress.com/2011/06/22/quick-reference-for-sparkfun-bus-pirate-cable
So I only have the GND = Black, TX= Pink and RX= Brown connected.
Anyone else running this same configuration and can point me to what I am doing wrong?
I'm sorry you haven't gotten any replies here. I'm not totally sure, but I assume it doesn't like the port name in buspirate.cfg.
Error: You need to specify port !
in procedure 'init'
The port name looks ok to me. Are you sure the Bus Pirate (and not a system serial port or toher adapter) has this serial port on your PC?
I moved it into the openocd subforum. It should get more attention in here.
Wow seriously no one has this same setup?
Well since I haven't gotten any response in the IRC channel, or here, I decided to get a 5$ PL2303 that works.
Anyone want to buy a brand new buspirate for 25$? :D lol
Ian:
This happens regardless if the usb cable/buspirate is plugged in or not.
I'm sorry we couldn't help you out.
This happens regardless if the usb cable/buspirate is plugged in or not.
Then I would guess the port name was wrong. Did you ever try screen /dev/ttyUSB0 (or similar) to open a terminal to the Bus Pirate to be sure it is present on your system?
So I only have the GND = Black, TX= Pink and RX= Brown connected.
I also just noticed this. The pinout you link is a whole JTAG header (TDI/TDO, etc), but this describes a serial UART, probably for a serial console terminal. I don't think it is the cause of your issue, but I have never heard of a JTAG device being JTAGed though a serial header. Did you also connect the new programmer that way?
[quote author="ian"]I'm sorry we couldn't help you out.
This happens regardless if the usb cable/buspirate is plugged in or not.
Then I would guess the port name was wrong. Did you ever try screen /dev/ttyUSB0 (or similar) to open a terminal to the Bus Pirate to be sure it is present on your system?
The screen part works fine and responds as it should.
So I only have the GND = Black, TX= Pink and RX= Brown connected.
I also just noticed this. The pinout you link is a whole JTAG header (TDI/TDO, etc), but this describes a serial UART, probably for a serial console terminal. I don't think it is the cause of your issue, but I have never heard of a JTAG device being JTAGed though a serial header. Did you also connect the new programmer that way?
[/quote]
This is even before you hook anything up, at this point all I have is the OpenOCD and buspirate connected, nothing else.
Hi,
sorry for the late attention :-)
I am pretty sure that the problem is in your config files.
Error: You need to specify port !
This error really means, that the buspirate driver doesn't see your port setting.
When there is no buspirate connected to the host you will get:
Error: Could not open serial port.
in procedure 'init'
And when the jtag is not connected to anything you will get:
Info : Buspirate switched to FAST mode
Info : Buspirate Interface ready!
Info : Want to set speed to 10kHz, but not implemented yet
Error: Translation from jtag_speed to khz not implemented
Info : adapter-specific clock speed value 10
Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
Error: JTAG scan chain interrogation failed: all zeroes
......
My openocd.cfg file looks like this
interface buspirate
buspirate_port /dev/ttyUSB0
buspirate_speed fast
buspirate_vreg 1
buspirate_mode normal
source [find target/stm32.cfg]
I have tested this config with version from 3.2.2011, and also from 3.8.2011, so it is hardly a bug in openocd.
Could you try and copy my config file, change the last line to your target and just run openocd (without any parameters) in the same dir as the openocd.cfg ?
[s:]I have the exact same problem. I am using cygwin. I'm wondering about "buspirate_port." I've tried COM7, com7, /dev/COM7[/s:]
For anyone else using cygwin, try the following:
buspirate_port /dev/comX
e.g. buspirate_port /dev/com7
In my case I got "You need to specify port !" with all of the following:
Did not work for me:com7
COM7
/dev/COM7
Thanks for the tip webboy, I'm sure it will help a lot of people.