We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Okay... admittedly this is slightly off topic, since I don't think it really has anything to do with the KEIL tools per se, but I am using KEIL tools on this project. I originally posted this on AT91.COM, but since that forum gets so little traffic I'm cross posting here hoping that someone can help.
I created an ASSERT macro for my project and noticed something funny. Basically, my ASSERT macro dumps the expression, filename and line number out the debug UART and then attempts to reset the micro by writing to the reset controller. Sometimes the macro works, sometimes it doesn't. When it doesn't work, the symptom is that the micro does not appear to come out of reset. After much investigation and trial and error I tried to reset the micro using a different method. I called the reset vector as shown below:
((void(*)(void))0x100000)(); // reset vector is 0x100000
Using the above method to reset the micro seems to make my ASSERT macro work rock solid.
My question is, does anyone know about any problems or common mistakes with getting the processor to reset via the RSTC...? Here's how I used the RSTC to reset the micro:
typedef volatile unsigned int * pMR; // pointer to microcontroller register #define RSTC_CR (*((pMR) 0xFFFFFD00)) #define RSTC_CR_PROCRST ((unsigned int)1 << 0) #define RSTC_CR_PERRST ((unsigned int)1 << 2) #define RSTC_KEY(x) ((unsigned int)(x) << 24) RSTC_CR = RSTC_CR_PROCRST | RSTC_CR_PERRST | RSTC_KEY(0xA5);
Can anyone tell me whether they see something wrong with how I'm trying to reset the micro as shown above, or how I should do it differently...?
Thanks !!
ATMEL tech support in Rousset informed me that the configuration wizard generated code for this part was flawed in the part where it switched MCK. The datasheet requires a certain procedure to correctly switch MCK, which was not done in the code generated by KEIL's configuration wizard. When I changed my code per Rousset's suggestions, my temperature sensitivity problems appear to have been fixed, and the reset controller appears to now work flawlessly.
I've forwarded Rousset's suggestion to KEIL's tech support in the form of a bug report.
Here's Rousset's comments:
Here is an extract from the datasheet (PMC section): If a new value for CSS field corresponds to PLL Clock, – Program the PRES field in the PMC_MCKR register. – Wait for the MCKRDY bit to be set in the PMC_SR register. – Program the CSS field in the PMC_MCKR register. – Wait for the MCKRDY bit to be set in the PMC_SR register.
However, they do not program correctly the PMC. They have programmed the MCKR in one time and they have forgotten to wait the MCKRDY flag which is mandatory to be sure they system clock has correctly switched on...
So, it should be more:
PMC_MCKR_Val1 EQU 0x00000004 PMC_MCKR_Val2 EQU 0x00000007 PMC_MCKRDY EQU (1<<3) ; MCK Ready Status ; Program 1st PRES field LDR R1, =PMC_MCKR_Val1 STR R1, [R0, #PMC_MCKR] ; Wait until MCK is stabilized MCK_Loop1 LDR R2, [R0, #PMC_SR] ANDS R2, R2, #PMC_MCKRDY BEQ MCK_Loop1 ; Then program CSS field LDR R1, =PMC_MCKR_Val2 STR R1, [R0, #PMC_MCKR] ; Wait until MCK is stabilized MCK_Loop2 LDR R2, [R0, #PMC_SR] ANDS R2, R2, #PMC_MCKRDY BEQ MCK_Loop2