SSP port problem in SPI mode

Home » Forums » Microprocessors Forums » lpc13xx
6 replies [Last post]
Fri, 2011-12-30 02:44
zaalzaalak
Offline
Joined: 2011-10-16

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.

0
Your rating: None
Top

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Fri, 2011-12-30 06:18
#1
Zero
Offline
Joined: 2011-07-19

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.

Top
Fri, 2011-12-30 11:07
#2
zaalzaalak
Offline
Joined: 2011-10-16

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.

Top
Wed, 2012-01-04 03:56
#3
zaalzaalak
Offline
Joined: 2011-10-16

No answer from NXP team?

Top
Wed, 2012-01-04 11:20
#4
wellsk's picture
wellsk
Offline
Joined: 2011-05-17

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_p... (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/s...)

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);

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=73bdae3177af70f7176344...

  /* 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);

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

Kevin

Kevin Wells

NXP Semiconductors

Kevin Wells

NXP Semiconductors

Top
Wed, 2012-01-04 14:12
#5
zaalzaalak
Offline
Joined: 2011-10-16

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.

Top
Tue, 2012-01-10 03:39
#6
zaalzaalak
Offline
Joined: 2011-10-16

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!

Top
Copyright ©2013 LPCWare.com
feedback