Help needed with flash writing and/or getting started

Development Boards MicroMod
1

Hello,

after reading the thread viewtopic.php?t=8407 I wrote a hex file to some memory bank… I’m quite new to this as this is my first ARM project and now I’m trying to verify if I got my HW setup working. I need some pushes and kicks in the right way, so… here we go :wink: .

The board with AT91SAM7S64 is powered up, I got the USBjtag hooked up to it, OpenOCD running (and configured, so it can find and use that USBjtag). I compiled the example from WinARM (at91sam7s64_Hello) which produced the ‘main.hex’ file.

I opened up the telnet (telnet localhost 4444) and entered:

flash write 0 C:\WinARM\examples\at91sam7s64_Hello\main.hex 0

to write the .hex file to bank 0, reallocate to 0. Then the OpenOCD was quiet for a while and gave me a successfull message ('wrote file C:\WinARM\examples\at91sam7s64_Hello\main.hex to flash bank 0 at offs

et 0x00000000’).

Now I’m not sure if the bank 0 and address 0 was the right choice… What parameters should I use?

Now I’m trying to figure out how to really see if it works (the board) or not. Does anyone have some ideas?

Thank you all.

Jookie

2

“flash write” is deprecated in current versions of the OpenOCD. You should use “flash write_binary” or “flash write_image” instead.

A “HEX” file is an image file, it can possibly specify disjunctive sections that span several memories, and has to be written using “flash write_image”.

The “flash write” command now aliases to “flash write_binary”, and writes the content of the file as is, it treats the file as a plain binary. This variant expects a bank and an offset.

The “flash write_image” command expects the , an optional [offset], and an optional [type]. It writes to all flash memories of the current target as defined by the addresses in the image file.

Regards,

Dominic

3

Dominic, thank you for your reply.

I got the OpenOCD (Revision 65), but when I type:

flash write_image C:\WinARM\examples\at91sam7s64_Hello\main.hex

it gives me ‘Command write_image not found.’ Do I have a old version, or did I do something wrong?

4

Your version is almost ancient, Revision 65 got committed June 2006. You can get current binaries for Windows at www.yagarto.de.

Best regards,

Dominic

5

OK, so I got now the latest OpenOCD, configured it, and this is what it shows at startup:

c:\Program Files\openocd-2007re204\bin>openocd-ftd2xx.exe
Info:    openocd.c:93 main(): Open On-Chip Debugger (2007-09-05 09:00 CEST)
Warning: arm7_9_common.c:734 arm7_9_assert_reset(): srst resets test logic, too
Error:   arm_jtag.c:38 arm_jtag_set_instr_error_handler(): setting the new JTAG
instruction failed, debugging is likely to be broken

And then when I’m trying to flash the ARM, it looks like this:

Open On-Chip Debugger
> flash write_image C:\main.hex
didn't write section at 0x00100000, size 0x000005c8
wrote 0 byte from file C:\main.hex in 0s 15625us (0.000000 kb/s)
>

Do I have something in my configuration of OpenOCD wrong, or is my HW faulty? (the ARM board and / or the USB JTAG)?

Just to be shure, here’s my ‘openocd.cfg’:

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "USBjtag A"
ft2232_layout usbjtag
ft2232_vid_pid 0x0403 0x6001
jtag_speed 2
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst srst_pulls_trst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe

#target configuration
daemon_startup reset
#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
target_script 0 reset h2294_init.script
run_and_halt_time 0 30
working_area 0 0x40000000 0x40000 nobackup

#flash configuration
#flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 14765 calc_checksum
#flash bank cfi 0x80000000 0x400000 2 2 0
flash bank at91sam7 0 0 0 0 0
6

I want to add that I looked on the web and I found some programming script for OpenOCD, which I used and gave me a ‘normal’ output:

> script scripts\flashit.script
halt
requesting target halt...
target already halted
sleep 10
mww 0xfffffd44 0x00008000
mww 0xfffffd08 0xa5000001
mww 0xfffffc20 0x00000601
sleep 10
mww 0xfffffc2c 0x00481c0e
sleep 10
mww 0xfffffc30 0x00000007
sleep 10
mww 0xffffff60 0x003c0100
arm7_9 dcc_downloads enable
dcc downloads are enabled
sleep 10
poll
target state: halted
target halted in Thumb state due to debug request, current mode: Supervisor
cpsr: 0xa0000033 pc: 0x001003ca
flash probe 0
flash 'at91sam7' found at 0x00100000
flash write_image C:\main.hex
wrote 5648 byte from file C:\main.hex in 1s 500000us (3.677083 kb/s)
reset run
sleep 10
>

According to this it looks like it should work, but it doesn’t… I altered the at91sam7s64_Hello example like this:

	pPIO->PIO_PER  = 0xffffffff;
	pPIO->PIO_OER  = 0xffffffff;
	pPIO->PIO_SODR = 0xffffffff;
	pPIO->PIO_OWER = 0xffffffff;

	while(1)
	{
	}

Then I flashed the ARM, and measured voltage on pins PA0…31 to see if the are HIGH (and used pPIO->PIO_CODR to see if they are LOW), but they were always HIGH - looks like that something just isn’t working…

I tried both my JTAGs (wiggler and USBjtag based of FT2232) and both gave me the same result…

Does anyone have any idea, what’s going on?

Jookie

7

While looking at my AT91SAM7S64 board I found out that the pins DBGRQ and DBGACK are not connected to SAM7. Is this the reason this?

Error:   arm_jtag.c:38 arm_jtag_set_instr_error_handler(): setting the new JTAG 
instruction failed, debugging is likely to be broken

Will I be able to use some debugger with that board?