AT91SAM7S256

That fixed my problem, also! I think the debugger changes the MCLK to
the fast clock, which would explain why I could run in the first place
at 55 MHz only while debugging. So you're right - you have to
manually set to the slow clock before doing that configuration. This
makes debugging MUCH easier!
--- In A..., "techguy2000" wrote:
> I hit the same problem with the debugger. Debuggers tend to step in
> and set stuff up, especially if they're programming flash, and may set
> things up in bad ways for some of the other initializations that your
> code is attempting to do once the debugger releases control.
>
> The fix is to make sure that slow clock is the selected clock before
> doing any of the initializations that expect slow clock to be active.
> I do this prior to setting up the flash wait states:
>
> /* insure we're on the slow clock */
> pPMC->PMC_MCKR &= ~0x03;
> while(!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
>
> This solved the debugger problem for IAR/Jlink.
>
> -Cliff
>
> --- In A..., "ryan100patterson"
> wrote:
> >
> > Cliff,
> >
> > You're a genius! I've been trying to figure out this problem all
> > year, and eventually resorted to running at only 50 MHz on most of my
> > projects. I've gone through the user's manual many times and never
> > caught this...
> >
> > So I've implemented the code as you suggested, and it runs on the
> > slowest silicon AT91SAMs that I have.
> >
> > However, I've found that this code change causes my processor to lock
> > up when debugging. The debugger gets stuck on:
> >
> > while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
> >
> > If I watch pPMC-PMC_SR, I see that it has the value 5. However, if I
> > step through this section of code, it has the value 13, and therefore
> > succeeds. Does anybody have any idea why the MCKRDY bit wouldn't get
> > set in PMC_SR while running in the debugger? Also, if I program the
> > device and let it run without the debugger attached, it works just
fine.
> >
> > Thanks!
> >
> > Best Regards,
> > Ryan
> >
> >
> >
> > --- In A..., "techguy2000" wrote:
> > >
> > >
> > > I may have found what may be the "real" problem. It's actually in
> > > the user manual, but was implemented incorrectly in the example code
> > > we were working from (which I think was originally from Atmel).
> > >
> > > When writing to the PMC_MCKR register, you update one field, wait
> > > for MCKRDY, then update the other field and wait for MCKRDY again.
> > > Which field you write first depends on which clock is being
selected.
> > > It's in the "Programming Sequence" section for the PMC
controller in
> > > the manual.
> > >
> > > Doing that, with all other delays and other extraneous code
removed
> > > from the init routine I'm using changed a device that would fail
> > > consistently using the single write method and work consistently
doing
> > > two writes.
> > >
> > > So for me going from slow clock to PLL clock:
> > >
> > > pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_SLOW_CLK;
> > > while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
> > > pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2 | AT91C_PMC_CSS_PLL_CLK;
> > > while (!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));
> > >
> > > Slow clock was already selected when entering this code.
> > >
> > > Is anyone that is seeing this problem while doing the double write
> > > to the PMC_MCKR register?
> > >
> > > Cliff
>
Start a New Thread