> any idea what the return might be doing to cause problems?

No idea at all. Very unexpected. You'd think that a seemingly
innocuous instruction would have no affect on a bit in an un-related
register. I mean 'return' ? What can go wrong with 'return' ?

> Have you had a look at what is happening to the various registers
> involved?

No, not even sure if it's worth pursuing TBH

> How exactly does it not work - does it even load SPI1BUF the
> first time round?

There's a sequence of SPI commands to an SDHC card. The
final one is ACMD41, which is where you wait for the card to
finish initialising. With the working code, the loop goes back and
re-issues the ACMD41 until the required response. With the
non-working code, the SPI does the sequence correctly but at
the looping just spits out FFs forever instead of the 12-byte
ACMD41 string, so it's obviously off with the fairies somewhere

I discovered *this* when I discovered the fault with SPIROV
and thought it would be a good idea to include its blcr in the
send routine to save typing and cycles

I've put a ticket in to MChip support to see if they can confirm that
there's a SPIROV bug they didn't know about (plus I can add this
oddity to the pile)

Because the project I'm working on is dependent on SPI I think
I have a case for a refund or bugless replacements under "fit for
purpose". Simply don't trust this IC any more

For the time being, got Duckman DVDs that need watching ;-)))

Joe
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.