Hi.
I had no time to enter in depth regarding your problem but when
I read your phrase:
"I cannot explain why the SPIF bit is missed however. That appears to
be a race condition in the silicon where a co-incidence of reading
from the SPI status register vs. the AHB writing into the status
register... ???"
I remembered the errata document for the LPC2138 processor where
similar problems are documented for both the timer and the uart.
If you write a register via software at the same time that hardware
want to write the same register, the hardware write is not performed.
For timer this occurs when you are clearing a timer match interrupt
(ex. interrupt on match0) and another match occurs at the same time
(ex. match1): the match interrupt is never generated.
For uart this occurs if you read the IIR register, clearing the THRE
bit and at the same time the transmitter register become empty so that
hardware want to set the THRE bit: the bit is never set, the interrupt
is never generated.
The consequence is: if timers and uarts have these problems, why not
the SPI?
Have you checked the ERRATA for the LPC2106?
Anyway, I agree that "there is absolutely no information nor timing
diagrams detailing the relationship of: the SPIF bit, shift clock, and
interrupts. Again, the Philips docs are sadly lacking in detail on
critical issues (see discussion in this group messages regarding the
ADC leakage)."
I know of my colleague working with SPI on LPC2138 and finding a lot
of problems.
I think that Philips failed create a microcontroller with "robust"
peripherals to be used in industrial environment.
Unfortunately (or fortunately??) it is very cheap, and this attract
the marketing peoples (the programmers will patch the code in one mode
or another...)
Good luck,
Carlo
--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
>
> Oh, just some further information. The LPC2106 is running the SPI
> under interrupts while the LCP2138 is not. Here is a sample of the SSI
> bit polling on the LPC2138:
>
> ========== begin spiPutByte() ============
>
> static void spiPutByte(uchar inBuf)
> {// spit a byte of data at the MMC.
> SSPDR = (REG16) inBuf; while (SSPSR & SSP_BSY);
> // dummy read clears SPI BSY flag on LPC2xxx processors.
> dummyReader = (uchar) SSPDR;
> }
>
> =============== snip ===============
>
> I am not yet using the SPI on the LPC2138, so that doesn't prove
> anything other than the SSI is more durable?
>
> TomW
>
>
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>Message
Re: SPI Code hangs
2006-03-09 by c.barbaro
Attachments
- No local attachments were found for this message.