Hi,
when switching an lpc2000 design with a SPI slave to a lpc24xx I used
the second set of MISO0 / MOSI0 / SSEL0 / SCK0 pins on P2[xx] expecting
to be able to run my existing SPI code via these port pins. After
investigating several hours into "why doesn't it work anymore" I found
out that the SPI clock SCK (not SCK0) is available on P0[15] only, so
when using P2[xx] SSP0 must be used (thank you NXP for laying this
snare, life would be too boring otherwise) to run my SPI code.
So I tried to modify the code accordingly, but I'm stuck on two issues:
a) How can I empty the TX FIFO of SSP0 to ensure that I'm in a initial
state ? I could not find any possibilty in the spec to clear the TX FIFO.
b) Bit RTIM in SSP0IMSC must be set to get an interrupt when data has
been clocked in: The manual says 'A Receive Timeout occurs when the Rx
FIFO is not empty, and no has not been read for a "timeout period".' -
so what is a "timeout period", resp. when do I get the interrupt after
the first byte has been clocked in ?
Especially b) makes me a lot of headache:
The SPI protocol I need to interprete is as follows: The master sends a
unique introducer, a command byte (e.g. read or write) and the length to
be read / written. When reading from my lpc24xx device the master
assumes the first byte after the length byte is to be ignored but
afterwards valid data must be available. So how can I ensure that I put
data into the TX FIFO at the correct moment ???
Thanks for your help & suggestions in advance.
Best regards
Herbert
SSP issues with lpc24xx
Started by ●March 17, 2009
Reply by ●March 17, 20092009-03-17
>> So how can I ensure that I put data into the TX FIFO
at the correct moment ???
I gave all my code for an SPI/SSP module previously in a post. It is IRQ driven. Search.
Chris.
I gave all my code for an SPI/SSP module previously in a post. It is IRQ driven. Search.
Chris.
Reply by ●March 17, 20092009-03-17
Chris,
not all people posting in this group do this without checking for
similar issues first.
So your impetus "search first ask later" is incongruous here - besides
that, I was talking about SPI slave (your code is SPI master).
Herbert
HM2 schrieb:
>>> So how can I ensure that I put data into the TX FIFO at the correct moment ???
>>>
>
> I gave all my code for an SPI/SSP module previously in a post. It is IRQ driven. Search.
>
> Chris.
>
>
not all people posting in this group do this without checking for
similar issues first.
So your impetus "search first ask later" is incongruous here - besides
that, I was talking about SPI slave (your code is SPI master).
Herbert
HM2 schrieb:
>>> So how can I ensure that I put data into the TX FIFO at the correct moment ???
>>>
>
> I gave all my code for an SPI/SSP module previously in a post. It is IRQ driven. Search.
>
> Chris.
>
>
Reply by ●March 17, 20092009-03-17
Hi Herbert:
I ran into exactly the same issues with the SSP0 as slave in one of our projects. This is the information I have:
1. LPC2300/LPC2400 use the ARM PrimeCell PL022 (Document DDI 0194D) to implement the SSP block. If you go to the ARM website you will be able to download the complete datasheet for this block.
You'll notice that this SSP module has several extra registers used for testing purposes (not mentioned in the NXP User Manual). One of the testing options is able to read from the TX FIFO. By enabling this option and reading the TX FIFO until is empty, you can effectively clear the TX FIFO.
Note, however, that "technically" this is no documented in NXP datasheet/user manual, and, therefore, might not be supported in the future.
2. In that SSP Block Manual, there is also the explanation about the receive timeout interrupt: "the receive interrupt is asserted when the receiver FIFO is not empty and the PrimeCell SSP has remainded idle for a fixed 32-bit period"
Basically, if enabled, you'll get an interrupt every 4 bytes (if you haven't read the data).
In our application we decided to disable this interrupt, and just work with the RX FIFO receive interrupt only.
SSP as slave always have to be carefully designed, so that there is enough time in the ISR to fill the TX FIFO before the next byte of data arrives from the master. The advantage of this SSP is the FIFO, which allow you receive interrupts every 4 bytes, instead of every byte, and have time to set the data for the next transaction.
One solution to communicate Master-Slave is to have fixed-size transactions. In this case every transaction is, let's say, 30 bytes.
Another solution could be to have a two-stage transaction: first stage transmits two bytes (command byte and size for next transaction). Second stage transmit the ammount of bytes setup in the first transaction.
Regards,
Alex.
--- In l..., Herbert Demmel wrote:
>
> Hi,
>
> when switching an lpc2000 design with a SPI slave to a lpc24xx I used
> the second set of MISO0 / MOSI0 / SSEL0 / SCK0 pins on P2[xx] expecting
> to be able to run my existing SPI code via these port pins. After
> investigating several hours into "why doesn't it work anymore" I found
> out that the SPI clock SCK (not SCK0) is available on P0[15] only, so
> when using P2[xx] SSP0 must be used (thank you NXP for laying this
> snare, life would be too boring otherwise) to run my SPI code.
>
> So I tried to modify the code accordingly, but I'm stuck on two issues:
>
> a) How can I empty the TX FIFO of SSP0 to ensure that I'm in a initial
> state ? I could not find any possibilty in the spec to clear the TX FIFO.
> b) Bit RTIM in SSP0IMSC must be set to get an interrupt when data has
> been clocked in: The manual says 'A Receive Timeout occurs when the Rx
> FIFO is not empty, and no has not been read for a "timeout period".' -
> so what is a "timeout period", resp. when do I get the interrupt after
> the first byte has been clocked in ?
>
> Especially b) makes me a lot of headache:
> The SPI protocol I need to interprete is as follows: The master sends a
> unique introducer, a command byte (e.g. read or write) and the length to
> be read / written. When reading from my lpc24xx device the master
> assumes the first byte after the length byte is to be ignored but
> afterwards valid data must be available. So how can I ensure that I put
> data into the TX FIFO at the correct moment ???
>
> Thanks for your help & suggestions in advance.
>
> Best regards
> Herbert
>
I ran into exactly the same issues with the SSP0 as slave in one of our projects. This is the information I have:
1. LPC2300/LPC2400 use the ARM PrimeCell PL022 (Document DDI 0194D) to implement the SSP block. If you go to the ARM website you will be able to download the complete datasheet for this block.
You'll notice that this SSP module has several extra registers used for testing purposes (not mentioned in the NXP User Manual). One of the testing options is able to read from the TX FIFO. By enabling this option and reading the TX FIFO until is empty, you can effectively clear the TX FIFO.
Note, however, that "technically" this is no documented in NXP datasheet/user manual, and, therefore, might not be supported in the future.
2. In that SSP Block Manual, there is also the explanation about the receive timeout interrupt: "the receive interrupt is asserted when the receiver FIFO is not empty and the PrimeCell SSP has remainded idle for a fixed 32-bit period"
Basically, if enabled, you'll get an interrupt every 4 bytes (if you haven't read the data).
In our application we decided to disable this interrupt, and just work with the RX FIFO receive interrupt only.
SSP as slave always have to be carefully designed, so that there is enough time in the ISR to fill the TX FIFO before the next byte of data arrives from the master. The advantage of this SSP is the FIFO, which allow you receive interrupts every 4 bytes, instead of every byte, and have time to set the data for the next transaction.
One solution to communicate Master-Slave is to have fixed-size transactions. In this case every transaction is, let's say, 30 bytes.
Another solution could be to have a two-stage transaction: first stage transmits two bytes (command byte and size for next transaction). Second stage transmit the ammount of bytes setup in the first transaction.
Regards,
Alex.
--- In l..., Herbert Demmel wrote:
>
> Hi,
>
> when switching an lpc2000 design with a SPI slave to a lpc24xx I used
> the second set of MISO0 / MOSI0 / SSEL0 / SCK0 pins on P2[xx] expecting
> to be able to run my existing SPI code via these port pins. After
> investigating several hours into "why doesn't it work anymore" I found
> out that the SPI clock SCK (not SCK0) is available on P0[15] only, so
> when using P2[xx] SSP0 must be used (thank you NXP for laying this
> snare, life would be too boring otherwise) to run my SPI code.
>
> So I tried to modify the code accordingly, but I'm stuck on two issues:
>
> a) How can I empty the TX FIFO of SSP0 to ensure that I'm in a initial
> state ? I could not find any possibilty in the spec to clear the TX FIFO.
> b) Bit RTIM in SSP0IMSC must be set to get an interrupt when data has
> been clocked in: The manual says 'A Receive Timeout occurs when the Rx
> FIFO is not empty, and no has not been read for a "timeout period".' -
> so what is a "timeout period", resp. when do I get the interrupt after
> the first byte has been clocked in ?
>
> Especially b) makes me a lot of headache:
> The SPI protocol I need to interprete is as follows: The master sends a
> unique introducer, a command byte (e.g. read or write) and the length to
> be read / written. When reading from my lpc24xx device the master
> assumes the first byte after the length byte is to be ignored but
> afterwards valid data must be available. So how can I ensure that I put
> data into the TX FIFO at the correct moment ???
>
> Thanks for your help & suggestions in advance.
>
> Best regards
> Herbert
>
Reply by ●March 17, 20092009-03-17
Alex,
thanks for your help. I got a contact with NXP in the meantime and they
told me the same workaround with the test register. Regarding the 32
cycle delay until the interrupts fires, I only have to say that the
design of the SSP part is completely mad (not to spend a interrupt
possibilty after a single byte is receive *is* stupid).
In my case it's necessary to have a variable protocol (I can't use fixed
size protocols) needing to switch the direction of transfer within one
"packet" and to retrieve buffer fill status and other things. All this
was no problem when using the standard SPI of the lpc2xxx but is a
serious problem because of the missing interrupt possibilty.
The idea NXP had, was to use DMA for SSP with 1 byte transfer size
getting an interrupt after every byte (a very strange workaround but
better than nothing).
Herbert
Alex Ribero schrieb:
> Hi Herbert:
>
> I ran into exactly the same issues with the SSP0 as slave in one of our projects. This is the information I have:
>
> 1. LPC2300/LPC2400 use the ARM PrimeCell PL022 (Document DDI 0194D) to implement the SSP block. If you go to the ARM website you will be able to download the complete datasheet for this block.
>
> You'll notice that this SSP module has several extra registers used for testing purposes (not mentioned in the NXP User Manual). One of the testing options is able to read from the TX FIFO. By enabling this option and reading the TX FIFO until is empty, you can effectively clear the TX FIFO.
>
> Note, however, that "technically" this is no documented in NXP datasheet/user manual, and, therefore, might not be supported in the future.
>
> 2. In that SSP Block Manual, there is also the explanation about the receive timeout interrupt: "the receive interrupt is asserted when the receiver FIFO is not empty and the PrimeCell SSP has remainded idle for a fixed 32-bit period"
>
> Basically, if enabled, you'll get an interrupt every 4 bytes (if you haven't read the data).
>
> In our application we decided to disable this interrupt, and just work with the RX FIFO receive interrupt only.
>
> SSP as slave always have to be carefully designed, so that there is enough time in the ISR to fill the TX FIFO before the next byte of data arrives from the master. The advantage of this SSP is the FIFO, which allow you receive interrupts every 4 bytes, instead of every byte, and have time to set the data for the next transaction.
>
> One solution to communicate Master-Slave is to have fixed-size transactions. In this case every transaction is, let's say, 30 bytes.
>
> Another solution could be to have a two-stage transaction: first stage transmits two bytes (command byte and size for next transaction). Second stage transmit the ammount of bytes setup in the first transaction.
> Regards,
>
> Alex.
>
> --- In l..., Herbert Demmel wrote:
>
>> Hi,
>>
>> when switching an lpc2000 design with a SPI slave to a lpc24xx I used
>> the second set of MISO0 / MOSI0 / SSEL0 / SCK0 pins on P2[xx] expecting
>> to be able to run my existing SPI code via these port pins. After
>> investigating several hours into "why doesn't it work anymore" I found
>> out that the SPI clock SCK (not SCK0) is available on P0[15] only, so
>> when using P2[xx] SSP0 must be used (thank you NXP for laying this
>> snare, life would be too boring otherwise) to run my SPI code.
>>
>> So I tried to modify the code accordingly, but I'm stuck on two issues:
>>
>> a) How can I empty the TX FIFO of SSP0 to ensure that I'm in a initial
>> state ? I could not find any possibilty in the spec to clear the TX FIFO.
>> b) Bit RTIM in SSP0IMSC must be set to get an interrupt when data has
>> been clocked in: The manual says 'A Receive Timeout occurs when the Rx
>> FIFO is not empty, and no has not been read for a "timeout period".' -
>> so what is a "timeout period", resp. when do I get the interrupt after
>> the first byte has been clocked in ?
>>
>> Especially b) makes me a lot of headache:
>> The SPI protocol I need to interprete is as follows: The master sends a
>> unique introducer, a command byte (e.g. read or write) and the length to
>> be read / written. When reading from my lpc24xx device the master
>> assumes the first byte after the length byte is to be ignored but
>> afterwards valid data must be available. So how can I ensure that I put
>> data into the TX FIFO at the correct moment ???
>>
>> Thanks for your help & suggestions in advance.
>>
>> Best regards
>> Herbert
>>
>>
>
thanks for your help. I got a contact with NXP in the meantime and they
told me the same workaround with the test register. Regarding the 32
cycle delay until the interrupts fires, I only have to say that the
design of the SSP part is completely mad (not to spend a interrupt
possibilty after a single byte is receive *is* stupid).
In my case it's necessary to have a variable protocol (I can't use fixed
size protocols) needing to switch the direction of transfer within one
"packet" and to retrieve buffer fill status and other things. All this
was no problem when using the standard SPI of the lpc2xxx but is a
serious problem because of the missing interrupt possibilty.
The idea NXP had, was to use DMA for SSP with 1 byte transfer size
getting an interrupt after every byte (a very strange workaround but
better than nothing).
Herbert
Alex Ribero schrieb:
> Hi Herbert:
>
> I ran into exactly the same issues with the SSP0 as slave in one of our projects. This is the information I have:
>
> 1. LPC2300/LPC2400 use the ARM PrimeCell PL022 (Document DDI 0194D) to implement the SSP block. If you go to the ARM website you will be able to download the complete datasheet for this block.
>
> You'll notice that this SSP module has several extra registers used for testing purposes (not mentioned in the NXP User Manual). One of the testing options is able to read from the TX FIFO. By enabling this option and reading the TX FIFO until is empty, you can effectively clear the TX FIFO.
>
> Note, however, that "technically" this is no documented in NXP datasheet/user manual, and, therefore, might not be supported in the future.
>
> 2. In that SSP Block Manual, there is also the explanation about the receive timeout interrupt: "the receive interrupt is asserted when the receiver FIFO is not empty and the PrimeCell SSP has remainded idle for a fixed 32-bit period"
>
> Basically, if enabled, you'll get an interrupt every 4 bytes (if you haven't read the data).
>
> In our application we decided to disable this interrupt, and just work with the RX FIFO receive interrupt only.
>
> SSP as slave always have to be carefully designed, so that there is enough time in the ISR to fill the TX FIFO before the next byte of data arrives from the master. The advantage of this SSP is the FIFO, which allow you receive interrupts every 4 bytes, instead of every byte, and have time to set the data for the next transaction.
>
> One solution to communicate Master-Slave is to have fixed-size transactions. In this case every transaction is, let's say, 30 bytes.
>
> Another solution could be to have a two-stage transaction: first stage transmits two bytes (command byte and size for next transaction). Second stage transmit the ammount of bytes setup in the first transaction.
> Regards,
>
> Alex.
>
> --- In l..., Herbert Demmel wrote:
>
>> Hi,
>>
>> when switching an lpc2000 design with a SPI slave to a lpc24xx I used
>> the second set of MISO0 / MOSI0 / SSEL0 / SCK0 pins on P2[xx] expecting
>> to be able to run my existing SPI code via these port pins. After
>> investigating several hours into "why doesn't it work anymore" I found
>> out that the SPI clock SCK (not SCK0) is available on P0[15] only, so
>> when using P2[xx] SSP0 must be used (thank you NXP for laying this
>> snare, life would be too boring otherwise) to run my SPI code.
>>
>> So I tried to modify the code accordingly, but I'm stuck on two issues:
>>
>> a) How can I empty the TX FIFO of SSP0 to ensure that I'm in a initial
>> state ? I could not find any possibilty in the spec to clear the TX FIFO.
>> b) Bit RTIM in SSP0IMSC must be set to get an interrupt when data has
>> been clocked in: The manual says 'A Receive Timeout occurs when the Rx
>> FIFO is not empty, and no has not been read for a "timeout period".' -
>> so what is a "timeout period", resp. when do I get the interrupt after
>> the first byte has been clocked in ?
>>
>> Especially b) makes me a lot of headache:
>> The SPI protocol I need to interprete is as follows: The master sends a
>> unique introducer, a command byte (e.g. read or write) and the length to
>> be read / written. When reading from my lpc24xx device the master
>> assumes the first byte after the length byte is to be ignored but
>> afterwards valid data must be available. So how can I ensure that I put
>> data into the TX FIFO at the correct moment ???
>>
>> Thanks for your help & suggestions in advance.
>>
>> Best regards
>> Herbert
>>
>>
>
