SPI Continuous transfer

[mikemillernow]

Posted on March 20, 2014 at 22:35

All,

I searched the forum but I didn't see any specific answers on this.

I am getting  the SPI peripheral setup and tested on my STM32F05*.

1.) Starting off I have the following configuration:

SPI_InitStruct.SPI_NSS = SPI_NSS_Hard;

SPI_NSSPulseModeCmd(SPI1,ENABLE );   // only way that I could get the cs to work

SSM (software slave management) = 0;

SSI (internal slave select) = 0;

SSOE (SS output enable) = 0;

I see the chip select line cycling from high-low-high for each byte. Looks good.

This is fine but there are times when I want to send more than 1 byte at a time and not

have the chip select line go high until all the bytes have been sent.

2.) I then tried to enable (SPE = 1) /disable (SPE=0) the SPI that was supposed to drive the CS high or low. This didn't work for me.

3.) I then tried to manually toggle the chip select line by using it as a regular gpio line and I am getting a mode fault.  Set low before sending out the data and then setting the pin high after the data has been sent out.

Any ideas on this?

Thanks.

-Mike

[mikemillernow]

Posted on March 20, 2014 at 23:07

Here is an update:

SSM = 0

SSI = 0

SSOE =1

When I used SPI_Cmd(SPI1, ENABLE); or SPI_Cmd(SPI1, DISABLE); this toggle my chip select pin.

But when I do the SPI_Cmd(SPI1, DISABLE); to set the CS pin back high there is a long and slow rise time. Not a quick transition as before with the NSS pulse management.

I have attached a screen shot of the scope showing the long chip select transition. Click on the upper right where it says ''

/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=39567&RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/SPI%20Continuous%20transfer

''.

I have a 100k pullup from the CS line to the 3.3V rail.

Ideas?

Thanks.

-Mike

________________

Attachments :

SPI_DEBUG.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Ry&d=%2Fa%2F0X0000000bgS%2FAldu1ckRKbF5DO74BHu4ur1uEdfwxnkGJKToF8gyvLg&asPdf=false

[mikemillernow]

Posted on March 21, 2014 at 16:48

Anyone have any ideas on this?

Thanks.

-Mike

[stm322399]

Posted on March 21, 2014 at 17:28

I did not catch exactly the various conditions of your tests, but here is what I can say:

1) If you want the SPI HW to manage CS pin for multiple bytes, don't let the TX stream stop, feed bytes as fast as possible (DMA is probably the best solution). This is not something I read from the manual, just a guess.

2) regarding the slow transition to high, it just means that the PIN is not driven by the CPU, the voltage slowly grows, charging capacities through the pull-up resistor (100k induces a small current). I had a similar issues with CAN port that I solved thank to a Push-Pull configuration of the GPIO (apparently GPIO P-P config does matter even for alternate functions).

[mikemillernow]

Posted on March 21, 2014 at 18:57

1.) For my chip select line I am using PA15:

Here is the configuration:

  /* Configure PA15 ((chip select) in alternate function mode  */

  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_15;

  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;;

  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;

  GPIO_Init(GPIOA, &GPIO_InitStructure);

2.) At this point I am not sure if I should go the software or hardware management direction for NSS in the case of a continuous stream of SPI data. I will only be using this i master mode.

3.) When I look at the block diagram for the hardware/software slave select management the only output for the NSS pin looks to be when using the hardware management.

From the datasheet:

''NSS output enable (SSM=0,SSOE = 1): this configuration is only used when the

 

MCU is set as master. The NSS pin is managed by the hardware. The NSS signal

 

is driven low as soon as the SPI is enabled in master mode (SPE=1), and is kept

 

low until the SPI is disabled (SPE =0). A pulse can be generated between

 

continuous communications if NSS pulse mode is activated (NSSP=1). The SPI

 

cannot work in multimaster configuration with this NSS setting.''

Again when I enable the SPI, the NSS pin has a nice sharp transition to ground.  When disabled looking for a sharp pop back high - but I get this long slow transition up.

If I need to manage this pin with software I am willing to do this but when I read up on the software NSS management it seems to be referring to managing this internally and the external pins is free for other application uses?  This doesn't make sense to me because I am trying to drive this pin so that I can communicate with an external device.

Should I just configured this pin as a regular GPIO pin and manually goggle between transfers?

-Mike

[stm322399]

Posted on March 21, 2014 at 19:21

Well, I suppose that when SPI is turned off (SPE=0), the output of the IO is released, leaving the line in Hi-Z, hence the slow transition through your external pull-up.

Anyway, I don't see any reason why you won't be able to manage NSS by yourself using GPIO controls (NSS is simply a generic output). One major drawback of that solution is that it forces you to be very careful of the moment you de-assert NSS (turning it high). You have to make sure the SPI transfer is done (normally the BSY status flag is there for that purpose). On the other side, one advantage is that you are free to choose the pin you like for that 'software NSS', you don't bother anymore to check the AF mappings.

[mikemillernow]

Posted on March 21, 2014 at 21:18

I am going to give it one more shot with the hardware management making sure that

SSM = 0 (software slave management disabled)

and

SSOE = 1; (SS output is enabled in master mode and when the SPI interface is enabled.)

If this doesn't work I will try the ''manual'' toggle of the gpio line.

Here I go!

-Mike