Okay... this may be slightly off topic... I'm suspecting hardware more than software.
Here's the problem... I've done KEIL projects for AT91SAM7S32 and AT91SAM7S64 boards and the hardware has always come out of reset and started to execute code reliably when not using the debugger.
Now I've tried (2) different AT91SAM7S256 designs, and they've both behaved differently in that sometimes the code just doesn't appear to come out of reset reliably. I simplifed both projects to do nothing but configure the H/W reset input and an I/O pin to be a driver, and then toggle that I/O pin in an infinite loop but that code does not run reliably. I am using a 4-layer board with a ground plane, and all the oscillator, reset and JTAG port stuff is a direct cut/paste from my working designs using the S32 & S64 parts.
I added code to enable a ~1 second watchdog timer, and that seems to fix the problem, in that when the I/O pin doesn't toggle after a power up reset or hardware reset it does come to life after ~1 second when the watchdog timer times out.
Does anybody know of anything that could be responsible for this type of symptom...?
Thanks, Dave.
Update...
I slowed MCK down to ~ 25 MHz (from ~ 55 MHz), and the symptom appears to have gone away. I've checked and double checked all the relevant datasheet sections, including the errata, and I don't see any reason I can't have an MCK of ~ 55 Mhz. I'm using REV A parts (AT91SAM7S256 AU A) parts.
I'm using a 20 MHz crystal, with 1 flash read wait state, with MUL = 1401 and DIV = 255. This should create an MCK of ~ 54.95 MHz, which should be okay as best as I can tell. If I slow MUL down to 637 the symptom goes away. Can anyone tell me if the settings I'm trying to use are valid or not, or if there's anything else I should be checking?
Again... I know this is probably considered slightly off topic, since it's not about the KEIL tools per se, but I am using KEIL tools on this project ;-)
Dave.
I'm using a 20 MHz crystal, with 1 flash read wait state, with MUL = 1401 and DIV = 255.
BTW, there is a limit of 180 MHz for the f_PLL output. Also, for the flash the MCK must be outside 3-19 MHz range. I'd re-check the math behind this problem.
See erratum: 40.1.2.1 MCK: Limited Master Clock Frequency Ranges in 6175E–ATARM–04-Apr-06
I did run this MCU overclocked to about 70 MHz (core clock) before it quit. You must be driving it harder yet, IMHO.
MCK = CRYSTAL * (MUL+1) / (DIV*2) = 20M * 1402 / 510 = 54.98Mhz
which is less than the max allowable MCK of 55 MHz, right? These settings should make a PLLCK of ~ 110 MHz, which is in spec too, right? I'm using 1 wait state for flash reads.
However, I did find out that I had violated the min input frequency spec for the PLL of 1 MHz (shame on me!). So, I changed DIV to 20 and MUL to 109 to try to get a 55 MHz MCK with my 20 MHz crystal.
MCK = 20M * (109+1) / (20*2) = 55 Mhz
Do you see a problem with that math? These settings don't work either. I had to reduce MUL till MCK was 28.5 MHz or less before I could get my toggling I/O pin program to start up and run reliably.
Still confuzed... Dave.
Do you see a problem with that math?
Not now. :-) PLL min/max seem to be okay, now.
BTW, do you wait for the PLL to settle down after programming the MUL and DIV, I suppose you are?
while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_LOCK)); while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY));
Is your AT91C_CKGR_PLLCOUNT sufficient for the setup time?
Then I would re-check the PLL's ext. RC values. There is a new release (v2.31) of the spreadsheet PLL calculator.
Good luck, man! :-)