Harold Ritter wrote:
> I have been developing an application using Yagarto and an AT91SAM7S256.
> I have the Timer, PIO, and USART0 all working with interrupts stand
> alone and in the debugger. I then added SPI driver code and it works but
> only if I start it in the debugger. It will not run if I just power down
> and then power back up.

At least I can not help without further information.
- Does the "SPI driver" work in a minimal stand-alone application?
- Does the "SPI driver" use interrupts?
- Please create a minimal but build-able example to reproduce the issue,
pack it and attach it to form-message.

I have solved the problem by writting the PMC_PCER prior to any SPI
register writes. I could not find anything in the data sheet that states
this. The data sheet states for the other peripherals that the clock
does not need to be enabled to set the peripheral up. My habit has been
to write the peripherl registers them write the PMC_PCER to enable the
clock. Then write the AIC registers to enable the interrupt.

I played a hunch and write the PMC_PCER register enabling the clock to
the SPI prior to setting up the SPI registers. This solved the problem.

Thank you Martin for your time and consideration.

I have not used the conventional programming model that everybody else
here seems to have used. I do not use pre-written functions to setup my
hardware because I like to understand what is going on and how to
perform the low level stuff. I also completely bastardized AT91SAM256.H
because I did not want to type "AT91C_" 10,000 times to get an
application finished so I removed every instance of it in the .h file.

If you would like to see my code you are more than welcome.

Harold

Martin Thomas wrote:
> Harold Ritter wrote:
>> I have been developing an application using Yagarto and an AT91SAM7S256.
>> I have the Timer, PIO, and USART0 all working with interrupts stand
>> alone and in the debugger. I then added SPI driver code and it works but
>> only if I start it in the debugger. It will not run if I just power down
>> and then power back up.
>
> At least I can not help without further information.
> - Does the "SPI driver" work in a minimal stand-alone application?
> - Does the "SPI driver" use interrupts?
> - Please create a minimal but build-able example to reproduce the issue,
> pack it and attach it to form-message.

Harold Ritter wrote:
> I have solved the problem by writting the PMC_PCER prior to any SPI
> register writes. I could not find anything in the data sheet that states
> this. The data sheet states for the other peripherals that the clock
> does not need to be enabled to set the peripheral up. My habit has been
> to write the peripherl registers them write the PMC_PCER to enable the
> clock. Then write the AIC registers to enable the interrupt.
>
> I played a hunch and write the PMC_PCER register enabling the clock to
> the SPI prior to setting up the SPI registers. This solved the problem.

Glad to read that it is working for you now. I think a lot of starters
struggle with this. I did not know that for some peripherals the clock
does not need to be enabled to use their registers. Usually I enable the
clock first.

> Thank you Martin for your time and consideration.
>
> I have not used the conventional programming model that everybody else
> here seems to have used. I do not use pre-written functions to setup my
> hardware because I like to understand what is going on and how to
> perform the low level stuff. I also completely bastardized AT91SAM256.H
> because I did not want to type "AT91C_" 10,000 times to get an
> application finished so I removed every instance of it in the .h file.

Well, it's a matter of taste. I would not use the approach since
- most of the inline-functions in the lib_at91 are that "lite" that one
can easily see what they do and they cause a minimal (if any) "size
overhead".
- Atmel and "everybody else" is used to this "model" and it's easier to
help if well known names for lib-functions and constants/defines are
used. I.e. if you did not find the issue yourself and showed your code
one if the first steps I would have done would have been searching for
AT91F_SPI_CfgPMC.
- It is easier to re-use code from Atmel and others who also use at91.h,
and lib_at91.h and it's easier to port code to another AT91.
- (I type fast enough so the AT91C_ prefix does not matter to me)

> If you would like to see my code you are more than welcome.

If you have some example application which would like to see
downloadable I can place it on my "at91-page" of cause with proper
reference and credits.

Martin