To the Atmel ARM gurus: Problems with OpenOCD

[Marcus von Cube, Germany]

This is a very technical question, but probably someone has a pointer for me. I'm working on the hardware port of wp34s, i. e. the flashing of the Atmel AT91SAM7L128 in the HP 20b. We (Pauli, Walter & me) are doing all our work with open source tools (except the Windows emulator which requires Visual Studio 2010 because of its MFC dependency).

One of the tools is OpenOCD, a software suite that supports on chip debugging with low cost JTAG probes. In my csae, it's an Olimex ARM-OCD. The problem I'm facing is that the ATM91SAM7L128 chip is not directly supported. I've had mixed success so far. The software detects my HP20b and I can submit commands like clock setup or flash erase. What I'm unable to do so far is programming the flash through OpenOCD. The pages are written with 00000008 and an error (protection bit set) is returned.

Is anybody here who has some experience with OpenOCD and the AT91SAM7L128 chip and can help me?

[Scott Newell]

Here's an example of my OpenOCD config (note I'm using a different JTAG dongle):

interface ft2232

target arm7tdmi little reset_run 0 arm7tdmi

jtag_device 4 0x1 0xf 0xe

jtag_speed 0x8

ft2232_layout evb_lm3s811

ft2232_device_desc "LM3S811 Evaluation Board A"

ft2232_vid_pid 0x0403 0xbcd9

working_area 0 0x2ff000 0x1000 nobackup

flash bank at91sam7 0 0 0 0 0

I ended up either using SAM-BA to burn flash, or running a little OpenOCD script to burn a sector at a time. It looked something like:

soft_reset_halt

load_image page-000.bin 0x100000 bin

mww 0xffffff64 0x5a000003 # command flash controller to erase/burn

sleep 10

load_image page-001.bin 0x100100 bin

mww 0xffffff64 0x5a000103 # command flash controller to erase/burn

sleep 10

...

load_image page-070.bin 0x104600 bin

mww 0xffffff64 0x5a004603 # command flash controller to erase/burn

sleep 10

verify_image test.bin 0x100000 bin

Pretty hacky, I know. Somewhere I've got a little windows program to build those .bin files if you need it.

Obviously on the 12C+, I was just doing crash and burn debugging with SAM-BA directly (no JTAG pins, no need for OpenOCD).

[Marcus von Cube, Germany]

Scott, thanks for you config file. It's not what I was hoping for. :(

Maybe I have to add myself to the list of OpenOCD developers and modify the respective algorithms. Do you think it may have to do with the processor speed? Have you tried different settings?

working_area 0 0x2ff000 0x1000 nobackup

flash bank at91sam7 0 0 0 0 0

These two lines make me curious. I thought the working area needs to be in RAM which is @ 0x200000 and not @ 0x2ff000. The size (4K) is correct.

The second line simply doesn't work for me because the flash algorithm does not identify the chip and therefore does not know about the flash layout and size. AFAIK, it makes no attempt at reading the flash layout info directly from the respective control registers.

Your splitting idea isn't very elegant at first sight but it might be improved by some TCL code. I'm new to TCL but if everything else fails, I can try this approach.

For the time being I'll stick to SAM-BA for flashing and use the adapter only for debugging.

[Scott Newell]

Quote:

---

Scott, thanks for you config file. It's not what I was hoping for. :
(

---

Sorry.

Quote:

---

working_area 0 0x2ff000 0x1000 nobackup

flash bank at91sam7 0 0 0 0 0

These two lines make me curious. I thought the working area needs to be in RAM which is @ 0x200000 and not @ 0x2ff000. The size (4K) is correct.

---

Oh, that's just a trick I used to have a solid 6k block of ram...check the databook (section 8 in my old copy): "The user can see the 6 Kbytes of SRAM contiguously at address 0x002F F000"

Quote:

---

The second line simply doesn't work for me because the flash algorithm does not identify the chip and therefore does not know about the flash layout and size. AFAIK, it makes no attempt at reading the flash layout info directly from the respective control registers.

---

I'll have to dig everything out and check, but I wasn't using much, if any, flash support from OpenOCD. Seems like I was doing a block copy from ram to the flash, then telling the flash controller to actually program the flash. That's what the script snippet was all about.

Quote:

---

Your splitting idea isn't very elegant at first sight but it might be improved by some TCL code. I'm new to TCL but if everything else fails, I can try this approach.

---

I think (it's been a while) that the script was generated as part of the makefile, so everytime I compiled the OpenOCD command script and flash image chunks were built automatically. If not, it certainly could be.

Quote:

---

For the time being I'll stick to SAM-BA for flashing and use the adapter only for debugging.

---

That's what I ended up with, once I upgraded to XP and SAM-BA ran quick enough. I started on win2k, and program times through SAM-BA were very long (~15 minutes).

[Scott Newell]

Quote:

---

Scott, thanks for you config file. It's not what I was hoping for. :(

---

Did you check 20B:flash_hacking ?

[Marcus von Cube, Germany]

Hi Scott,

Yes I've checked every mention of the AT91SAM7L on the Net...

I can debug now and I still use SAM-BA for flashing. It's not perfect but I can proceed with the real problems in my code. And there are many...