Hi All
There is a modification that is recommended for the ATMEL SAM7X PLL initialisation code. I will start with the lines of code that should be changed and then explain the reasons for this:
1) In sam7x.h: Extend the bit defines of the Power Management Controller Status Register (PMC_SR):
#define PMC_SR *(volatile unsigned long*)(PMC_PERIPHERAL_BLOCK + 0x68) // Status Register (read only)
#define MOSCS 0x00000001
#define PLL_LOCK 0x00000004
#define MCKRDY 0x00000008
#define PCKRDY0 0x00000100
#define PCKRDY1 0x00000200
#define PCKRDY2 0x00000400
#define PCKRDY3 0x00000800
2) In AT91F_LowLevelInit(), in sam7x.c modify the way that the prescaler and PLL are selected:
from
PMC_MCKR = (SELECT_PLL | CLK_PRES); // {39} finally set the master clock to half the PLL value
to
PMC_MCKR = CLK_PRES; // first program the prescale and wait for ready
while (!(PMC_SR & MCKRDY)) {} // wait for the master clock status to indicate ready
PMC_MCKR = (SELECT_PLL | CLK_PRES); // {39} finally set the master clock to half the PLL value
while (!(PMC_SR & MCKRDY)) {} // wait for the master clock status to indicate ready
It has been identified that with the original code, boards tested over expended temperature ranges (-45C to °85°C) could have start-up problems. At temperature extremes some boards would not start although under less extreme conditions they started reliably. Studying the most recent user's manual showed that it explicitly warns from setting both SELECT_PLL and CLK_PRES bits in a single write. After each modification the MCKRDY bit should also be waited for.
This was rather surprising since this sounds like an obvious piece of advice that was not respected. So the user's manual was compared with the original user's manual (thankfully there was still a copy) which was used for the original development. In the original manual it states "All parameters in PMC_MCKR can be programmed in a single write operation".
So the question is, why did this change? Checking the errata sheets, which are monitored throughout the life of the project, there is no mention of a workaround required. But in the documentation revision notes there is reference to a Change Request number 05-506. So the conclusion is that the change was made in a user's manual release but not considered required as workaround due to errata, which is a shame as it is then not obvious.
Apart from these extreme tests (which worked reliably after the modification) there have otherwise not been any reports of such a problem so it is probably also not that serious. But it is certainly recommended for any new SW revisions ;-)
Regards
Mark