SparkFun Forums

[prchan]

Has anyone had any success using openocd with a sam7x using a olimex
wiggler?

i was able to connect and load a ram based image using gdb , but was not able to step or run code once it was loaded.

thanks Pete.

[Dominic]

Hello Peter,

sorry for the delay, I just got back from a holiday last night.

I don't have a SAM7X myself, but as far as I know, it should work.

Maybe you could explain in more detail what happens when you're "not able to step or run code", i.e. show us the GDB commands you used, the config file, and output from OpenOCD. If there are a lot of Warning: or Error: messages, include debug output too, by enabling it with the "-d" switch on the command line.

Regards,

Dominic

[jqpublick]

I've got both the SAM7S64-EK, SAM7X256-EK, and Olimex wiggler. I have not yet tried loading code via OpenOCD (still using SAM-PROG over USB), although I have been able to do basic debugging in flash: stopping, starting, steping through, over, etc.

I have noticed that on the SAM7X I am unable to do a complete hardware reset: What I am seeing is that the PIO lines for the LEDs do not get reset. Stepping through the code still works though.

I need to play around with both some more, and I will make a new post with my findings/questions.

- Joe

[prchan]

I have both a sam7s64 and sam7x256 and a usbjtag,
i can load and run code into both modules, however the sam7x256 takes
about 45sec to load a 25kB image, whereas the sam7s64 takes only
a few seconds to load the same 25kB image.

has anyone had simlar problems loading code into the sam7x?

[Dominic]

Are you talking about loading into flash or into RAM? Is the download working correctly? 45s for 25kb might be caused by timeouts, in that case, there should be some error messages in the daemon output.

Would be nice if you could send me a log file (run with -d -l <logfile>) from the sam7x256 to Dominic.Rath <at> gmx.de.

Regards,

Dominic

[prchan]

Im able to load code into ram on the sam7x and run, step, break,

however it just takes 45 sec to load code.

i will send you the log file ASAP.

Also i have another problem where openocd comes up in thumb mode
if i do not hold the reset button on the board? If i hold the reset button
the board comes up in ARM mode and is ready..

[Dominic]

It takes a rather long time for the SAM7X to reenter debug state after writing to the target memory, but obviously everything else is fine.

The SAM7 seem to come up running from the slow clock (few kHz), that would explain the slow memory writing. Maybe you attach to the SAM7X before code running on the board had a chance to initialize the PLL (PC at 0x0 indicates that), while the SAM7S gets properly initialized (maybe you can send a log for that one, too)? You could try manually enabling the PLL and switching to the faster clock from within the OpenOCD.

Without logs and configuration files, I can't really tell you what's going wrong when your board comes up in thumb mode. Maybe there's already code in the flash that runs in Thumb mode? You can always switch modes with the "armv4_5 core_state 'arm|thumb' command. When holding the reset button down while starting the OpenOCD you simulate a "reset halt" command or the "reset_halt" target reset type respectively. Out of reset, the core is in ARM state.

Regards,

Dominic

[jqpublick]

Yes, this works for me and my SAM7X w/ wiggler.

It takes me 2:20 to burn a 62K file to an erased flash.

However, once the startup code is there, I use a "reset run_and_init", and verify ARM mode before flashing, the flash time drops to 11 seconds. This is a huge improvement!

PLEASE NOTE: After much trial and error I discovered that if you output debug information to the console window (as opposed to a file), this seriously slows down performance! There is no noticable performance hit when sending the log to a file.

Here is my target_script:

Code: Select all

wait_halt
armv4_5 core_state arm
poll
flash probe 0
flash write 0 c:\temp\rtosdemo.bin 0x0
shutdown

- Joe