This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AT91SAM7S256 not coming out of RESET...

Okay... this may be slightly off topic... I'm suspecting hardware more than software.

Here's the problem... I've done KEIL projects for AT91SAM7S32 and AT91SAM7S64 boards and the hardware has always come out of reset and started to execute code reliably when not using the debugger.

Now I've tried (2) different AT91SAM7S256 designs, and they've both behaved differently in that sometimes the code just doesn't appear to come out of reset reliably. I simplifed both projects to do nothing but configure the H/W reset input and an I/O pin to be a driver, and then toggle that I/O pin in an infinite loop but that code does not run reliably. I am using a 4-layer board with a ground plane, and all the oscillator, reset and JTAG port stuff is a direct cut/paste from my working designs using the S32 & S64 parts.

I added code to enable a ~1 second watchdog timer, and that seems to fix the problem, in that when the I/O pin doesn't toggle after a power up reset or hardware reset it does come to life after ~1 second when the watchdog timer times out.

Does anybody know of anything that could be responsible for this type of symptom...?

Thanks,
Dave.

Parents
  • I'm using a 20 MHz crystal, with 1 flash read wait state, with MUL = 1401 and DIV = 255.

    BTW, there is a limit of 180 MHz for the f_PLL output. Also, for the flash the MCK must be outside 3-19 MHz range. I'd re-check the math behind this problem.

    See erratum:
    40.1.2.1 MCK: Limited Master Clock Frequency Ranges
    in 6175E–ATARM–04-Apr-06

    I did run this MCU overclocked to about 70 MHz (core clock) before it quit. You must be driving it harder yet, IMHO.

Reply
  • I'm using a 20 MHz crystal, with 1 flash read wait state, with MUL = 1401 and DIV = 255.

    BTW, there is a limit of 180 MHz for the f_PLL output. Also, for the flash the MCK must be outside 3-19 MHz range. I'd re-check the math behind this problem.

    See erratum:
    40.1.2.1 MCK: Limited Master Clock Frequency Ranges
    in 6175E–ATARM–04-Apr-06

    I did run this MCU overclocked to about 70 MHz (core clock) before it quit. You must be driving it harder yet, IMHO.

Children
  • MCK = CRYSTAL * (MUL+1) / (DIV*2) = 20M * 1402 / 510 = 54.98Mhz

    which is less than the max allowable MCK of 55 MHz, right? These settings should make a PLLCK of ~ 110 MHz, which is in spec too, right? I'm using 1 wait state for flash reads.

    However, I did find out that I had violated the min input frequency spec for the PLL of 1 MHz (shame on me!). So, I changed DIV to 20 and MUL to 109 to try to get a 55 MHz MCK with my 20 MHz crystal.

    MCK = 20M * (109+1) / (20*2) = 55 Mhz

    Do you see a problem with that math? These settings don't work either. I had to reduce MUL till MCK was 28.5 MHz or less before I could get my toggling I/O pin program to start up and run reliably.

    Still confuzed...
    Dave.

  • Do you see a problem with that math?

    Not now.
    :-)
    PLL min/max seem to be okay, now.

    BTW, do you wait for the PLL to settle down after programming the MUL and DIV, I suppose you are?

      while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_LOCK));
    
      while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY));
    

    Is your AT91C_CKGR_PLLCOUNT sufficient for the setup time?

    Then I would re-check the PLL's ext. RC values. There is a new release (v2.31) of the spreadsheet PLL calculator.

    Good luck, man!
    :-)