AT91SAM7S256 and the RSTC register...

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 !!

Parents
  • I'm wondering if there's a relation between the above problem and another problem I've been experiencing for some time now. The other problem is that sometimes after I do a build and load the code into my target via KEIL's ULINK tool it just won't run. When this happens I usually try something like:

    1 - loading it again
    2 - doing a build all and try again
    3 - toggle the hardware reset switch input and try again
    4 - cycle power on the target and try again
    5 - cycle power on the ULINK and try again
    6 - restart the KEIL IDE and try again
    7 - revert to a prior working version of the code and try again
    8 - load the code into the board via the debugger and single step into it
    9 - etc., etc., etc.

    Sometimes any one of the above will make the problem go away, but eventually, the very code that wouldn't load and run will load and run just fine. The oddest case is when all the easy steps don't fix the problem, I then try things with the debugger and everything works fine. After that, I can once again just load code and run with no problems.

    I currently don't suspect my hardware, as the stuff around the micro (i.e., the crystal & cap's, JTAG interface, RESET input, etc.) were directly copied from an ATMEL eval board

    Has anyone else experienced problems reliably loading and running code on an AT91SAM7 part using KEIL's ULINK tool?

    Does anyone have any suggestions to make loading and running code via the ULINK reliable?

    HELP... (please)...
    Dave.

Reply
  • I'm wondering if there's a relation between the above problem and another problem I've been experiencing for some time now. The other problem is that sometimes after I do a build and load the code into my target via KEIL's ULINK tool it just won't run. When this happens I usually try something like:

    1 - loading it again
    2 - doing a build all and try again
    3 - toggle the hardware reset switch input and try again
    4 - cycle power on the target and try again
    5 - cycle power on the ULINK and try again
    6 - restart the KEIL IDE and try again
    7 - revert to a prior working version of the code and try again
    8 - load the code into the board via the debugger and single step into it
    9 - etc., etc., etc.

    Sometimes any one of the above will make the problem go away, but eventually, the very code that wouldn't load and run will load and run just fine. The oddest case is when all the easy steps don't fix the problem, I then try things with the debugger and everything works fine. After that, I can once again just load code and run with no problems.

    I currently don't suspect my hardware, as the stuff around the micro (i.e., the crystal & cap's, JTAG interface, RESET input, etc.) were directly copied from an ATMEL eval board

    Has anyone else experienced problems reliably loading and running code on an AT91SAM7 part using KEIL's ULINK tool?

    Does anyone have any suggestions to make loading and running code via the ULINK reliable?

    HELP... (please)...
    Dave.

Children
More questions in this forum