--- In l..., "shwouchk" wrote:
>
> Hi!
>
> Sorry for taking long to respond - I had IT problems... :)
>
> Anyway, I saw that table, and it reiterated what you said and what I
> knew - that it was fine to use 0.7 as out even when the rest of the
> SPI pins are in SPI mode, but just to make sure I changed the pin...
> Why are you pulling 0.7 high - can it not be used as out in 2148?
> Thanks for the init code - I'll look into it and see if it helps any.
>
> Regards,
> Kosta.

I started out using the LPC2106 where P0.7 can ONLY be used as a slave
select input and must be pulled high if the SPI gadget is to be used
as a master.

When I moved the code to the LPC2148, I didn't bother to change things
around because it worked just fine. Besides, on the Olimex P2148
board, the pin is pulled high with a 10k resistor - I didn't have to
add it. With this arrangement, several off-board devices could pull
the line low to select the 2148 as a slave.

One day, if I get interested, I may change the 2148 code to use P0.7
as a GPIO and as a device select signal for the PS/2 controller.

Richard

An Engineer's Guide to the LPC2100 Series

> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of shwouchk
> Sent: Friday, August 10, 2007 8:03 PM
> To: l...
> Subject: [lpc2000] Re: lpc2138 SPI not working
> Hi!
>
> Sorry for taking long to respond - I had IT problems... :)
>
> Anyway, I saw that table, and it reiterated what you said and what I
> knew - that it was fine to use 0.7 as out even when the rest of the
> SPI pins are in SPI mode, but just to make sure I changed the pin...
> Why are you pulling 0.7 high - can it not be used as out in 2148?
> Thanks for the init code - I'll look into it and see if it helps any.
>
> Regards,
> Kosta.
>

P0.7 can be used for alternate functions on an LPC2148, but on some
other LPC parts this can only be used as the SS input when the SPI is used.

Mike

Hi!

Sorry for taking long to respond - I had IT problems... :)

Anyway, I saw that table, and it reiterated what you said and what I
knew - that it was fine to use 0.7 as out even when the rest of the
SPI pins are in SPI mode, but just to make sure I changed the pin...
Why are you pulling 0.7 high - can it not be used as out in 2148?
Thanks for the init code - I'll look into it and see if it helps any.

Regards,
Kosta.

--- In l..., "rtstofer" wrote:
>
> I think we are leading you astray! On the LPC2138 the SSEL0 pin can
> be used as GPIO if the SPI0 gadget is to be a master only. Check
> Table 126 Section 12.3 'Pin description' of the User Manual.
>
> I have a program for the LPC2148 that interfaces with a PS/2 game
> controller using SPI. The initialization code is:
>
> // set up SPI
>
> PINSEL0 |= 0x00005500; // set proper bits for SPI
> SPI_SPCR = SPI_MSTR | SPI_CPOL | SPI_CPHA | SPI_LSBF; // set spi as
> a master
> SPI_SPCCR = SPI_DIVIDER; // set divider
>
> Sending a byte (send a command, ignore the returned byte) looks like:
>
> void spiSendByte(unsigned char c)
> {
> SPI_SPDR = c;
> while (!(SPI_SPSR & SPI_SPIF))
> ;
> }
>
> Transferring a byte (send a byte, return to caller the returned byte)
> looks like:
>
> unsigned char spiTransferByte(unsigned char c)
> {
> SPI_SPDR = c;
> while (!(SPI_SPSR & SPI_SPIF))
> ;
> return SPI_SPDR;
> }
>
> The main code which simply reads the game controller and prints the
> results looks like:
>
> int
> main(void)
> {
> unsigned char i, reply[8];
>
> Initialize();
>
> while (1)
> {
> IOCLR = PS_SELECT; // set slave select bit low
>
> delay(SPI_DELAY); // give the device a chance to react
> spiSendByte(0x01); // send start command
>
> delay(SPI_DELAY);
> reply[0] = spiTransferByte(0x42); // send ID, device should send 0x41
> or 0x73
>
> for (i = 1; i < (reply[0] == 0x73 ? 8 : 4); i++)
> {
> delay(SPI_DELAY);
> reply[i] = spiTransferByte(0xFF);
> }
> IOSET = PS_SELECT; // set slave select high
>
> for (i = 0; i < (reply[0] == 0x73? 8 : 4); i++)
> {
> puthex(reply[i]);
> putch(' ');
> }
>
> putCRLF();
> }
> return 0;
> }
>
> For my project, I used P0.15 as the device select output to the game
> controller (PS_SELECT). I pulled P0.7 (SSEL0) high and did not use it
> for any other function.
>
> Richard
>

Hi!

Sorry it took me a while to reply - I had severe IT problems... :)

Anyway, it is very hard for me to tell, since I don't have an
oscilloscope right now. The voltmeter shows a tiny spike in voltage,
which could mean the clock is working, but I can't be sure.

what do you mean about the firmware test loop?

Regards,
Kosta.

--- In l..., Alexandre Kremer wrote:
>
> Hi
>
> Could you see if, at least the clock and data are
> comming out from ARM to the other device ?
> Maybe the problem isnt with micro controller code.
> Try to put a test loop on firmware to see if the cpu
> sends the signals correctly.
>
> Regards
>
> --- shwouchk escreveu:
>
> > Thanks for the response!
> >
> > Unfortunately, although might be a bit unclear from
> > the parts I
> > pasted, I do not use the SSEL pin in SPI mode, but
> > rather in GPIO
> > mode, so I don't think that this is the cause of my
> > problems...
> > (morever, after I couldn't get it to work I decided
> > to move it from
> > 0.7 entirely... now it's on 0.2)
> >
> > Any other ideas?
> >
> > Thanks in advance,
> > Kosta.
> > --- In l..., Alexandre Kremer
> > wrote:
> > >
> > > This is a common mistake people do with LPC�s
> > spi
> > > interface.
> > > I think your problem is that you are taking the
> > SSEL
> > > pin as a Chip Select for other devices. Well, this
> > pin
> > > isn�t a chip select, but a SLAVE SELECT.
> > > The SLAVE SELECT functionality serves to turn the
> > > ARM�s SPI from MASTER MODE to SLAVE MODE, so
> > another
> > > device on the bus can take it as a Master by
> > putting a
> > > low level on this ARM�s pin. It doesn�t select
> > > external devices as slave, but it makes the micro
> > > controller act as a slave.
> > > Try to put a 10K pull up on this pin and
> > disconnect
> > > it from any other device.
> > > Also it is an INPUT ONLY, so things like IOSET0 > > > SPI_SSEL; or IOCLR0 = SPI_SSEL; won�t produce
> > any
> > > effect when SSEL pin is configured with SPI
> > > functionality.
> > > So, i suggest you to use another GPIO as a chip
> > > select for your micromag device.
> > >
> > > Regards
> > >
> > >
> > > --- shwouchk escreveu:
> > >
> > > > Hi!
> > > >
> > > > Ive been working at it for at least a week and I
> > > > can't find the reason
> > > > why I can't get SPI to work - I haven't looked
> > with
> > > > a scope, but I'm
> > > > pretty sure that the the device doesn't even
> > send
> > > > out a clock...
> > > > otherwise it seems to work fine, which is why
> > I'm
> > > > stumped.. This is
> > > > most of the code which runs the SPI - can anyone
> > > > spot anything obvious?
> > > >
> > > > P.S.
> > > > I'm using a device which uses a modified version
> > of
> > > > SPI - it also
> > > > needs a reset pin.
> > > > The code hangs in the while loop which wait for
> > > > SPIF...
> > > >
> > > > The following two functions are called one after
> > the
> > > > other:
> > > >
> > ===================================================> > > >
> > > > struct MicroMag_Command; // size uint8_t
> > > >
> > > > void vSPI_MicroMag_Init(void)
> > > > {
> > > > PINSEL0 |= SPI0_PINS; // Configure SPI0 pins.
> > > > IODIR0 |= SPI_EXTRA_PINS; // SSEL and RESET
> > which
> > > > are GPIO controlled.
> > > > IOSET0 = SPI_SSEL; // Deselect the MicroMag.
> > > > (Active low)
> > > > IOCLR0 = SPI_RESET; // Set the reset pin low.
> > > >
> > > > // It is usually set at 60 (while the pll runs
> > at
> > > > ~59mhz)
> > > > S0SPCCR = 100; // Configure The SPI clock
> > divider.
> > > >
> > > > // Configure and set the default transfer
> > > > attributes:
> > > > S0SPCR_bit.BITENABLE = 0; // 8 bits.
> > > > S0SPCR_bit.CPHA = 0;
> > > > S0SPCR_bit.CPOL = 0;
> > > > S0SPCR_bit.MSTR = 1; // Master.
> > > > S0SPCR_bit.LSBF = 0; // MSB First.
> > > > S0SPCR_bit.SPIE = 0; // No SPI Interrupts.
> > > > S0SPCR_bit.BITS = 0; // 16 bits if BITENABLE > > > > true;
> > > > }
> > > >
> > > >
> > > > void vSPI_MicroMag_SendMeasureCommand(void)
> > > > {
> > > > IOCLR0 = SPI_RESET; // Set RESET low.
> > > > IOCLR0 = SPI_SSEL; // Select the MicroMag.
> > > >
> > > > S0SPCR_bit.BITENABLE = 0; // 8 bits.
> > > >
> > > > IOPIN0 ^= SPI_RESET; // Toggle RESET high.
> > > > WAIT(10);
> > > > IOPIN0 ^= SPI_RESET; // Toggle RESET low.
> > > > WAIT(10);
> > > >
> > > > SSPDR = *((uint8_t *) (&SPI_MicroMag_MMC)); //
> > Send
> > > > the command.
> > > >
> > > >
> > > > // This is where it gets stuck:
> > > > while (S0SPSR_bit.SPIF == 0); // Wait until the
> > > > transfer completes.
> > > >
> > > > IOSET0 = SPI_SSEL; // Deselect the MicroMag.
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Alertas do Yahoo! Mail em seu celular. Saiba
> > mais em
> > http://br.mobile.yahoo.com/mailalertas/
> > >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> > Flickr agora em portugu. Vocclica, todo mundo v
> http://www.flickr.com.br/
>

I think we are leading you astray! On the LPC2138 the SSEL0 pin can
be used as GPIO if the SPI0 gadget is to be a master only. Check
Table 126 Section 12.3 'Pin description' of the User Manual.

I have a program for the LPC2148 that interfaces with a PS/2 game
controller using SPI. The initialization code is:

// set up SPI

PINSEL0 |= 0x00005500; // set proper bits for SPI
SPI_SPCR = SPI_MSTR | SPI_CPOL | SPI_CPHA | SPI_LSBF; // set spi as
a master
SPI_SPCCR = SPI_DIVIDER; // set divider

Sending a byte (send a command, ignore the returned byte) looks like:

void spiSendByte(unsigned char c)
{
SPI_SPDR = c;
while (!(SPI_SPSR & SPI_SPIF))
;
}

Transferring a byte (send a byte, return to caller the returned byte)
looks like:

unsigned char spiTransferByte(unsigned char c)
{
SPI_SPDR = c;
while (!(SPI_SPSR & SPI_SPIF))
;
return SPI_SPDR;
}

The main code which simply reads the game controller and prints the
results looks like:

int
main(void)
{
unsigned char i, reply[8];

Initialize();

while (1)
{
IOCLR = PS_SELECT; // set slave select bit low

delay(SPI_DELAY); // give the device a chance to react
spiSendByte(0x01); // send start command

delay(SPI_DELAY);
reply[0] = spiTransferByte(0x42); // send ID, device should send 0x41
or 0x73

for (i = 1; i < (reply[0] == 0x73 ? 8 : 4); i++)
{
delay(SPI_DELAY);
reply[i] = spiTransferByte(0xFF);
}
IOSET = PS_SELECT; // set slave select high

for (i = 0; i < (reply[0] == 0x73? 8 : 4); i++)
{
puthex(reply[i]);
putch(' ');
}

putCRLF();
}
return 0;
}

For my project, I used P0.15 as the device select output to the game
controller (PS_SELECT). I pulled P0.7 (SSEL0) high and did not use it
for any other function.

Richard

Hi

Could you see if, at least the clock and data are
comming out from ARM to the other device ?
Maybe the problem isnt with micro controller code.
Try to put a test loop on firmware to see if the cpu
sends the signals correctly.

Regards

--- shwouchk escreveu:

> Thanks for the response!
>
> Unfortunately, although might be a bit unclear from
> the parts I
> pasted, I do not use the SSEL pin in SPI mode, but
> rather in GPIO
> mode, so I don't think that this is the cause of my
> problems...
> (morever, after I couldn't get it to work I decided
> to move it from
> 0.7 entirely... now it's on 0.2)
>
> Any other ideas?
>
> Thanks in advance,
> Kosta.
> --- In l..., Alexandre Kremer
> wrote:
> >
> > This is a common mistake people do with LPC�s
> spi
> > interface.
> > I think your problem is that you are taking the
> SSEL
> > pin as a Chip Select for other devices. Well, this
> pin
> > isn�t a chip select, but a SLAVE SELECT.
> > The SLAVE SELECT functionality serves to turn the
> > ARM�s SPI from MASTER MODE to SLAVE MODE, so
> another
> > device on the bus can take it as a Master by
> putting a
> > low level on this ARM�s pin. It doesn�t select
> > external devices as slave, but it makes the micro
> > controller act as a slave.
> > Try to put a 10K pull up on this pin and
> disconnect
> > it from any other device.
> > Also it is an INPUT ONLY, so things like IOSET0 > > SPI_SSEL; or IOCLR0 = SPI_SSEL; won�t produce
> any
> > effect when SSEL pin is configured with SPI
> > functionality.
> > So, i suggest you to use another GPIO as a chip
> > select for your micromag device.
> >
> > Regards
> >
> >
> > --- shwouchk escreveu:
> >
> > > Hi!
> > >
> > > Ive been working at it for at least a week and I
> > > can't find the reason
> > > why I can't get SPI to work - I haven't looked
> with
> > > a scope, but I'm
> > > pretty sure that the the device doesn't even
> send
> > > out a clock...
> > > otherwise it seems to work fine, which is why
> I'm
> > > stumped.. This is
> > > most of the code which runs the SPI - can anyone
> > > spot anything obvious?
> > >
> > > P.S.
> > > I'm using a device which uses a modified version
> of
> > > SPI - it also
> > > needs a reset pin.
> > > The code hangs in the while loop which wait for
> > > SPIF...
> > >
> > > The following two functions are called one after
> the
> > > other:
> > >
> ===================================================> > >
> > > struct MicroMag_Command; // size uint8_t
> > >
> > > void vSPI_MicroMag_Init(void)
> > > {
> > > PINSEL0 |= SPI0_PINS; // Configure SPI0 pins.
> > > IODIR0 |= SPI_EXTRA_PINS; // SSEL and RESET
> which
> > > are GPIO controlled.
> > > IOSET0 = SPI_SSEL; // Deselect the MicroMag.
> > > (Active low)
> > > IOCLR0 = SPI_RESET; // Set the reset pin low.
> > >
> > > // It is usually set at 60 (while the pll runs
> at
> > > ~59mhz)
> > > S0SPCCR = 100; // Configure The SPI clock
> divider.
> > >
> > > // Configure and set the default transfer
> > > attributes:
> > > S0SPCR_bit.BITENABLE = 0; // 8 bits.
> > > S0SPCR_bit.CPHA = 0;
> > > S0SPCR_bit.CPOL = 0;
> > > S0SPCR_bit.MSTR = 1; // Master.
> > > S0SPCR_bit.LSBF = 0; // MSB First.
> > > S0SPCR_bit.SPIE = 0; // No SPI Interrupts.
> > > S0SPCR_bit.BITS = 0; // 16 bits if BITENABLE > > > true;
> > > }
> > >
> > >
> > > void vSPI_MicroMag_SendMeasureCommand(void)
> > > {
> > > IOCLR0 = SPI_RESET; // Set RESET low.
> > > IOCLR0 = SPI_SSEL; // Select the MicroMag.
> > >
> > > S0SPCR_bit.BITENABLE = 0; // 8 bits.
> > >
> > > IOPIN0 ^= SPI_RESET; // Toggle RESET high.
> > > WAIT(10);
> > > IOPIN0 ^= SPI_RESET; // Toggle RESET low.
> > > WAIT(10);
> > >
> > > SSPDR = *((uint8_t *) (&SPI_MicroMag_MMC)); //
> Send
> > > the command.
> > >
> > >
> > > // This is where it gets stuck:
> > > while (S0SPSR_bit.SPIF == 0); // Wait until the
> > > transfer completes.
> > >
> > > IOSET0 = SPI_SSEL; // Deselect the MicroMag.
> > > }
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > Alertas do Yahoo! Mail em seu celular. Saiba
> mais em
> http://br.mobile.yahoo.com/mailalertas/
> >
>
> Yahoo! Groups Links
>

Flickr agora em portugu. Vocclica, todo mundo v
http://www.flickr.com.br/

Thanks for the response!

Unfortunately, although might be a bit unclear from the parts I
pasted, I do not use the SSEL pin in SPI mode, but rather in GPIO
mode, so I don't think that this is the cause of my problems...
(morever, after I couldn't get it to work I decided to move it from
0.7 entirely... now it's on 0.2)

Any other ideas?

Thanks in advance,
Kosta.
--- In l..., Alexandre Kremer wrote:
>
> This is a common mistake people do with LPC�s spi
> interface.
> I think your problem is that you are taking the SSEL
> pin as a Chip Select for other devices. Well, this pin
> isn�t a chip select, but a SLAVE SELECT.
> The SLAVE SELECT functionality serves to turn the
> ARM�s SPI from MASTER MODE to SLAVE MODE, so another
> device on the bus can take it as a Master by putting a
> low level on this ARM�s pin. It doesn�t select
> external devices as slave, but it makes the micro
> controller act as a slave.
> Try to put a 10K pull up on this pin and disconnect
> it from any other device.
> Also it is an INPUT ONLY, so things like IOSET0 > SPI_SSEL; or IOCLR0 = SPI_SSEL; won�t produce any
> effect when SSEL pin is configured with SPI
> functionality.
> So, i suggest you to use another GPIO as a chip
> select for your micromag device.
>
> Regards
> --- shwouchk escreveu:
>
> > Hi!
> >
> > Ive been working at it for at least a week and I
> > can't find the reason
> > why I can't get SPI to work - I haven't looked with
> > a scope, but I'm
> > pretty sure that the the device doesn't even send
> > out a clock...
> > otherwise it seems to work fine, which is why I'm
> > stumped.. This is
> > most of the code which runs the SPI - can anyone
> > spot anything obvious?
> >
> > P.S.
> > I'm using a device which uses a modified version of
> > SPI - it also
> > needs a reset pin.
> > The code hangs in the while loop which wait for
> > SPIF...
> >
> > The following two functions are called one after the
> > other:
> > ===================================================> >
> > struct MicroMag_Command; // size uint8_t
> >
> > void vSPI_MicroMag_Init(void)
> > {
> > PINSEL0 |= SPI0_PINS; // Configure SPI0 pins.
> > IODIR0 |= SPI_EXTRA_PINS; // SSEL and RESET which
> > are GPIO controlled.
> > IOSET0 = SPI_SSEL; // Deselect the MicroMag.
> > (Active low)
> > IOCLR0 = SPI_RESET; // Set the reset pin low.
> >
> > // It is usually set at 60 (while the pll runs at
> > ~59mhz)
> > S0SPCCR = 100; // Configure The SPI clock divider.
> >
> > // Configure and set the default transfer
> > attributes:
> > S0SPCR_bit.BITENABLE = 0; // 8 bits.
> > S0SPCR_bit.CPHA = 0;
> > S0SPCR_bit.CPOL = 0;
> > S0SPCR_bit.MSTR = 1; // Master.
> > S0SPCR_bit.LSBF = 0; // MSB First.
> > S0SPCR_bit.SPIE = 0; // No SPI Interrupts.
> > S0SPCR_bit.BITS = 0; // 16 bits if BITENABLE > > true;
> > }
> >
> >
> > void vSPI_MicroMag_SendMeasureCommand(void)
> > {
> > IOCLR0 = SPI_RESET; // Set RESET low.
> > IOCLR0 = SPI_SSEL; // Select the MicroMag.
> >
> > S0SPCR_bit.BITENABLE = 0; // 8 bits.
> >
> > IOPIN0 ^= SPI_RESET; // Toggle RESET high.
> > WAIT(10);
> > IOPIN0 ^= SPI_RESET; // Toggle RESET low.
> > WAIT(10);
> >
> > SSPDR = *((uint8_t *) (&SPI_MicroMag_MMC)); // Send
> > the command.
> >
> >
> > // This is where it gets stuck:
> > while (S0SPSR_bit.SPIF == 0); // Wait until the
> > transfer completes.
> >
> > IOSET0 = SPI_SSEL; // Deselect the MicroMag.
> > }
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> > Alertas do Yahoo! Mail em seu celular. Saiba mais em
http://br.mobile.yahoo.com/mailalertas/
>

This is a common mistake people do with LPCs spi
interface.
I think your problem is that you are taking the SSEL
pin as a Chip Select for other devices. Well, this pin
isnt a chip select, but a SLAVE SELECT.
The SLAVE SELECT functionality serves to turn the
ARMs SPI from MASTER MODE to SLAVE MODE, so another
device on the bus can take it as a Master by putting a
low level on this ARMs pin. It doesnt select
external devices as slave, but it makes the micro
controller act as a slave.
Try to put a 10K pull up on this pin and disconnect
it from any other device.
Also it is an INPUT ONLY, so things like IOSET0 SPI_SSEL; or IOCLR0 = SPI_SSEL; wont produce any
effect when SSEL pin is configured with SPI
functionality.
So, i suggest you to use another GPIO as a chip
select for your micromag device.

Regards
--- shwouchk escreveu:

> Hi!
>
> Ive been working at it for at least a week and I
> can't find the reason
> why I can't get SPI to work - I haven't looked with
> a scope, but I'm
> pretty sure that the the device doesn't even send
> out a clock...
> otherwise it seems to work fine, which is why I'm
> stumped.. This is
> most of the code which runs the SPI - can anyone
> spot anything obvious?
>
> P.S.
> I'm using a device which uses a modified version of
> SPI - it also
> needs a reset pin.
> The code hangs in the while loop which wait for
> SPIF...
>
> The following two functions are called one after the
> other:
> ===================================================>
> struct MicroMag_Command; // size uint8_t
>
> void vSPI_MicroMag_Init(void)
> {
> PINSEL0 |= SPI0_PINS; // Configure SPI0 pins.
> IODIR0 |= SPI_EXTRA_PINS; // SSEL and RESET which
> are GPIO controlled.
> IOSET0 = SPI_SSEL; // Deselect the MicroMag.
> (Active low)
> IOCLR0 = SPI_RESET; // Set the reset pin low.
>
> // It is usually set at 60 (while the pll runs at
> ~59mhz)
> S0SPCCR = 100; // Configure The SPI clock divider.
>
> // Configure and set the default transfer
> attributes:
> S0SPCR_bit.BITENABLE = 0; // 8 bits.
> S0SPCR_bit.CPHA = 0;
> S0SPCR_bit.CPOL = 0;
> S0SPCR_bit.MSTR = 1; // Master.
> S0SPCR_bit.LSBF = 0; // MSB First.
> S0SPCR_bit.SPIE = 0; // No SPI Interrupts.
> S0SPCR_bit.BITS = 0; // 16 bits if BITENABLE > true;
> }
> void vSPI_MicroMag_SendMeasureCommand(void)
> {
> IOCLR0 = SPI_RESET; // Set RESET low.
> IOCLR0 = SPI_SSEL; // Select the MicroMag.
>
> S0SPCR_bit.BITENABLE = 0; // 8 bits.
>
> IOPIN0 ^= SPI_RESET; // Toggle RESET high.
> WAIT(10);
> IOPIN0 ^= SPI_RESET; // Toggle RESET low.
> WAIT(10);
>
> SSPDR = *((uint8_t *) (&SPI_MicroMag_MMC)); // Send
> the command.
> // This is where it gets stuck:
> while (S0SPSR_bit.SPIF == 0); // Wait until the
> transfer completes.
>
> IOSET0 = SPI_SSEL; // Deselect the MicroMag.
> }
>
>
> Yahoo! Groups Links
>

Alertas do Yahoo! Mail em seu celular. Saiba mais em http://br.mobile.yahoo.com/mailalertas/

Hi!

Ive been working at it for at least a week and I can't find the reason
why I can't get SPI to work - I haven't looked with a scope, but I'm
pretty sure that the the device doesn't even send out a clock...
otherwise it seems to work fine, which is why I'm stumped.. This is
most of the code which runs the SPI - can anyone spot anything obvious?

P.S.
I'm using a device which uses a modified version of SPI - it also
needs a reset pin.
The code hangs in the while loop which wait for SPIF...

The following two functions are called one after the other:
===================================================
struct MicroMag_Command; // size uint8_t

void vSPI_MicroMag_Init(void)
{
PINSEL0 |= SPI0_PINS; // Configure SPI0 pins.
IODIR0 |= SPI_EXTRA_PINS; // SSEL and RESET which are GPIO controlled.
IOSET0 = SPI_SSEL; // Deselect the MicroMag. (Active low)
IOCLR0 = SPI_RESET; // Set the reset pin low.

// It is usually set at 60 (while the pll runs at ~59mhz)
S0SPCCR = 100; // Configure The SPI clock divider.

// Configure and set the default transfer attributes:
S0SPCR_bit.BITENABLE = 0; // 8 bits.
S0SPCR_bit.CPHA = 0;
S0SPCR_bit.CPOL = 0;
S0SPCR_bit.MSTR = 1; // Master.
S0SPCR_bit.LSBF = 0; // MSB First.
S0SPCR_bit.SPIE = 0; // No SPI Interrupts.
S0SPCR_bit.BITS = 0; // 16 bits if BITENABLE = true;
}
void vSPI_MicroMag_SendMeasureCommand(void)
{
IOCLR0 = SPI_RESET; // Set RESET low.
IOCLR0 = SPI_SSEL; // Select the MicroMag.

S0SPCR_bit.BITENABLE = 0; // 8 bits.

IOPIN0 ^= SPI_RESET; // Toggle RESET high.
WAIT(10);
IOPIN0 ^= SPI_RESET; // Toggle RESET low.
WAIT(10);

SSPDR = *((uint8_t *) (&SPI_MicroMag_MMC)); // Send the command.
// This is where it gets stuck:
while (S0SPSR_bit.SPIF == 0); // Wait until the transfer completes.

IOSET0 = SPI_SSEL; // Deselect the MicroMag.
}