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 !!
Very good points... thanks!! And yes, I am aware of them. However, for this trivial test project, no interrupts were ever enabled. The only thing the program did was:
1 - enable the external hardware reset input 2 - configure one I/O pin as an output 3 - toggle that I/O pin a few times 4 - assert the software controlled reset input to the reset controller.
This code failed on all but one of the SAM7S256 boards I've got (once they ran for a while and warmed up). The point of jumping to the reset vector rather than asserting the reset input to the reset controller was to help isolate the problem to the reset controller, or something associated with coming out of a hardware reset, as opposed to something with just running code from FLASH.
I certainly do appreciate your insightful response.
Dave.
The SAM7S datasheet provides a bit in the reset controller's status register (SRCMP) to provide a method to tell if any part of a software generated reset is in progress or not. The text goes on to state that when this bit is cleared, it's okay to write to the reset controller's registers. This implies that it's not okay to write to the reset controller's mode register if any part of a software generated reset is still active.
Why bring this up? Okay, I know this is a stretch, but it looks like the very first part of the KEIL generated startup code in SAM7.s writes to the reset controller's mode register. It would seem logical that if the SAM7S is executing code, no part of any software generated reset could still be active, but maybe that's not the case.
Now for the request for help...
I'm not an ARM assembly language programmer (yet). Can someone show me how to modify the default KEIL SAM7.s file to include a loop that waits for the SRCMP bit in the reset controller's status register to be clear before advancing (to the part that writes to the reset controller's mode register)?
I'd sure appreciate it. It'd be easy to test to see if that fixes my RSTC problem.
Thanks, Dave.
P.S. I have received additional different date code parts (much newer than the parts I had), and all date code parts I've tested to date have this problem (once the chips warm up enough, which is usually somewhere between 85°F and 100°F). Even chips I earlier thought did not have this problem. A fair amount of the chips I have won't show this symptom till they've been warmed up using a heat gun. It usually takes only 2 or 3 seconds of heat from a heat gun to make the chips fail. A couple of the chips had to be warmed to ~ 145°F before they failed.
I'd sure like to get to the bottom of this one !!