SparkFun Forums 

Where electronics enthusiasts find answers.

Open source ARM Debugger
By ernestw
#114816
Hello Rockford,

Congratulations! Most of what you did makes sense!

I have found my problem with the drivers is related to Vista OS. It seems the Windows Vista and windows 7 64-bit OS systems cause a lot of problems with drivers for new hardware.
Unfortunately for other reasons I started this project in Vista, not Ubuntu as is my preference. So I am in the process of moving all my tools and project over to Ubuntu and a Win-32 system.

I am not familiar with the SAM7-P256 chip, but a few comments...

I see in your .cfg files

#flash bank <driver> <base_addr> <size> <chip_width> <bus_width> <target_number> [<target_name> <banks> <sectors_per_bank> <pages_per_sector> <page_size> <num_nvmbits> <ext_freq_khz>]
set _FLASHNAME $_CHIPNAME.flash
flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME 0 0 0 0 0 0 0 18432

I think there are a few errors...
The arguments seem to be slightly different to the flash bank command I read about. I am pretty certain 0 is used to specify a default value for the args.
Aligning the arguments I get
#flash bank <driver> <base_addr> <size> <chip_width> <bus_width> <target_number> [<target_name> <banks> <sectors_per_bank> <pages_per_sector> <page_size> <num_nvmbits> <ext_freq_khz>]
flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME 0 0 0 0 0 0 0 18432

is at91sam7 defined as the flash bank base addr? "flash 'at91sam7' found at 0x00100000" Is this the correct addr? And what of the two extra 0 0? 18432 is ext freq?

Should have warned you about the flash lock. Do you know if the lock is for the full bank, or a range of sectors? You ready should know exactly what part of the flash memory you are opening up.
Do you know if the SAM7-P256 chip stores any critical code in the flash bank? You should work out the memory map, locating all the code first. Often development boards have programs loaded into parts of RAM or Flash memory. This code/data is usually loaded from the lowest available blocks/sectors. When you first start to load your own code it is better to pick a couple of higher blocks/sectors near the upper end so you do not overwrite any code. Sometimes you have no choice.

cleared protection for sectors 0 through 1 on flash bank 0
flash 'at91sam7' found at 0x00100000

It looks like you unlock sectors 0 through 1

The other thing you should always do is immediately lock up the flash after you have written your code. Do this before you run anything! Otherwise some bad code can trash the lot!

I tend to not try to write to flash until I am sure I have all the args and variables correct. So I

1. comment out the nasty write operations and then check all the debug log carefully before trying to write.
2. It is better to get the memory dump commands working first
3. confirm where code/data is in memory (before loading your own code)
4. Just write a small amount of "do nothing" code. But do not run it.
5. Use memory dump to confirm you are writing the right code into the right memory locations.
6. Then run the code (which does the minimal amount of changes to prove it runs, i.e. changes one safe memory location).
7. Use debug and memory dump to confirm works as planned.
8. Then progressively increase code from there - blinking LEDS, etc.

Hope this helps.


Ernest
By ernestw
#114827
Hello again,

I went and RTFM http://openocd.berlios.de/doc/html/Flash-Commands.html

12.1 Flash Configuration Commands

— Config Command: flash bank name driver base size chip_width bus_width target [driver_options]

Configures a flash bank which provides persistent storage for addresses from base to base + size - 1. These banks will often be visible to GDB through the target's memory map. In some cases, configuring a flash bank will activate extra commands; see the driver-specific documentation.

* name ... may be used to reference the flash bank in other flash commands. A number is also available.
* driver ... identifies the controller driver associated with the flash bank being declared. This is usually cfi for external flash, or else the name of a microcontroller with embedded flash memory. See Flash Driver List.
* base ... Base address of the flash chip.
* size ... Size of the chip, in bytes. For some drivers, this value is detected from the hardware.
* chip_width ... Width of the flash chip, in bytes; ignored for most microcontroller drivers.
* bus_width ... Width of the data bus used to access the chip, in bytes; ignored for most microcontroller drivers.
* target ... Names the target used to issue commands to the flash controller.
* driver_options ... drivers may support, or require, additional parameters. See the driver-specific documentation for more information.

Note: This command is not available after OpenOCD initialization has completed. Use it in board specific configuration files, not interactively.


Config Command: flash bank name driver base size chip_width bus_width target [driver_options]
So should be (if I have read correctly)

flash bank $_FLASHNAME at91sam7 0x????? 0x8000 32 32 $_TARGETNAME 0 0 0 0 0 18432

where
at91sam7 is the driver s/ware; you need to supply base addr and size (0x8000 should work); SAM7 is 32 bit chip


Ernest
By ernestw
#114829
Here are the options for this driver.

Flash Driver: at91sam7

All members of the AT91SAM7 microcontroller family from Atmel include internal flash and use ARM7TDMI cores. The driver automatically recognizes a number of these chips using the chip identification register, and autoconfigures itself.

flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME

For chips which are not recognized by the controller driver, you must provide additional parameters in the following order:

* chip_model ... label used with flash info
* banks
* sectors_per_bank
* pages_per_sector
* pages_size
* num_nvm_bits
* freq_khz ... required if an external clock is provided, optional (but recommended) when the oscillator frequency is known

It is recommended that you provide zeroes for all of those values except the clock frequency, so that everything except that frequency will be autoconfigured. Knowing the frequency helps ensure correct timings for flash access.

The flash controller handles erases automatically on a page (128/256 byte) basis, so explicit erase commands are not necessary for flash programming. However, there is an “EraseAll“ command that can erase an entire flash plane (of up to 256KB), and it will be used automatically when you issue flash erase_sector or flash erase_address commands.
— Command: at91sam7 gpnvm bitnum (set|clear)

Set or clear a “General Purpose Non-Volatile Memory” (GPNVM) bit for the processor. Each processor has a number of such bits, used for controlling features such as brownout detection (so they are not truly general purpose).

Note: This assumes that the first flash bank (number 0) is associated with the appropriate at91sam7 target.



Ernest
By rodi07
#142362
Hi,

After a long time, I have loaded my program via ARM-USB-TINY-H on the
SAM7-EX256 Board (Flash). But I do not know, how to start the program from Flash?
I use a startup-program from a sample Project "olimex_sam7_ex256_startup_minimal" . I think this Program is used to start from SRAM. And I must start from Flash.

The second Problem is. I can Not Debug my Program, I set the OpenOCD according this manual:
http://carrierwave.wordpress.com/2009/0 ... debugging/


Thanks in advance.
Rodi
By rodi07
#142369
Hi,

After a long time, I have loaded my program via ARM-USB-TINY-H on the
SAM7-EX256 Board (Flash). But I do not know, how to start the program from Flash?
I use a startup-program from a sample Project "olimex_sam7_ex256_startup_minimal" . I think this Program is used to start from SRAM. And I must start from Flash.

The second Problem is. I can Not Debug my Program, I set the OpenOCD according this manual:
http://carrierwave.wordpress.com/2009/0 ... debugging/


Thanks in advance.
Rodi