Lpc2000

brendanmurphy37 wrote:

>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@...> wrote:
>  
>
>>What I'd found was that this state machine / VICSoftInt 
>>mechanism would run fine for a while, then randomly the SPI ISR would 
>>deadlock looking for the SPI completion bit.  The only way I've found 
>>out of that deadlock was to put a timeout in the code which looks at 
>>    
>>
>the 
>  
>
>>completion bit:
>>    
>>
>
>Tom,
>
>I presume you've seen and taken account of the LPC2106 erratum, 
>specifically the item "unintentional clearing of SPI interrupt flag" in 
>your investigations?
>
>  
>
Thank you, I am aware of that document.  It doesn't pertain to the 
problem we are seeing.  The problem we are seeing is that at random 
intervals the SPIF flag does not get set.  For myself, I have an ISR 
which is triggered by the SPINT request, at the top of the ISR I loop 
looking for the SPIF flag to be set.  Randomly, this flag fails to be 
asserted by the hardware.  This causes my ISR to deadlock.

I had found that even if you got an SPINT which brough you into the ISR, 
you cannot write into the SPDR until SPIF is set.  Otherwise a WCOL 
would be raised.  So, you have to wait in the ISR until SPIF is raised, 
usually this takes 10..20 interations of a simple for() loop polling the 
SPIF bit.  However, randomly the SPIF bit is never raised, thus leaving 
you deadlocked awaiting that bit.

My, rather inelegant, solution was to put a max interation count to the 
loop and record the max value of the loop when it found a valid SPIF 
bit.  Then I took that value and increased it to what I felt was a 
"worst case" loop value.

So far this has worked, the SPI has run for many hours servicing the 
UARTs under moderate load without a lockup or noticable data loss.  I am 
concerned that although this does work (the max count) it may be that 
later, when the product is released, that data loss may show up!

The SPI of the LPC2106 seems to be rather fragile...

Regards,

TomW


>I'm not saying this is the cause of the behaviour you're seeing, but if 
>you haven't looked into this, it might be worth doing so.
>
>Brendan
>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------