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 !!
Hmmm... I tried the code on an (similarly configured) ATMEL eval board and guess what...? The code runs just fine. So, I found another (different design) SAM7S256 based board and guess what...? The code runs just fine on that board too. Something tells me I've probably got a hardware problem after all. I guess that's good news.
After much hardware investigation, the only difference I could find between AT91SAM7S256 boards that worked and those that didn't was the date code of the microcontroller.
I found that if I put different date code chips on my boards (that weren't working reliably) they started working just fine. Unfortunately, the date codes for the parts that work (0604) are earlier than the ones that don't work (0621). That's not good.
0604 = 4th week of 2006 0621 = 21st week of 2006
My local ATMEL FAE and distributor are bringing me a few different date code parts for me to try to see what happens. Hopefully some of them will be fairly current.
I realize this has nothing to do with KEIL tools, but I'd just like to get closure for this thread.