2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

I wonder if anyone can help me with the problem we are having with
interfacing a peripheral to LPC2119...

The issue is that a peripheral (MicroMag 3 from PNI Corp) expects 8
bit command and after measurement transmits 16 bit of data back to
master.

We have set up LPC2119 in SPI1 master mode, transmit 8 bit command to
Micromag 3 and read S1SPDR twice after peripheral signals the end of
measurement, however results we're getting are pretty much garbage...

I wonder if anyone has tried receiving multi-byte results from SPI
peripherals and if there are any quirks there...

With kind regards,

Igor Rafalovsky
R3 Scientific Corp



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "irafalovsky" wrote:
>
> I wonder if anyone can help me with the problem we are having with
> interfacing a peripheral to LPC2119...
>
> The issue is that a peripheral (MicroMag 3 from PNI Corp) expects 8
> bit command and after measurement transmits 16 bit of data back to
> master.
>
> We have set up LPC2119 in SPI1 master mode, transmit 8 bit command to
> Micromag 3 and read S1SPDR twice after peripheral signals the end of
> measurement, however results we're getting are pretty much garbage...
>
> I wonder if anyone has tried receiving multi-byte results from SPI
> peripherals and if there are any quirks there...
>
> With kind regards,
>
> Igor Rafalovsky
> R3 Scientific Corp
>

Do you send 2 bytes out from LPC2119 to allow the SPI clock to go so
you can get back the 2 bytes that you are expecting?

We have an application with LPC2138 running in slave mode and
receiving packets of 9 bits characters from an host processor and
responding with packets of 9 bits characters.
Naturally, in order to be able to send back the answer the LPC must
receive the spi clock from the master so the host processor must pump
out dummy characters to allow the answer to come back.

Regards,

Carlo Barbaro



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

If we attempt to send 2 bytes after peripheral indicates available
data, we simply get zeroes in return...

Here's what code looks like:

IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
delay(10);
IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
delay(10);
S1SPDR = 0x41; // Send Measure X command
while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
S1SPDR = 0;
S1SPDR = 0;
MM3_HB = S1SPDR;
MM3_LB = S1SPDR;
wMM3_X = MM3_HB;
wMM3_X = (wMM3_X << 8) | MM3_LB;
>
> Do you send 2 bytes out from LPC2119 to allow the SPI clock to go so
> you can get back the 2 bytes that you are expecting?
>
> We have an application with LPC2138 running in slave mode and
> receiving packets of 9 bits characters from an host processor and
> responding with packets of 9 bits characters.
> Naturally, in order to be able to send back the answer the LPC must
> receive the spi clock from the master so the host processor must pump
> out dummy characters to allow the answer to come back.
>
> Regards,
>
> Carlo Barbaro
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

> If we attempt to send 2 bytes after peripheral indicates
> available data, we simply get zeroes in return...
>
> Here's what code looks like:
>
> IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> delay(10);
> IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> delay(10);
> S1SPDR = 0x41; // Send Measure X command
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> S1SPDR = 0;
> S1SPDR = 0;
> MM3_HB = S1SPDR;
> MM3_LB = S1SPDR;
> wMM3_X = MM3_HB;
> wMM3_X = (wMM3_X << 8) | MM3_LB;

Oh my god. Read the data sheet, please, read the data sheet. Don't
bother until you've read the data sheet. The error is obvious here.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I apologize if you got offended somehow, but we did read the
datasheet and the manual very carefully. Needless to say, there is
no useful information on the topic in both documents and this is the
reason I asked the question here...

If the error is obvious, could you please kindly point me to it?

With best regards,

Igor.

>
> Hi,
>
> > If we attempt to send 2 bytes after peripheral indicates
> > available data, we simply get zeroes in return...
> >
> > Here's what code looks like:
> >
> > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> > delay(10);
> > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > delay(10);
> > S1SPDR = 0x41; // Send Measure X command
> > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > S1SPDR = 0;
> > S1SPDR = 0;
> > MM3_HB = S1SPDR;
> > MM3_LB = S1SPDR;
> > wMM3_X = MM3_HB;
> > wMM3_X = (wMM3_X << 8) | MM3_LB;
>
> Oh my god. Read the data sheet, please, read the data sheet.
Don't
> bother until you've read the data sheet. The error is obvious
here.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Shouldn't these be interlaced:

> > S1SPDR = 0;
> > S1SPDR = 0;
> > MM3_HB = S1SPDR;
> > MM3_LB = S1SPDR;

Should be:

> > S1SPDR = 0;
> > MM3_HB = S1SPDR;
> > S1SPDR = 0;
> > MM3_LB = S1SPDR;

Otherwise, you wipe out the first value in S1SPDR before you
read it.

MX
-----Original Message-----
From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On Behalf Of irafalovsky
Sent: Tuesday, August 08, 2006 2:37 PM
To: l...@yahoogroups.com
Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
I apologize if you got offended somehow, but we did read the
datasheet and the manual very carefully. Needless to say, there is
no useful information on the topic in both documents and this is the
reason I asked the question here...

If the error is obvious, could you please kindly point me to it?

With best regards,

Igor.

>
> Hi,
>
> > If we attempt to send 2 bytes after peripheral indicates
> > available data, we simply get zeroes in return...
> >
> > Here's what code looks like:
> >
> > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> > delay(10);
> > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > delay(10);
> > S1SPDR = 0x41; // Send Measure X command
> > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > S1SPDR = 0;
> > S1SPDR = 0;
> > MM3_HB = S1SPDR;
> > MM3_LB = S1SPDR;
> > wMM3_X = MM3_HB;
> > wMM3_X = (wMM3_X << 8) | MM3_LB;
>
> Oh my god. Read the data sheet, please, read the data sheet.
Don't
> bother until you've read the data sheet. The error is obvious
here.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

We first attempted reading two bytes in succession without any
additional writes, which is how Philips demonstrates it in one of
their Application Notes.

That attempt produces really erratic results, after which we
attempted what you suggested second and are getting zero values for
both reads.

The example code showed implementation of a suggestion made by
c.barbaro in an earlier post (regarding sending two bytes to keep
SCLK moving). This code also produces zero values.

>
> Shouldn't these be interlaced:
>
> > > S1SPDR = 0;
> > > S1SPDR = 0;
> > > MM3_HB = S1SPDR;
> > > MM3_LB = S1SPDR;
>
> Should be:
>
> > > S1SPDR = 0;
> > > MM3_HB = S1SPDR;
> > > S1SPDR = 0;
> > > MM3_LB = S1SPDR;
>
> Otherwise, you wipe out the first value in S1SPDR before you
> read it.
>
> MX
> -----Original Message-----
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On
Behalf Of irafalovsky
> Sent: Tuesday, August 08, 2006 2:37 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
> I apologize if you got offended somehow, but we did read the
> datasheet and the manual very carefully. Needless to say, there is
> no useful information on the topic in both documents and this is
the
> reason I asked the question here...
>
> If the error is obvious, could you please kindly point me to it?
>
> With best regards,
>
> Igor.
>
> >
> > Hi,
> >
> > > If we attempt to send 2 bytes after peripheral indicates
> > > available data, we simply get zeroes in return...
> > >
> > > Here's what code looks like:
> > >
> > > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> > > delay(10);
> > > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > > delay(10);
> > > S1SPDR = 0x41; // Send Measure X command
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > > S1SPDR = 0;
> > > S1SPDR = 0;
> > > MM3_HB = S1SPDR;
> > > MM3_LB = S1SPDR;
> > > wMM3_X = MM3_HB;
> > > wMM3_X = (wMM3_X << 8) | MM3_LB;
> >
> > Oh my god. Read the data sheet, please, read the data sheet.
> Don't
> > bother until you've read the data sheet. The error is obvious
> here.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3
processors
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Also, I don't see it doing a chip select, unless it's
outside the range of code you show.

MX

-----Original Message-----
From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On Behalf Of irafalovsky
Sent: Tuesday, August 08, 2006 2:52 PM
To: l...@yahoogroups.com
Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
We first attempted reading two bytes in succession without any
additional writes, which is how Philips demonstrates it in one of
their Application Notes.

That attempt produces really erratic results, after which we
attempted what you suggested second and are getting zero values for
both reads.

The example code showed implementation of a suggestion made by
c.barbaro in an earlier post (regarding sending two bytes to keep
SCLK moving). This code also produces zero values.

>
> Shouldn't these be interlaced:
>
> > > S1SPDR = 0;
> > > S1SPDR = 0;
> > > MM3_HB = S1SPDR;
> > > MM3_LB = S1SPDR;
>
> Should be:
>
> > > S1SPDR = 0;
> > > MM3_HB = S1SPDR;
> > > S1SPDR = 0;
> > > MM3_LB = S1SPDR;
>
> Otherwise, you wipe out the first value in S1SPDR before you
> read it.
>
> MX
> -----Original Message-----
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On
Behalf Of irafalovsky
> Sent: Tuesday, August 08, 2006 2:37 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
> I apologize if you got offended somehow, but we did read the
> datasheet and the manual very carefully. Needless to say, there is
> no useful information on the topic in both documents and this is
the
> reason I asked the question here...
>
> If the error is obvious, could you please kindly point me to it?
>
> With best regards,
>
> Igor.
>
> >
> > Hi,
> >
> > > If we attempt to send 2 bytes after peripheral indicates
> > > available data, we simply get zeroes in return...
> > >
> > > Here's what code looks like:
> > >
> > > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> > > delay(10);
> > > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > > delay(10);
> > > S1SPDR = 0x41; // Send Measure X command
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > > S1SPDR = 0;
> > > S1SPDR = 0;
> > > MM3_HB = S1SPDR;
> > > MM3_LB = S1SPDR;
> > > wMM3_X = MM3_HB;
> > > wMM3_X = (wMM3_X << 8) | MM3_LB;
> >
> > Oh my god. Read the data sheet, please, read the data sheet.
> Don't
> > bother until you've read the data sheet. The error is obvious
> here.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3
processors
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Woolsey Matt"
wrote:
>
> Also, I don't see it doing a chip select, unless it's
> outside the range of code you show.
>
> MX

Yes, it is outside, I didn't want to bother audience with the code
that works... :-)



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

How about waiting for some data to come back for a start?

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

> -----Original Message-----
> From: irafalovsky [mailto:r...@ivr.org]
> Sent: 08 August 2006 22:37
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
>
> I apologize if you got offended somehow, but we did read the
> datasheet and the manual very carefully. Needless to say,
> there is no useful information on the topic in both documents
> and this is the reason I asked the question here...
>
> If the error is obvious, could you please kindly point me to it?
>
> With best regards,
>
> Igor.
>
> >
> > Hi,
> >
> > > If we attempt to send 2 bytes after peripheral indicates
> available
> > > data, we simply get zeroes in return...
> > >
> > > Here's what code looks like:
> > >
> > > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> > > delay(10);
> > > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > > delay(10);
> > > S1SPDR = 0x41; // Send Measure X command
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > > S1SPDR = 0;
> > > S1SPDR = 0;
> > > MM3_HB = S1SPDR;
> > > MM3_LB = S1SPDR;
> > > wMM3_X = MM3_HB;
> > > wMM3_X = (wMM3_X << 8) | MM3_LB;
> >
> > Oh my god. Read the data sheet, please, read the data sheet.
> Don't
> > bother until you've read the data sheet. The error is obvious
> here.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> >
>
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Shouldn't you also check the status register for
completion after _every_ write to the data register?

MX

-----Original Message-----
From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On Behalf Of irafalovsky
Sent: Tuesday, August 08, 2006 3:04 PM
To: l...@yahoogroups.com
Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
--- In l...@yahoogroups.com, "Woolsey Matt"
wrote:
>
> Also, I don't see it doing a chip select, unless it's
> outside the range of code you show.
>
> MX

Yes, it is outside, I didn't want to bother audience with the code
that works... :-)



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

We have tried that too, no difference...

--- In l...@yahoogroups.com, "Woolsey Matt"
wrote:
>
> Shouldn't you also check the status register for
> completion after _every_ write to the data register?
>
> MX
>
> -----Original Message-----
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On
Behalf Of irafalovsky
> Sent: Tuesday, August 08, 2006 3:04 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
> --- In l...@yahoogroups.com, "Woolsey Matt"
> wrote:
> >
> > Also, I don't see it doing a chip select, unless it's
> > outside the range of code you show.
> >
> > MX
>
> Yes, it is outside, I didn't want to bother audience with the code
> that works... :-)
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

We have tried sending dummy write after first read as well, with or
without clearing S1SPSR with no luck...

--- In l...@yahoogroups.com, "Paul Curtis" wrote:
>
> How about waiting for some data to come back for a start?
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Should you reset the MM3 prior to selecting the chip? Seems like doing the reset
while it is selected will take it out of the SPI transfer mode.

-----Original Message-----
From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On Behalf Of irafalovsky
Sent: Tuesday, August 08, 2006 3:04 PM
To: l...@yahoogroups.com
Subject: [lpc2000] Re: Problem with SPI1 on LPC2119

--- In lpc2000@yahoogroups .com, "Woolsey Matt"
wrote:
>
> Also, I don't see it doing a chip select, unless it's
> outside the range of code you show.
>
> MX

Yes, it is outside, I didn't want to bother audience with the code
that works... :-)

[Non-text portions of this message have been removed]



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I think we made the code in exact accordance to their SPI timing
sequence (Page 7 of MM3 datasheet), at least what we see on the
oscilloscope resembles what they say...

Our problem seems to be with reading 16 bits of data on MOSI, or
more precisely, with our way of working with S1SPDR...

--- In l...@yahoogroups.com, "Woolsey Matt"
wrote:
>
> Should you reset the MM3 prior to selecting the chip? Seems like
doing the reset
> while it is selected will take it out of the SPI transfer mode.
>
>
> -----Original Message-----
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On
Behalf Of irafalovsky
> Sent: Tuesday, August 08, 2006 3:04 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
>
> --- In lpc2000@yahoogroups 40yahoogroups.com> .com, "Woolsey Matt"
> wrote:
> >
> > Also, I don't see it doing a chip select, unless it's
> > outside the range of code you show.
> >
> > MX
>
> Yes, it is outside, I didn't want to bother audience with the code
> that works... :-)
>
>
>
> [Non-text portions of this message have been removed]
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Tried that too, with pretty much the same outcome.

I believe we are doing everything right in terms of commanding the
peripheral to make the measurement, however we are making some sort
of mistake in the way we are attempting to read two bytes from
S1SPDR, but I have no idea what that mistake is...

--- In l...@yahoogroups.com, "Woolsey Matt"
wrote:
>
> Shouldn't you also check the status register for
> completion after _every_ write to the data register?
>
> MX
>
> -----Original Message-----
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On
Behalf Of irafalovsky
> Sent: Tuesday, August 08, 2006 3:04 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
> --- In l...@yahoogroups.com, "Woolsey Matt"
> wrote:
> >
> > Also, I don't see it doing a chip select, unless it's
> > outside the range of code you show.
> >
> > MX
>
> Yes, it is outside, I didn't want to bother audience with the code
> that works... :-)
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Make it MISO, not MOSI...

--- In l...@yahoogroups.com, "irafalovsky" wrote:
>
> I think we made the code in exact accordance to their SPI timing
> sequence (Page 7 of MM3 datasheet), at least what we see on the
> oscilloscope resembles what they say...
>
> Our problem seems to be with reading 16 bits of data on MOSI, or
> more precisely, with our way of working with S1SPDR...
>
> --- In l...@yahoogroups.com, "Woolsey Matt"
> wrote:
> >
> > Should you reset the MM3 prior to selecting the chip? Seems
like
> doing the reset
> > while it is selected will take it out of the SPI transfer mode.
> >
> >
> > -----Original Message-----
> > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com]On
> Behalf Of irafalovsky
> > Sent: Tuesday, August 08, 2006 3:04 PM
> > To: l...@yahoogroups.com
> > Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
> >
> >
> >
> > --- In lpc2000@yahoogroups > 40yahoogroups.com> .com, "Woolsey Matt"
> > wrote:
> > >
> > > Also, I don't see it doing a chip select, unless it's
> > > outside the range of code you show.
> > >
> > > MX
> >
> > Yes, it is outside, I didn't want to bother audience with the
code
> > that works... :-)
> >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

To clear the SPIF bit in S1SPSR you have to access the S1SPSR then
access the S1SPDR (ie read or write to it). You also have to shift
out a byte to receive one, and wait for the SPI status to indicate
SPIF before the received byte can be read.

I use interrupts, so I can't speak to how well polling the SPI status
register works. This code is also ignoring any errors that the SPI
may be setting as well.

Try something along these lines:

S1SPDR = 0x41; // Send Measure X command
while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
temp = S1SPDR; // Clears SPIF in S1SPSR.

while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready

S1SPDR = 0;.
while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
MM3_HB = S1SPDR; // Clears SPIF in S1SPSR.

S1SPDR = 0;
while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
MM3_LB = S1SPDR; // Clears SPIF in S1SPSR.

wMM3_X = MM3_HB;
wMM3_X = (wMM3_X << 8) | MM3_LB;

--- In l...@yahoogroups.com, "irafalovsky" wrote:
>
> If we attempt to send 2 bytes after peripheral indicates available
> data, we simply get zeroes in return...
>
> Here's what code looks like:
>
> IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> delay(10);
> IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> delay(10);
> S1SPDR = 0x41; // Send Measure X command
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> S1SPDR = 0;
> S1SPDR = 0;
> MM3_HB = S1SPDR;
> MM3_LB = S1SPDR;
> wMM3_X = MM3_HB;
> wMM3_X = (wMM3_X << 8) | MM3_LB;
> >
> > Do you send 2 bytes out from LPC2119 to allow the SPI clock to go so
> > you can get back the 2 bytes that you are expecting?
> >
> > We have an application with LPC2138 running in slave mode and
> > receiving packets of 9 bits characters from an host processor and
> > responding with packets of 9 bits characters.
> > Naturally, in order to be able to send back the answer the LPC must
> > receive the spi clock from the master so the host processor must pump
> > out dummy characters to allow the answer to come back.
> >
> > Regards,
> >
> > Carlo Barbaro
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Thank you for your help! Unfortunately, this approach does not work
either...

Now, the question is -- is it at all possible to make LPC2119 read
16 bits sent by SPI peripheral in succession?

--- In l...@yahoogroups.com, "Alan Strickland"
wrote:
>
> To clear the SPIF bit in S1SPSR you have to access the S1SPSR then
> access the S1SPDR (ie read or write to it). You also have to shift
> out a byte to receive one, and wait for the SPI status to indicate
> SPIF before the received byte can be read.
>
> I use interrupts, so I can't speak to how well polling the SPI
status
> register works. This code is also ignoring any errors that the SPI
> may be setting as well.
>
> Try something along these lines:
>
> S1SPDR = 0x41; // Send Measure X command
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> temp = S1SPDR; // Clears SPIF in S1SPSR.
>
> while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
>
> S1SPDR = 0;.
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> MM3_HB = S1SPDR; // Clears SPIF in S1SPSR.
>
> S1SPDR = 0;
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> MM3_LB = S1SPDR; // Clears SPIF in S1SPSR.
>
> wMM3_X = MM3_HB;
> wMM3_X = (wMM3_X << 8) | MM3_LB;
>
> --- In l...@yahoogroups.com, "irafalovsky" wrote:
> >
> > If we attempt to send 2 bytes after peripheral indicates
available
> > data, we simply get zeroes in return...
> >
> > Here's what code looks like:
> >
> > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> > delay(10);
> > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > delay(10);
> > S1SPDR = 0x41; // Send Measure X command
> > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > S1SPDR = 0;
> > S1SPDR = 0;
> > MM3_HB = S1SPDR;
> > MM3_LB = S1SPDR;
> > wMM3_X = MM3_HB;
> > wMM3_X = (wMM3_X << 8) | MM3_LB;
> >
> >
> > >
> > > Do you send 2 bytes out from LPC2119 to allow the SPI clock to
go so
> > > you can get back the 2 bytes that you are expecting?
> > >
> > > We have an application with LPC2138 running in slave mode and
> > > receiving packets of 9 bits characters from an host processor
and
> > > responding with packets of 9 bits characters.
> > > Naturally, in order to be able to send back the answer the LPC
must
> > > receive the spi clock from the master so the host processor
must pump
> > > out dummy characters to allow the answer to come back.
> > >
> > > Regards,
> > >
> > > Carlo Barbaro
> > >
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I was never able to get the SPI engine to send 16 bits. I ended up writing my own code to do it by GPIO.
I don't believe the LPC SPI engines can do anything but 8 bit data word size.

Chris.
----- Original Message -----
From: irafalovsky
To: l...@yahoogroups.com
Sent: Tuesday, August 08, 2006 9:00 PM
Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
Thank you for your help! Unfortunately, this approach does not work
either...

Now, the question is -- is it at all possible to make LPC2119 read
16 bits sent by SPI peripheral in succession?

--- In l...@yahoogroups.com, "Alan Strickland"
wrote:
>
> To clear the SPIF bit in S1SPSR you have to access the S1SPSR then
> access the S1SPDR (ie read or write to it). You also have to shift
> out a byte to receive one, and wait for the SPI status to indicate
> SPIF before the received byte can be read.
>
> I use interrupts, so I can't speak to how well polling the SPI
status
> register works. This code is also ignoring any errors that the SPI
> may be setting as well.
>
> Try something along these lines:
>
> S1SPDR = 0x41; // Send Measure X command
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> temp = S1SPDR; // Clears SPIF in S1SPSR.
>
> while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
>
> S1SPDR = 0;.
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> MM3_HB = S1SPDR; // Clears SPIF in S1SPSR.
>
> S1SPDR = 0;
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> MM3_LB = S1SPDR; // Clears SPIF in S1SPSR.
>
> wMM3_X = MM3_HB;
> wMM3_X = (wMM3_X << 8) | MM3_LB;
>
> --- In l...@yahoogroups.com, "irafalovsky" wrote:
> >
> > If we attempt to send 2 bytes after peripheral indicates
available
> > data, we simply get zeroes in return...
> >
> > Here's what code looks like:
> >
> > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> > delay(10);
> > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > delay(10);
> > S1SPDR = 0x41; // Send Measure X command
> > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > S1SPDR = 0;
> > S1SPDR = 0;
> > MM3_HB = S1SPDR;
> > MM3_LB = S1SPDR;
> > wMM3_X = MM3_HB;
> > wMM3_X = (wMM3_X << 8) | MM3_LB;
> >
> >
> > >
> > > Do you send 2 bytes out from LPC2119 to allow the SPI clock to
go so
> > > you can get back the 2 bytes that you are expecting?
> > >
> > > We have an application with LPC2138 running in slave mode and
> > > receiving packets of 9 bits characters from an host processor
and
> > > responding with packets of 9 bits characters.
> > > Naturally, in order to be able to send back the answer the LPC
must
> > > receive the spi clock from the master so the host processor
must pump
> > > out dummy characters to allow the answer to come back.
> > >
> > > Regards,
> > >
> > > Carlo Barbaro
> > >
> >
>

[Non-text portions of this message have been removed]



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, wrote:
>
> I was never able to get the SPI engine to send 16 bits. I ended up
writing my own code to do it by GPIO.
> I don't believe the LPC SPI engines can do anything but 8 bit data
word size.
>
> Chris.
>

I never tried working with 16 bit frames, only 9 bits.
Anyway Mr Irafalovsky is working with 8 bit frames and is sending
2x8bit frames in order to read the 16 bit result.
Pheraps here is the problem: the SSEL1 signal goes high between the
two 8 bit frames; are you sure this are not causing problems to your
slave device?

>
> ----- Original Message -----
> From: irafalovsky
> To: l...@yahoogroups.com
> Sent: Tuesday, August 08, 2006 9:00 PM
> Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
> Thank you for your help! Unfortunately, this approach does not work
> either...
>
> Now, the question is -- is it at all possible to make LPC2119 read
> 16 bits sent by SPI peripheral in succession?
>
> --- In l...@yahoogroups.com, "Alan Strickland"
> wrote:
> >

Looking at the SPI signals with a scope, do you see the command sent
out in the MOSI line and your peripheral answer in the MISO line?
If yes, the problem is restricted to the LPC software.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

This is pretty much our conclusion at this point. It doesn't seem
that SPI in LPC2119 is able to handle data sizes over ine byte, at
least we can't find any references anywhere to the possibility of
that...

It seems that the only way to handle this scenario is through bit
banging, which is the shame. To this point we had absolutely no
issues with LPC2119s... SPI in single byte scenario also works
flawlessly.

What are we missing here?! :-)

--- In l...@yahoogroups.com, "c.barbaro" wrote:
>
> --- In l...@yahoogroups.com, wrote:
> >
> > I was never able to get the SPI engine to send 16 bits. I
ended up
> writing my own code to do it by GPIO.
> > I don't believe the LPC SPI engines can do anything but 8 bit
data
> word size.
> >
> > Chris.
> > I never tried working with 16 bit frames, only 9 bits.
> Anyway Mr Irafalovsky is working with 8 bit frames and is sending
> 2x8bit frames in order to read the 16 bit result.
> Pheraps here is the problem: the SSEL1 signal goes high between the
> two 8 bit frames; are you sure this are not causing problems to
your
> slave device?

Well, SSEL1 pin is connected to VDD (on LPC2119, of course), so I
don't know how this would affect us... We are not toggling
peripheral's SS line between the two byte reads.

>
> > Looking at the SPI signals with a scope, do you see the command
sent
> out in the MOSI line and your peripheral answer in the MISO line?
> If yes, the problem is restricted to the LPC software.
>

We see the command sent correctly on the MOSI with proper timing,
peripheral behaves properly (at least it brings up DRDY line after
measurement is completed) and then we see peripheral pulsing bits on
the MISO line during the first 8 cycles of SCLK, however we never
saw a single pulse during next 8 cycles.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

The User Manual for the LPC2119 does not seem to indicate any
capability for SPI transfer sizes other than 8 bits at a time? However
the user manuals for the LPC2138 and LPC2148 *do* indicate transfer
sizes from 8 to 16 bits per transfer, and give control register
settings for doing those transfer sizes. It probably could be infered
from that, that if the LPC2119 could do 16 bit transfers that the
manual would have indicated it??????????

http://www.standardics.philips.com/products/lpc2000/

-- Dave
--- In l...@yahoogroups.com, wrote:
>
> I was never able to get the SPI engine to send 16 bits. I ended up
writing my own code to do it by GPIO.
> I don't believe the LPC SPI engines can do anything but 8 bit data
word size.
>
> Chris.
> ----- Original Message -----
> From: irafalovsky
> To: l...@yahoogroups.com
> Sent: Tuesday, August 08, 2006 9:00 PM
> Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
> Thank you for your help! Unfortunately, this approach does not work
> either...
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Perhaps it was a typo but the line where you wait for the sensor to
signal that data is ready...

while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready

has an extra & in the masking of IOPIN0. Don't you really mean...

while(!(IOPIN0 & (1 << 22))){;;} // Wait for Data Ready

The first line will only take the while() path once because (1<<22)
will always evaluate (and thus the ! of the whole statement will make
it leave the loop) to true and it won't ever matter what the read
of IOPIN0 is. This seems like it may be consistent with your failure
since the sensor is probably never ready when you start asking it for
the data (i.e doing you SPI reads).

Try Alan's example code with this correction and maybe things will
start working..assuming you've configured the peripheral properly etc.

Also, someone made the point about the SSEL1 toggling after every
byte. This may cause problems with the sensor which probably expects
the chip select to stay low through all 16 clocks for the data. So
unless you are manually controlling another GPIO for the chip
select...be aware of that behaviour on SSEL1.

Hope this helps.

Best regards,
Ryan.

--- In l...@yahoogroups.com, "Alan Strickland"
wrote:
>
> To clear the SPIF bit in S1SPSR you have to access the S1SPSR then
> access the S1SPDR (ie read or write to it). You also have to shift
> out a byte to receive one, and wait for the SPI status to indicate
> SPIF before the received byte can be read.
>
> I use interrupts, so I can't speak to how well polling the SPI
status
> register works. This code is also ignoring any errors that the SPI
> may be setting as well.
>
> Try something along these lines:
>
> S1SPDR = 0x41; // Send Measure X command
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> temp = S1SPDR; // Clears SPIF in S1SPSR.
>
> while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
>
> S1SPDR = 0;.
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> MM3_HB = S1SPDR; // Clears SPIF in S1SPSR.
>
> S1SPDR = 0;
> while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> MM3_LB = S1SPDR; // Clears SPIF in S1SPSR.
>
> wMM3_X = MM3_HB;
> wMM3_X = (wMM3_X << 8) | MM3_LB;
>
> --- In l...@yahoogroups.com, "irafalovsky" wrote:
> >
> > If we attempt to send 2 bytes after peripheral indicates
available
> > data, we simply get zeroes in return...
> >
> > Here's what code looks like:
> >
> > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the MM3
> > delay(10);
> > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > delay(10);
> > S1SPDR = 0x41; // Send Measure X command
> > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > S1SPDR = 0;
> > S1SPDR = 0;
> > MM3_HB = S1SPDR;
> > MM3_LB = S1SPDR;
> > wMM3_X = MM3_HB;
> > wMM3_X = (wMM3_X << 8) | MM3_LB;
> >
> >
> > >
> > > Do you send 2 bytes out from LPC2119 to allow the SPI clock to
go so
> > > you can get back the 2 bytes that you are expecting?
> > >
> > > We have an application with LPC2138 running in slave mode and
> > > receiving packets of 9 bits characters from an host processor
and
> > > responding with packets of 9 bits characters.
> > > Naturally, in order to be able to send back the answer the LPC
must
> > > receive the spi clock from the master so the host processor
must pump
> > > out dummy characters to allow the answer to come back.
> > >
> > > Regards,
> > >
> > > Carlo Barbaro
> > >
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>Original Message:
>-----------------
>From: derbaier
>The User Manual for the LPC2119 does not seem to indicate any
>capability for SPI transfer sizes other than 8 bits at a time? However
>the user manuals for the LPC2138 and LPC2148 *do* indicate transfer
>sizes from 8 to 16 bits per transfer, and give control register
>settings for doing those transfer sizes. It probably could be infered
>from that, that if the LPC2119 could do 16 bit transfers that the
>manual would have indicated it??????????

Don't confuse word size with frame size. I have not seen an SPI peripheral
yet that limited the frame size even though many have a fixed word size of
8 bits.

The standard SPI peripheral, which I have worked with, uses a fixed 8 bit
words size and has no problem with multiple word in the same frame.

Robert
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

It seems that LPC2138/LPC2148 have SPI1 configured as SSP with
buffered data register, which manual for LPC2119 has no mentioning
of... In fact, first two bits of S1SPCR register are defined as
reserved, whereas first two bits of this register for 2138/2148
defind as data size...

--- In l...@yahoogroups.com, "derbaier" wrote:
> The User Manual for the LPC2119 does not seem to indicate any
> capability for SPI transfer sizes other than 8 bits at a time?
However
> the user manuals for the LPC2138 and LPC2148 *do* indicate transfer
> sizes from 8 to 16 bits per transfer, and give control register
> settings for doing those transfer sizes. It probably could be
infered
> from that, that if the LPC2119 could do 16 bit transfers that the
> manual would have indicated it??????????
>
> http://www.standardics.philips.com/products/lpc2000/
>
> -- Dave
> --- In l...@yahoogroups.com, wrote:
> >
> > I was never able to get the SPI engine to send 16 bits. I
ended up
> writing my own code to do it by GPIO.
> > I don't believe the LPC SPI engines can do anything but 8 bit
data
> word size.
> >
> > Chris.
> >
> >
> > ----- Original Message -----
> > From: irafalovsky
> > To: l...@yahoogroups.com
> > Sent: Tuesday, August 08, 2006 9:00 PM
> > Subject: [lpc2000] Re: Problem with SPI1 on LPC2119
> >
> >
> > Thank you for your help! Unfortunately, this approach does not
work
> > either...
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

In our code, we make chipselect using a separate pin, LPC2119
requires SPI SSEL pin to be high if MCU is in master mode, therefore
we connected it to VDD, as per user manual.

I will ask the engineer who used && operand there for his reasoning,
I think it wasn't a typo...

--- In l...@yahoogroups.com, "tirfec" wrote:
>
> Perhaps it was a typo but the line where you wait for the sensor
to
> signal that data is ready...
>
> while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
>
> has an extra & in the masking of IOPIN0. Don't you really mean...
>
> while(!(IOPIN0 & (1 << 22))){;;} // Wait for Data Ready
>
> The first line will only take the while() path once because
(1<<22)
> will always evaluate (and thus the ! of the whole statement will
make
> it leave the loop) to true and it won't ever matter what the read
> of IOPIN0 is. This seems like it may be consistent with your
failure
> since the sensor is probably never ready when you start asking it
for
> the data (i.e doing you SPI reads).
>
> Try Alan's example code with this correction and maybe things will
> start working..assuming you've configured the peripheral properly
etc.
>
> Also, someone made the point about the SSEL1 toggling after every
> byte. This may cause problems with the sensor which probably
expects
> the chip select to stay low through all 16 clocks for the data. So
> unless you are manually controlling another GPIO for the chip
> select...be aware of that behaviour on SSEL1.
>
> Hope this helps.
>
> Best regards,
> Ryan.
>
> --- In l...@yahoogroups.com, "Alan Strickland"
> wrote:
> >
> > To clear the SPIF bit in S1SPSR you have to access the S1SPSR
then
> > access the S1SPDR (ie read or write to it). You also have to
shift
> > out a byte to receive one, and wait for the SPI status to
indicate
> > SPIF before the received byte can be read.
> >
> > I use interrupts, so I can't speak to how well polling the SPI
> status
> > register works. This code is also ignoring any errors that the
SPI
> > may be setting as well.
> >
> > Try something along these lines:
> >
> > S1SPDR = 0x41; // Send Measure X command
> > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > temp = S1SPDR; // Clears SPIF in S1SPSR.
> >
> > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> >
> > S1SPDR = 0;.
> > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > MM3_HB = S1SPDR; // Clears SPIF in S1SPSR.
> >
> > S1SPDR = 0;
> > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > MM3_LB = S1SPDR; // Clears SPIF in S1SPSR.
> >
> > wMM3_X = MM3_HB;
> > wMM3_X = (wMM3_X << 8) | MM3_LB;
> >
> > --- In l...@yahoogroups.com, "irafalovsky" wrote:
> > >
> > > If we attempt to send 2 bytes after peripheral indicates
> available
> > > data, we simply get zeroes in return...
> > >
> > > Here's what code looks like:
> > >
> > > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the
MM3
> > > delay(10);
> > > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > > delay(10);
> > > S1SPDR = 0x41; // Send Measure X command
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > > S1SPDR = 0;
> > > S1SPDR = 0;
> > > MM3_HB = S1SPDR;
> > > MM3_LB = S1SPDR;
> > > wMM3_X = MM3_HB;
> > > wMM3_X = (wMM3_X << 8) | MM3_LB;
> > >
> > >
> > > >
> > > > Do you send 2 bytes out from LPC2119 to allow the SPI clock
to
> go so
> > > > you can get back the 2 bytes that you are expecting?
> > > >
> > > > We have an application with LPC2138 running in slave mode and
> > > > receiving packets of 9 bits characters from an host
processor
> and
> > > > responding with packets of 9 bits characters.
> > > > Naturally, in order to be able to send back the answer the
LPC
> must
> > > > receive the spi clock from the master so the host processor
> must pump
> > > > out dummy characters to allow the answer to come back.
> > > >
> > > > Regards,
> > > >
> > > > Carlo Barbaro
> > > >
> > >
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "subscriptions@..."
wrote:
>
> >Original Message:
> >-----------------
> >From: derbaier
> >The User Manual for the LPC2119 does not seem to indicate any
> >capability for SPI transfer sizes other than 8 bits at a time? However
> >the user manuals for the LPC2138 and LPC2148 *do* indicate transfer
> >sizes from 8 to 16 bits per transfer, and give control register
> >settings for doing those transfer sizes. It probably could be infered
> >from that, that if the LPC2119 could do 16 bit transfers that the
> >manual would have indicated it??????????
>
> Don't confuse word size with frame size. I have not seen an SPI
peripheral
> yet that limited the frame size even though many have a fixed word
size of
> 8 bits.
>
> The standard SPI peripheral, which I have worked with, uses a fixed
8 bit
> words size and has no problem with multiple word in the same frame.
>
> Robert
>
Your interpretation *may* be more correct than mine, but I thought
that it might be useful to put that information out since nothing else
has worked so far.

My interpretation from the SPI documentation is that the word size is
defined by hardware, and frame size is purely a software construct
above the hardware implementation. So any frame size should work as
long as both sides of the transaction aggree what it is. However, both
sets of hardware also need to agree on a word size too, since the
state machines controling the transfer need to remain in
synchronization. That is how I viewed the transfer when I built some
code to use SPI with MMC/SD cards, and it does work when viewed that way.

-- Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>Original Message:
>-----------------
>From: derbaier
>My interpretation from the SPI documentation is that the word size is
>defined by hardware, and frame size is purely a software construct
>above the hardware implementation. So any frame size should work as
>long as both sides of the transaction aggree what it is.

Agreed, although some SPI HW lets you choose the word size to some degree.
The HW/SW split is pretty arbitrary, it could occur at any level. The
hierarchy is reasonable though and it's not a bad mental model.
>However, both
>sets of hardware also need to agree on a word size too, since the
>state machines controling the transfer need to remain in
>synchronization.

There is no way for the slave HW to know how many bits the master uses per
word so it cannot have any dependancies on word size. However, all the SPI
slaves I've used that have frame sizes that are not muliples of 8 bits
allow the frame to be padded up to an 8 bit multiple at either the leading
or trailing edge. Some allow an arbitrary padding only paying attention to
the first n or last n bits.

I've heard rumors that devices exist that frame on clock idle times rather
than a chip select, in that case interword delays would need to be checked.
Strictly speaking that's not really SPI anymore though.
Robert
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "irafalovsky" wrote:
>
> It seems that LPC2138/LPC2148 have SPI1 configured as SSP with
> buffered data register, which manual for LPC2119 has no mentioning
> of... In fact, first two bits of S1SPCR register are defined as
> reserved, whereas first two bits of this register for 2138/2148
> defind as data size...
>
> --- In l...@yahoogroups.com, "derbaier" wrote:

In the LPC2138/48 there two SPIs. SPI0 is "Compliant with Serial
Peripheral Interface (SPI) specification." , whereas SPI1 is
"Compatible with Motorola SPI, 4-wire TI SSI, and National
Semiconductor Microwire
buses." In SPI0 bits 11:8 of S0SPCR control the units of transfer,
while bits 3:0 of SSPCR0 in SPI1 control the units of transfer. There
is also an 8 word/frame FIFO in SPI1 which is 16 bits wide, as is the
data register of SPI0. However, the data register of the LPC2119 is
only 8 bits wide, so transfers have to be in units of 8 bits. You
should be able to combine as many 8 bit units as needed if both sides
of the transfer agree, since the hardware state machine in the LPC2119
is going to deslect the slave after each 8 bit unit.
That is all in my interpretation of course!

-- Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "subscriptions@..."
wrote:

> There is no way for the slave HW to know how many bits the master
>uses per word so it cannot have any dependancies on word size.

I thought that the transition of the slave select signal identified
the end of the current word, and reset the slave state machine to
begin the next word???????????????

--Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>Original Message:
>-----------------
>From: derbaier
>--- In l...@yahoogroups.com, "subscriptions@..."
> wrote:
>
>> There is no way for the slave HW to know how many bits the master
>>uses per word so it cannot have any dependancies on word size.
>
>I thought that the transition of the slave select signal identified
>the end of the current word, and reset the slave state machine to
>begin the next word???????????????

Nope, Chip select is done on a frame basis. Of the three devices I've got
on one board at the moment, one has a frame size of 12 bits, one of 24 bits
and one is an indeterminate multiple of 8 bits (the frame size depends on
how many 8 bit bytes I want to read/write at once). All controlled via the
Philips inital SPI with a fixed 8 bit word size. If you toggle the slave
select between words you will definitely fail.

Robert
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I wonder, what mechanism is used to "deselect the slave" if the pin
for chipselect is not controlled by SPI but by a user program, is
that some sort of internal workings of SPI implementation on LPC?

I didn't see anything like that in documentation...

--- In l...@yahoogroups.com, "derbaier" wrote:
>
> --- In l...@yahoogroups.com, "irafalovsky" wrote:
> >
> > It seems that LPC2138/LPC2148 have SPI1 configured as SSP with
> > buffered data register, which manual for LPC2119 has no
mentioning
> > of... In fact, first two bits of S1SPCR register are defined as
> > reserved, whereas first two bits of this register for 2138/2148
> > defind as data size...
> >
> > --- In l...@yahoogroups.com, "derbaier" wrote:
>
> In the LPC2138/48 there two SPIs. SPI0 is "Compliant with Serial
> Peripheral Interface (SPI) specification." , whereas SPI1 is
> "Compatible with Motorola SPI, 4-wire TI SSI, and National
> Semiconductor Microwire
> buses." In SPI0 bits 11:8 of S0SPCR control the units of transfer,
> while bits 3:0 of SSPCR0 in SPI1 control the units of transfer.
There
> is also an 8 word/frame FIFO in SPI1 which is 16 bits wide, as is
the
> data register of SPI0. However, the data register of the LPC2119 is
> only 8 bits wide, so transfers have to be in units of 8 bits. You
> should be able to combine as many 8 bit units as needed if both
sides
> of the transfer agree, since the hardware state machine in the
LPC2119
> is going to deslect the slave after each 8 bit unit.
> That is all in my interpretation of course!
>
> -- Dave
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>Original Message:
>-----------------
>From: irafalovsky

>I wonder, what mechanism is used to "deselect the slave" if the pin
>for chipselect is not controlled by SPI but by a user program, is
>that some sort of internal workings of SPI implementation on LPC?

That's your job. You select the slave before starting the frame and
deselect it after frame end.

Robert
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "subscriptions@..."
wrote:
>
> >Original Message:
> >-----------------
> >From: derbaier
> >--- In l...@yahoogroups.com, "subscriptions@"
> > wrote:
> >
> >> There is no way for the slave HW to know how many bits the master
> >>uses per word so it cannot have any dependancies on word size.
> >
> >I thought that the transition of the slave select signal identified
> >the end of the current word, and reset the slave state machine to
> >begin the next word???????????????
>
> Nope, Chip select is done on a frame basis. Of the three devices
I've got
> on one board at the moment, one has a frame size of 12 bits, one of
24 bits
> and one is an indeterminate multiple of 8 bits (the frame size
depends on
> how many 8 bit bytes I want to read/write at once). All controlled
via the
> Philips inital SPI with a fixed 8 bit word size. If you toggle the
slave
> select between words you will definitely fail.
>
> Robert
>
But the LPC2119 does toggle slave select every 8 bits, which indicates
to me that it's internal state machine is resetting regardless of what
the peripheral is doing?

I hope that Mr. Irafalovsky posts his final outcome, because now my
curiosity is really arroused.

-- Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Would you be willing to share a code example with the group or send
it to me? We're banging our heads on the wall here... :-)

--- In l...@yahoogroups.com, "subscriptions@..."
wrote:
>
> >Original Message:
> >-----------------
> >From: derbaier
> >--- In l...@yahoogroups.com, "subscriptions@"
> > wrote:
> >
> >> There is no way for the slave HW to know how many bits the
master
> >>uses per word so it cannot have any dependancies on word size.
> >
> >I thought that the transition of the slave select signal
identified
> >the end of the current word, and reset the slave state machine to
> >begin the next word???????????????
>
> Nope, Chip select is done on a frame basis. Of the three devices
I've got
> on one board at the moment, one has a frame size of 12 bits, one
of 24 bits
> and one is an indeterminate multiple of 8 bits (the frame size
depends on
> how many 8 bit bytes I want to read/write at once). All
controlled via the
> Philips inital SPI with a fixed 8 bit word size. If you toggle
the slave
> select between words you will definitely fail.
>
> Robert
> -------------------------------------------------------------------
-
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>Original Message:
>-----------------
>From: irafalovsky
>
>Would you be willing to share a code example with the group or send
>it to me? We're banging our heads on the wall here... :-)

Check the newlib-lpc stuff at http://www.aeolusdevelopment.com

It's only for SPI0, developed originally for LPC2104/5/6 so it has none of
this fancy word size selection etc... ;)

There is an FRAM driver though and that does use the spi driver to to the
underlying work. Since the structure is meant to be built on to abstract
the SPI functionality away from the device driver it's not the clearest
exposition of the SPI itself. It is, however, commented.

Robert

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>Original Message:
>-----------------
>From: derbaier
> wrote:
>>
>> Nope, Chip select is done on a frame basis. Of the three devices I've
got
>> on one board at the moment, one has a frame size of 12 bits, one of 24
bits
>> and one is an indeterminate multiple of 8 bits (the frame size depends on
>> how many 8 bit bytes I want to read/write at once). All controlled via
the
>> Philips inital SPI with a fixed 8 bit word size. If you toggle the slave
>> select between words you will definitely fail.
>
>But the LPC2119 does toggle slave select every 8 bits, which indicates
>to me that it's internal state machine is resetting regardless of what
>the peripheral is doing?

If that's the case it's broken. Don't use the automatic slave select. If
it toggles every word it will work with only a small number of slave
devices.

Robert
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "subscriptions@..."
wrote:
>
> >Original Message:
> >-----------------
> >From: derbaier
> > wrote:
> >>
> >> Nope, Chip select is done on a frame basis. Of the three devices
I've
> got
> >> on one board at the moment, one has a frame size of 12 bits, one
of 24
> bits
> >> and one is an indeterminate multiple of 8 bits (the frame size
depends on
> >> how many 8 bit bytes I want to read/write at once). All
controlled via
> the
> >> Philips inital SPI with a fixed 8 bit word size. If you toggle
the slave
> >> select between words you will definitely fail.
> >
> >But the LPC2119 does toggle slave select every 8 bits, which indicates
> >to me that it's internal state machine is resetting regardless of what
> >the peripheral is doing?
>
> If that's the case it's broken. Don't use the automatic slave
select. If
> it toggles every word it will work with only a small number of slave
> devices.
>
> Robert
>

Isn't that what this thread is all about???

-- Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

The code that Alan presented should be correct...however, you
absolutely MUST change the double ampersand (&&) to a single one (&)
in your wait loop.

For example,

while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready

must be replaced with...

while(!(IOPIN0 & (1 << 22))){;;} // Wait for Data Ready

In the top case you will never wait since && means a logical 'AND'.
Therefore (1<<22) will always evaluate to non-zero (therefore
TRUE)...and its very likely that at least one of the bits in the read
of IOPIN0 will be high thus making that part TRUE and the whole
expression will evaluate to TRUE...which after you negate with the !
out in front will cause you to leave the loop immediately (which is
not what you intended for it to do).

What you mean to do with your expression is to MASK the bit of
interest (in this case bit 22) with a read of IOPIN0...that's what
the single & is for...take a moment in any C reference to review the
meaning of the operators and you'll be back on track.

I took a quick glance at the datasheet for the sensor you are using
and the Data Ready signal may not be asserted for 500 microSeconds in
the best case and could take as long as 60 milliSeconds in the worst
case (based on the Period Select setting...which I'm not sure which
one you are using). Since your wait loop never actually waits, you
will NEVER expect to see valid data! Even if you have the SPI and
chip select configured properly you will NEVER see valid data because
you are not actually waiting for it.

I'm sure you've checked the direction of Pin 22 but just for sanity
make sure you have it configured as an input also. You may want to
pay fairly close attention to this pin and whether or not there is an
internal pull-up enabled on it. It's very unlikely, but perhaps the
sensor's Data Ready output isn't strong enough to pull the line low
when data is not yet ready. Maybe just double check the levels to
which the pin is toggling and see that they are at expected levels.

I hope this helps you get things working...I know what it feels like
to be in pain sometimes.

Best regards,
Ryan.
--- In l...@yahoogroups.com, "irafalovsky" wrote:
>
> Would you be willing to share a code example with the group or send
> it to me? We're banging our heads on the wall here... :-)
>
> --- In l...@yahoogroups.com, "subscriptions@"
> wrote:
> >
> >
> >
> > >Original Message:
> > >-----------------
> > >From: derbaier
> > >--- In l...@yahoogroups.com, "subscriptions@"
> > > wrote:
> > >
> > >> There is no way for the slave HW to know how many bits the
> master
> > >>uses per word so it cannot have any dependancies on word size.
> > >
> > >I thought that the transition of the slave select signal
> identified
> > >the end of the current word, and reset the slave state machine to
> > >begin the next word???????????????
> >
> > Nope, Chip select is done on a frame basis. Of the three devices
> I've got
> > on one board at the moment, one has a frame size of 12 bits, one
> of 24 bits
> > and one is an indeterminate multiple of 8 bits (the frame size
> depends on
> > how many 8 bit bytes I want to read/write at once). All
> controlled via the
> > Philips inital SPI with a fixed 8 bit word size. If you toggle
> the slave
> > select between words you will definitely fail.
> >
> > Robert
> >
> >
> > ------------------------------------------------------------------
-
> -
> > mail2web - Check your email from the web at
> > http://mail2web.com/ .
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>Original Message:
>-----------------
>From: derbaier
>>--- In l...@yahoogroups.com, "subscriptions@..."
wrote:
>>>
>>>
>>>
>>>From: derbaier
>>>
>>>But the LPC2119 does toggle slave select every 8 bits, which indicates
>>>to me that it's internal state machine is resetting regardless of what
>>>the peripheral is doing?
>>
>> If that's the case it's broken. Don't use the automatic slave select.
If
>> it toggles every word it will work with only a small number of slave
>> devices.
>
>Isn't that what this thread is all about???

I didn't think so. I thought there was an injunction to check the chip
select early on. We seem to have wandered off into the weeds on it but I
thought the main thread had already dealt with it, as in chipselct was oon
and stayed on through the transaction.

Robert
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

irafalovsky wrote:

> In our code, we make chipselect using a separate pin, LPC2119
> requires SPI SSEL pin to be high if MCU is in master mode, therefore
> we connected it to VDD, as per user manual.
>
> I will ask the engineer who used && operand there for his reasoning,
> I think it wasn't a typo...
>

"&&" is a logical AND, while "&" is a boolean AND.

TomW
>
> --- In lpc2000@yahoogroups .com ,
> "tirfec" wrote:
> >
> > Perhaps it was a typo but the line where you wait for the sensor
> to
> > signal that data is ready...
> >
> > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> >
> > has an extra & in the masking of IOPIN0. Don't you really mean...
> >
> > while(!(IOPIN0 & (1 << 22))){;;} // Wait for Data Ready
> >
> > The first line will only take the while() path once because
> (1<<22)
> > will always evaluate (and thus the ! of the whole statement will
> make
> > it leave the loop) to true and it won't ever matter what the read
> > of IOPIN0 is. This seems like it may be consistent with your
> failure
> > since the sensor is probably never ready when you start asking it
> for
> > the data (i.e doing you SPI reads).
> >
> > Try Alan's example code with this correction and maybe things will
> > start working..assuming you've configured the peripheral properly
> etc.
> >
> > Also, someone made the point about the SSEL1 toggling after every
> > byte. This may cause problems with the sensor which probably
> expects
> > the chip select to stay low through all 16 clocks for the data. So
> > unless you are manually controlling another GPIO for the chip
> > select...be aware of that behaviour on SSEL1.
> >
> > Hope this helps.
> >
> > Best regards,
> > Ryan.
> >
> > --- In lpc2000@yahoogroups .com ,
> "Alan Strickland"
> > wrote:
> > >
> > > To clear the SPIF bit in S1SPSR you have to access the S1SPSR
> then
> > > access the S1SPDR (ie read or write to it). You also have to
> shift
> > > out a byte to receive one, and wait for the SPI status to
> indicate
> > > SPIF before the received byte can be read.
> > >
> > > I use interrupts, so I can't speak to how well polling the SPI
> > status
> > > register works. This code is also ignoring any errors that the
> SPI
> > > may be setting as well.
> > >
> > > Try something along these lines:
> > >
> > > S1SPDR = 0x41; // Send Measure X command
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > temp = S1SPDR; // Clears SPIF in S1SPSR.
> > >
> > > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > >
> > > S1SPDR = 0;.
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > MM3_HB = S1SPDR; // Clears SPIF in S1SPSR.
> > >
> > > S1SPDR = 0;
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > MM3_LB = S1SPDR; // Clears SPIF in S1SPSR.
> > >
> > > wMM3_X = MM3_HB;
> > > wMM3_X = (wMM3_X << 8) | MM3_LB;
> > >
> > > --- In lpc2000@yahoogroups .com
> , "irafalovsky" wrote:
> > > >
> > > > If we attempt to send 2 bytes after peripheral indicates
> > available
> > > > data, we simply get zeroes in return...
> > > >
> > > > Here's what code looks like:
> > > >
> > > > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the
> MM3
> > > > delay(10);
> > > > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > > > delay(10);
> > > > S1SPDR = 0x41; // Send Measure X command
> > > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > > > S1SPDR = 0;
> > > > S1SPDR = 0;
> > > > MM3_HB = S1SPDR;
> > > > MM3_LB = S1SPDR;
> > > > wMM3_X = MM3_HB;
> > > > wMM3_X = (wMM3_X << 8) | MM3_LB;
> > > >
> > > >
> > > > >
> > > > > Do you send 2 bytes out from LPC2119 to allow the SPI clock
> to
> > go so
> > > > > you can get back the 2 bytes that you are expecting?
> > > > >
> > > > > We have an application with LPC2138 running in slave mode and
> > > > > receiving packets of 9 bits characters from an host
> processor
> > and
> > > > > responding with packets of 9 bits characters.
> > > > > Naturally, in order to be able to send back the answer the
> LPC
> > must
> > > > > receive the spi clock from the master so the host processor
> > must pump
> > > > > out dummy characters to allow the answer to come back.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Carlo Barbaro
> > > > >
> > > >
> > >
> >

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I wanted to thank everybody for help and advice! We finally got
everything working well between the MicroMag3 and LPC2119 using
SPI0/SPI1. The problem was with the sensor itself and PNI Corp has
replaced it with working one.

As to the multiple byte transfers on SPI in LPC2119, it works as
expected and demonstrated in code samples in this thread.

--- In l...@yahoogroups.com, wrote:
>
> I was never able to get the SPI engine to send 16 bits. I ended up
writing my own code to do it by GPIO.
> I don't believe the LPC SPI engines can do anything but 8 bit data
word size.
>
> Chris.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )