SSP port problem in SPI mode

[lpcware]

Content originally posted in LPCWare by zaalzaalak on Fri Dec 30 02:44:07 MST 2011
Hello

I read the SSP0 in SPI mode , the datasheet says that after each byte(if my data size is 8 bits) is send ,the SSEL must return high,this is bad because we need to send several bytes in each transfer and after send all bytes we can return SSEL to high.(for example AD77xx ADCs from ADI need several bytes for communication and when we return SSEL to high it will reset the SPI interface in AD77xx).

How can I send several bytes without returning SSEL to high after each byte?


please check and respond this bug.

[lpcware]

Content originally posted in LPCWare by IanB on Sat May 21 00:34:13 MST 2016
Having to change the MCU seems a bit melodramatic to me!

I agree with Ex-Zero here - especially as the AD7792 is further complicated by having the DOUT/RDY pin as part of the interface - A lot easier to implement the SSEL in software as a GPIO pin.

As some of the data are 2 bytes long, it is easier to set the SSP interface to 16 bits for that data, so that it can be read in one operation.

The SSEL function isn't too clever in the LPC15xx either - it all goes horribly wrong if there is an interrupt between two SSP reads, so, again, it is far easier to implement the SSELs as GPIO.

[lpcware]

Content originally posted in LPCWare by xxtigerxx on Thu May 07 22:48:02 MST 2015
I faced the same problem as zaalzaalak, yesterday.

I do not understand NXP makes a new mcu from LPC17XX the LPC12XX and the makes the spi worst  than LPC17XX.

The manual and the datsheet does not clear this issue. All other mcus i have worked does not have this issue.

I am in a middle of a project and now i must change the mcu.

[lpcware]

Content originally posted in LPCWare by zaalzaalak on Tue Jan 10 03:39:40 MST 2012
It seems SSP design from ARM company does not compatible with SPI protocols of ICs that are available and in real ARM SSP have bug.


Real ICs with SPI need multiple bytes for one transaction!

[lpcware]

Content originally posted in LPCWare by zaalzaalak on Wed Jan 04 14:12:49 MST 2012
Thanks for technical support from NXP.

I will test this method on AD7792 in next 2 weeks and I will report the results.

By this method it seems we can solve the problem but I suggest add SPI interface instead of SSP because many many ICs have SPI interface.Other features of SSP(except SPI mode) is useless for many users and they can use bit bang for that application.


I worked with SPI interface of LPC1768 and works nice,I suggest use that SPI for LPC11,12,13.

[lpcware]

Content originally posted in LPCWare by wellsk on Wed Jan 04 11:20:30 MST 2012
Hi,

I'll try to answer this one, as I've used with SSP a bit in the past. The SSP, when in SPI mode, has always toggled CS on a per byte basis, at least for mode 0 transfers. This goes back to other devices in the NXP line that use the ARM SSP Primecell. I agree that this might be a little odd, but the operation of the CS is specified to work like that in the ARM SSP TRM.
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0194g/DDI0194G_ssp_pl022_r1p3_trm.pdf (Even other manufacturer's devices that use SSP have the 1-byte CS toggle condition).

In every design I've worked with that has SPI slave devices controlled via the SSP in SPI master mode, each SPI device was controlled by a general purpose output to toggle it's CS state based on the CS condition needed for the full transfer. On systems where multiple slave devices were attached to the master (each with a unique controlling GPIO), the active CS states were not necessarily low, so it was possible that one SPI device needed an active high state for transfer while another needed an active low state.

>scu_pinmux(0x3,6,MD_PLN_FAST,FUNC2);    // P3.6 connected to nCS                func2=SSP0 SSEL0
It looks like the SPI master example in the lpc4300 software bundle uses the SSP SSEL signal instead of a GPIO. This will toggle CS on each byte for mode 0. A loopback test will work fine, but connecting to a slave device that needs a CS active state maintained across the entire transfer won't work. Note the driver doesn't really need to know about what is actually hooked up to the CS pin of the SPI slave device.

To make the SSEL signal a GPIO, this mux needs to be reset to it's usable GPIO and then control the GPIO state for the selected device at the start and end of the transfer. ie, setting the proper GPIO state for the CS pin prior to calling the SSP_ReadWrite() function and then restoring the CS pin to inactive state after the SSP_ReadWrite() function returns. You don't necessarily have to use SSEL to control the CS state for the slave - any spare GPIO should work.

For example, in Linux, a callback is used to set the GPIO state based on the device similar to below.
(http://git.lpclinux.com/?p=linux-2.6.27.8-lpc32xx.git;a=blob;f=drivers/spi/spi_lpc32xx.c;h=5b7d4edbe...)

<code>
285                 /* Assert selected chip select */
286                 if (cs_change)
287                 {
288                         lpc32xx_cs_set_state(spi, spi->chip_select, 1, cs_delay);
289                 }
290                 cs_change = t->cs_change;

....Do SSP transfer...

Once the entire transfer is complete, the CS is de-asserted for the device.
396                 lpc32xx_cs_set_state(spi, spi->chip_select, 0, cs_delay);
</code>

Another example is the LPC32xx SSP interface in SPI mode connected to a SPI EEPROM. In this case, the driver has no knowledge of the CS used to control to SPI slave it's talking to. The CS is set active prior to the SSP write and read calls and is then de-asserted once complete. That code is located here:
http://sw.lpcware.com/?p=lpc3xxx_cdl.git&a=blob&h=73bdae3177af70f7176344bb0c36642cfba51de3&hb=79eb5b...

<code>
  /* Asset chip select */
  GPIO->p3_outp_clr = P3_STATE_GPIO(5);

  ssp_write(sspid, out, bytes);
  while (rbytes < bytes)
  {
    rbytes += ssp_read(sspid, &in [rbytes], 1);
  }

  /* De-assert chip select */
  GPIO->p3_outp_set = P3_STATE_GPIO(5);
</code>

I know this isn't an excuse for some additional logic for better control of CS, but this method works quite well.

Kevin

[lpcware]

Content originally posted in LPCWare by zaalzaalak on Wed Jan 04 03:56:17 MST 2012
No answer from NXP team?

[lpcware]

Content originally posted in LPCWare by zaalzaalak on Fri Dec 30 11:07:35 MST 2011
This is very BIG BUG in design of NXP LPC1100,LPC1200 and LPC1300 series because the SSP interface is nothing ,SSP interface does not support very popular SPI interface .


SSP is useless and have no SPI mode in practice,

I must use bit bang for software SPI emulation and SSP peripheral can not be used for SPI.


NXP should solve this BUG.

I used LPC1768 with SPI interface and LPC1700 support SPI very nice.


Please report this to LPC team.

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Fri Dec 30 06:18:14 MST 2011
If SSEL isn't able to do what you want, a common approach is to change pin function to GPIO and switch your own 'chip select' in your program.