- Sat Dec 04, 2010 3:31 am
#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
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