--- In lpc2000@lpc2..., 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?

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
	

brendanmurphy37 wrote:

>--- In lpc2000@lpc2..., 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..."
----------------
	

--- In lpc2000@lpc2..., Tom Walsh <tom@...> wrote:

> 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'd guessed you'd seen it OK, but just in case you weren't aware
of 
it....

The behaviour you describe certainly seems odd, and like you say, 
though the work-around works, I'd be a bit worried too that it could 
fail (on the basis that it's to get around unexplained rather than well 
understood behaviour).

I'd be inclined to reduce the software as much as possible to try and 
isolate the behaviour. This will either identify the source of the 
problem, or if not, should give something small and manageable that 
Philips could take a look at.

Let us know the outcome if you go down this route.

Brendan
	

At 08:16 AM 3/10/2006 +0000, Danish Ali wrote:
>That's a very useful page. (I can't vouch
for the chinese-like
>text at the bottom) but I still say it should be an _official_
>Philips document, so those who start with (say) an lpc2148 and
>then say "I need more pins" can move to an lpc2294 knowing the
>areas which require attention even if they only know documents
>from Philips.
	It might be nice but the wiki is capable of responding far faster than 
Philips bureaucracy.

Mutter, spammers.  Spam removed from various pages now.  BTW community help 
in keeping the pages up to date and clean of spam is appreciated (even if 
I'm not the owner of the site I feel confident in that statement)

Robert

" 'Freedom' has no meaning of itself.  There are always
restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/