Flashing SAM7-P256 with ARM-USB-TINY-H and OpenOCD 0.6.1 on Mac OS X.

[pacman]

I'm using a PowerMac G5 with Mac OS X 10.5.8, and the Terminal for compiling/flashing.

Around 2 years ago, I bought a SAM7-P256 and a ARM-USB-TINY-H.

I built a toolchain, and after a while, I got a program flashed onto the SAM7-P256 board.
This was using OpenOCD and a clumsy trial-and-error-modification. I never got a 'beautiful' solution.

Unfortunately, my setup broke, and recently, I compiled a new toolchain; properly built, which includes OpenOCD 0.6.1.

Having trouble flashing my LPC1768, I thought I'd try and see if the Tiny-H will work with this OpenOCD, so I started searching the net; had a bunch of problems getting useful information.

Then I found this article, and created the following files, exactly as suggested:
project.cfg
board.cfg
target.cfg

Regarding project.cfg, the following line...
source [find board/olimex_sam7_p256.cfg]
... fails; it should be changed to something like ...
source [find board/olimex_sam7_ex256.cfg]
... That fails too, because the sourced file sources a file that does not exist either. Can be fixed by ...
source [find target/at91sam7x256.cfg]
...So far, so good.

I can now invoke OpenOCD by issuing the following command from the terminal:
$ openocd -f interface/olimex-arm-usb-tiny-h.cfg -f project.cfg
Open On-Chip Debugger 0.6.1 (2012-11-30-00:04)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 3000 kHz
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
Info : max TCK change to: 30000 kHz
Info : clock speed 3000 kHz
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : Embedded ICE version 1
Info : sam7x256.cpu: hardware has 2 breakpoint/watchpoint units

I open a new terminal window and type:
$ telnet localhost 4444
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying fe80::1...
telnet: connect to address fe80::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger

Finally, I get no errors that OpenOCD can't communicate with my target board.

> reset init
JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
Halt timed out, wake up GDB.
timed out while waiting for target halted
TARGET: sam7x256.cpu - Not halted

in procedure 'reset'

Learning from the file Manual_PROGRAMMER.pdf, I wrote the following:
File: 2013-flash.cfg

Code: [Select]

source [find interface/olimex-arm-usb-tiny-h.cfg]
source [find project.cfg]

adapter_khz 15000

proc program_sam7 () {

# halt the processor:
halt
wait_halt

# write file to flash memory:
arm7_9 dcc_downloads enable
sleep 10
poll
flash probe 0
flash write_image erase unlock "MyBlinker0.bin" 0x00100000
sleep 10

#  start execution of the program just downloaded
reset run
sleep 10

# exit OpenOCD:
shutdown
}

init
reset init
program_sam7 ()

I can run it using:
$ openocd -f 2013-flash.cfg
Open On-Chip Debugger 0.6.1 (2012-11-30-00:04)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 3000 kHz
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
adapter speed: 15000 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 15000 kHz
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : Embedded ICE version 1
Info : sam7x256.cpu: hardware has 2 breakpoint/watchpoint units
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
Info : Halt timed out, wake up GDB.
Error: timed out while waiting for target halted
TARGET: sam7x256.cpu - Not halted

Runtime Error: 2013-flash.cfg:30:
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'reset' called at file "2013-flash.cfg", line 30

In short: I have a file called MyBlinker0.bin, and I'd like to flash this file onto the SAM7-P256 using my ARM-USB-TINY-H JTAG adapter.

Here's my BinAndConfigFiles.

How should I do this ?


Love
Jens

[maria_olimex]

Hello pacman,

First, this is what I wrote in the first thread:

I'm glad my reply was useful to you. However, the project.cfg file that I've posted is now pat of a fully functioning project in Olimex ODS, without any changes. I don't know what made you change the file, but this is the wrong chip for the board.
SAM7-P256  -> AT91SAM7S256
SAM7-EX256 -> AT91SAM7X256

notice that the X in the MCU name is part of the name, not a letter that could be anything (like the stmf4xx files for example). So the at91sam7s256.cfg file is correct for the board. Note, that the board file needs to be in the .../scripts/board/ directory in order to be found properly. Now in this case the board file is just calling the target file so it really can be omitted; but in a lot of OpenOCD projects the board files contain borad-specific instructions(not project-, not cpu-specific, but board) and it is important to keep everything separate.

Please try using the correct target file for the chip. Your problem is with the reset event and this kind of event is very specific for every chip. You can see it defined as ... reset-init{...} in most cfg source files.
also, note the specific set of commands the (gdb in my case) debugger sends to openOCD when flashing the p256:

reset init
arm7_9 force_hw_breakpoints enable
flash write_image erase unlock main 0 bin
sleep 100
arm7_9 fast_memory_access enable
soft_reset_halt
continue

Note that soft_reset_halt is a different event, often used when you don't need a complete reset and reconfiguration of everyhting. You can read more about it in the openOCD 0.6.1 pdf manual (it comes with the release and is also included in OlimexODS).

Best Regards,
Maria/OLIMEX

[pacman]

Hi Maria.

Thank you for your excellent reply, this really narrows down the problem.

Please try using the correct target file for the chip. Your problem is with the reset event and this kind of event is very specific for every chip. You can see it defined as ... reset-init{...} in most cfg source files.
also, note the specific set of commands the (gdb in my case) debugger sends to openOCD when flashing the p256:

It seems that the current show-stopper is that I do not have the "at91sam7s256.cfg" file.
Thank you very much for listing the commands I need. I might be able to flash as soon as I have the at91sam7s256.cfg file.
Is it possible for you to attach this file / send it / paste it here ?

There might be hope for me yet.

I've spent a lot of time reading about OpenOCD and trying to understand it, but I think it's probably a little too difficult to grasp, when not knowing anything about JTAG and the programming protocols.

[pacman]

Hi Maria.

I beginning to think that there may be something wrong with my hardware.

I just removed all files and started from scratch, to make sure there's no "debris" laying around, which could interfere.

My project.cfg, board.cfg and target/at91sam7.cfg are all exactly like those you have; freshly copied and pasted into new files.
My board/olimex_sam7_p256.cfg is as follows:
I've created the file board/olimex_sam7_p256.cfg with the following contents:

Code: [Select]

# Olimex SAM7-P256 has a single Atmel at91sam7s256 on it.

source [find target/at91sam7sx.cfg]
-If it works on your end, it has to work on my end as well!

Now I do the following:

• Unplug my ARM-USB-TINY-H adapter from my computer.
• Remove power from my SAM7-P256 board.
• Plug in my 5VDC power to the SAM7-P256 board.
• Plug in the adapter as well.
• I even press the reset button on the board.
• I issue the command:
  $ openocd -f interface/olimex-arm-usb-tiny-h.cfg -f project.cfg
  Open On-Chip Debugger 0.6.1 (2012-11-30-00:04)
  Licensed under GNU GPL v2
  For bug reports, read
     http://openocd.sourceforge.net/doc/doxygen/bugs.html
  Info : only one transport option; autoselect 'jtag'
  adapter speed: 3000 kHz
  srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
  Warn : use 'at91sam7s.cpu' as target identifier, not '0'
  Info : max TCK change to: 30000 kHz
  Info : clock speed 3000 kHz
  Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
  Info : Embedded ICE version 1
  Info : at91sam7s.cpu: hardware has 2 breakpoint/watchpoint units
• Open a new Terminal window and issue the commands:
  $ telnet localhost 4444
  >reset init
  JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
  srst pulls trst - can not reset into halted mode. Issuing halt after reset.
  Halt timed out, wake up GDB.
  timed out while waiting for target halted
  TARGET: at91sam7s.cpu - Not halted
  
  in procedure 'reset'

Please notice that I suddenly got this warning (and I have no clue why; this must be significant):
Warn : use 'at91sam7s.cpu' as target identifier, not '0'

I then did this:
$ cd /usr/local/share/openocd/scripts/chip/atmel/at91
$ ls -la
drwxr-xr-x  21 root  wheel   714 Nov 30 00:04 .
drwxr-xr-x   3 root  wheel   102 Nov 28 17:56 ..
-rw-r--r--   1 root  wheel  2916 Nov 30 00:04 aic.tcl
-rw-r--r--   1 root  wheel  1332 Nov 30 00:04 at91_pio.cfg
-rw-r--r--   1 root  wheel  6503 Nov 30 00:04 at91_pmc.cfg
-rw-r--r--   1 root  wheel  1156 Nov 30 00:04 at91_rstc.cfg
-rw-r--r--   1 root  wheel   917 Nov 30 00:04 at91_wdt.cfg
-rw-r--r--   1 root  wheel  3713 Nov 30 00:04 at91sam7x128.tcl
-rw-r--r--   1 root  wheel  4107 Nov 30 00:04 at91sam7x256.tcl
-rw-r--r--   1 root  wheel  2924 Nov 30 00:04 at91sam9261.cfg
-rw-r--r--   1 root  wheel  2692 Nov 30 00:04 at91sam9261_matrix.cfg
-rw-r--r--   1 root  wheel  3823 Nov 30 00:04 at91sam9263.cfg
-rw-r--r--   1 root  wheel  7128 Nov 30 00:04 at91sam9263_matrix.cfg
-rw-r--r--   1 root  wheel  4053 Nov 30 00:04 at91sam9_init.cfg
-rw-r--r--   1 root  wheel  3349 Nov 30 00:04 at91sam9_sdramc.cfg
-rw-r--r--   1 root  wheel   965 Nov 30 00:04 at91sam9_smc.cfg
-rw-r--r--   1 root  wheel   286 Nov 30 00:04 hardware.cfg
-rw-r--r--   1 root  wheel   341 Nov 30 00:04 pmc.tcl
-rw-r--r--   1 root  wheel  1394 Nov 30 00:04 rtt.tcl
-rw-r--r--   1 root  wheel  1395 Nov 30 00:04 sam9_smc.cfg
-rw-r--r--   1 root  wheel  3645 Nov 30 00:04 usarts.tcl

Shouldn't there be a at91sam7s file in there - or is my problem elsewhere ?

Almost needless to say; my 2013-flash.cfg script didn't work.
I also tried afinko's armflash.cfg, but no luck.

[maria_olimex]

Hello,

I am using openocd-0.6.1 on windows XP (sorry, cannot currently test it on other platforms) + ARM-USB-TINY-H + SAM7-P256 + the code I pasted in the other thread, using the old file (+2 extra lines of code, sometimes they can save the whole project; I don't remember if I added them or if they were there initially).

Also, check the jumpers on the board, BDS and TEST should be open.

Here is my console output:

Code: [Select]

Open On-Chip Debugger
> poll
background polling: on
TAP: at91sam7s.cpu (enabled)
target state: running
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x00100650
> reset init
JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0,
ver: 0x3)
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x00100494
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x00000000
NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Typ
e 'help dcc'.
NOTE! Severe performance degradation without fast memory access enabled. Type 'h
elp fast'.
>

My GDB doesn't fail to halt it after reset. I haven't looked if the srst_pulls_trst option is vital for this chip/project, you may want to look there (it is in the cfg files).

Best Regards,
Maria/OLIMEX

[pacman]

Hi Maria.

I am using openocd-0.6.1 on windows XP (sorry, cannot currently test it on other platforms) + ARM-USB-TINY-H + SAM7-P256 + the code I pasted in the other thread, using the old file (+2 extra lines of code, sometimes they can save the whole project; I don't remember if I added them or if they were there initially).

I've tried both with and without the extra lines; no difference.

Also, check the jumpers on the board, BDS and TEST should be open.

They're both open (they've been open all the time).

Does your OpenOCD report the following line ?
Warn : use 'at91sam7s.cpu' as target identifier, not '0'

Here is my console output:
Open On-Chip Debugger
> poll
background polling: on
TAP: at91sam7s.cpu (enabled)
target state: running

I get exactly the same output. I've tried pulling the JTAG connector after running OpenOCD, and then I get complaints when I run poll.
But as soon as I plug the JTAG back in again, I get the same output from poll as you do, so poll works exactly like it should on my end.

> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x00100650

Here I get...
> halt
Halt timed out, wake up GDB.
timed out while waiting for target halted
in procedure 'halt'

I'm suspecting one of the JTAG's RESET pins doesn't work as expected.

The reason for trying to get my SAM7 board working, is that I wanted to flash a bare LPC1768, but OpenOCD reported something similar with the LPC1768.
-So since I once (two years ago) had it working, I went back to a 'known state', but I don't know if maybe my TINY-H is broken; I haven't used it since that time.

My GDB doesn't fail to halt it after reset. I haven't looked if the srst_pulls_trst option is vital for this chip/project, you may want to look there (it is in the cfg files).

As far as I can see on some of my old files, I had the line...
reset_config srst_only srst_pulls_trst
...in the top of my config.

I just tried using my old config again, but it doesn't work, not even with the correct files in my scripts directory.

I also checked my ribbon cable; no broken connections as far as my multimeter says.

Is there a way I can check the reset pin on the JTAG / TINY-H ?

[maria_olimex]

Hello,

I have several suggestions. I just experienced the same problem as you:
Warn : use 'at91sam7s.cpu' as target identifier, not '0'

and it couldn't connect at all. The solution is actually something totally unrelated to the project.
I have 2 USB cables - one I use for the ARM-USB-TINY-H and the other, identical to the first, to power the SAM7-P256. Today it seems I switched the two - and there was the connection problem. Switching them back to the way they were two days ago - and everything works seamlessly again.

You can try using a different USB port/cable. It will probably prompt you for drivers again and you will start fresh.

If your problem still persists, you can try using slightly different commands while flashing. opnOCD is still very much in development and some things haven't been ironed out; we just need a workaround.
So you just need to avoid reset-init; It isn't really needed while flashing - you just need the processor to be halted, preferably with pc at 0x0;
I just successfully flashed the P256 with those commands:
soft_reset_halt
wait_halt
arm7_9 fast_memory_access disable
flash write_image erase unlock main.elf 0
reset
****

You can reenable the fast memory access if you need it. I'd also recommend doing things manually via telnet and not with a script/program until all the issues are solved.

Best regards,
Maria/OLIMEX

[pacman]

Hi Maria.

Thank you for caring so much about my problem. I value this very much. 

I just tried 3 different USB cables (excluding the one I initially used), but none of them made any difference.
I tried with different ports. Unplugging all other USB devices, including my USB harddisk, my Kensington Turbomouse (trackball), using Apple's mouse again, etc.. Unfortunately, there's no difference yet.
I then decided to finally open my TINY-H (as it's now more than 2 years old) and check if there was any loose connections, but I spotted no visible errors so far.

After a lot of struggling with USB cables, wrong assumptions about OpenOCD, uninitialized variables, possible driver-errors, I decided to try something completely insane.

I have this very expensive switch-mode 5V DC power supply.

Now I found a good old heavy +6V DC power supply and used this one instead. I'm not afraid of burning off the board, because I checked the schematic, and it should at least, as far as I can tell, be able to handle voltages above 13V.

After using this heavy (6V, 2A) power supply with enough juice, I tried the "reset halt" command.
No timeout.
"reset init"
no timeout.

-So what you're experiencing with the one USB cable for power and another USB cable for programming might be this:

Your power cable must be short, in order to work, otherwise the voltage drop will be juuust big enough to get below what the board requires.
Try measuring this, if you have equipment suitable for it.

So whenever people have problems with these timeouts, ask them if they have at least 6V DC on the power plug.

When I read the printing on the board (which is partly hidden by a screw), I can now see that it says 6V, not 5V, like I first read it as.
-So this is an "error 40", eg. my own fault.
...But I hope it helps you as well, in catching problems related to too low voltages.

Just tried running my flash-script...

Code: [Select]

source [find interface/olimex-arm-usb-tiny-h.cfg]
source [find project.cfg]

adapter_khz 15000

proc program_sam7 () {

# halt the processor:
halt
wait_halt

# write file to flash memory:
arm7_9 dcc_downloads enable
sleep 10
poll
flash probe 0
flash write_image erase unlock "MyBlinker0.bin" 0x00100000
sleep 10

#  start execution of the program just downloaded
reset run
sleep 10

# exit OpenOCD:
shutdown
}

init
reset init
program_sam7 ()
And something very strange happened.. I have two LEDs blinking on the board.

I almost can't believe it works. Thank you for all the help you've provided. I know that if I just switched the power supply, I would probably have said "That's not it, it still doesn't work", and I'd have switched back to using the old PSU again.
But I'm really grateful that my config files are correct now. I still have the 'Warn' line, and it's most likely related to a config file, but I guess it doesn't mean that there will be any serious errors with flashing.


Love
Jens