Migrating SPI from stm32f4xx(407, 417) to stm32f7xx(746) - please help

[piececakeof]

Posted on January 13, 2016 at 11:43

The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Amel NASRI]

Posted on January 13, 2016 at 15:08

Hi pustobayev.roman,

It seems that you are writing your own functions for GPIOs configuration.

When GPIO is configured as AF, the mode has to be set to ''GPIO_MODE_AF_PP'' instead of ''GPIO_MODE_OUTPUT_PP''.

Please check if this modification resolves your issue.

If not, I recommend you to have a look to the example STM32Cube_FW_F7_V1.3.0\Projects\STM32746G-Discovery\Examples\SPI\SPI_FullDuplex_ComPolling.

You can use it as a start point for your application. 

You may also generate your initialization code based on CubeMX then add the functions you need for processing (HAL_SPI_TransmitReceive...).

-Mayla-

[piececakeof]

Posted on January 14, 2016 at 08:37

Hello, Mayla. Thx for your reply.

my own functions for GPIO initialization is only cover for the standart HAL_GPIO_INIT(), to avoid declaring structures to init them.

Yes, i'm already done it from the example you point to - the same result.

But i think that i found some mistakes in standart libraries, there is it:

HAL_StatusTypeDef HAL_SPI_TransmitReceive ( SPI_HandleTypeDef *hspi,

uint8_t *pTxData, 

uint8_t *pRxData, 

uint16_t Size, 

uint32_t Timeout )

{

/..../

if

((hspi->Init.DataSize > SPI_DATASIZE_8BIT) || (hspi->RxXferCount > 1))

  {

    /* set fiforxthreshold according the reception data length: 16bit */

    CLEAR_BIT(hspi->Instance->CR2, SPI_RXFIFO_THRESHOLD);

  }

  else

  {

    /* set fiforxthreshold according the reception data length: 8bit */

    SET_BIT(hspi->Instance->CR2, 

SPI_RXFIFO_THRESHOLD

);

  }

/..../

there is set the same bit for different FIFO treshold modes.

i think my problem is refer to the FIFO workaround.

and when i poll  for BSY_FLAG against the RXNE_FLAG - program wait some iterations and return the data, but data always = 0;

the problem is similar for the different chips with SPI interface, maybe i can test it if connect MISO and MOSI  between each other - to test the FIFO's?

I dont have an logic analyzer, so i cant show to you full picture about incomming and outcomming data. With the f417 device all i need works fine, there is no FIFO for spi.

[piececakeof]

Posted on January 14, 2016 at 21:52

So, if someone have interest, i'm resolve this problem - 

I have met some mistakes* about initialization and RX\TX procedures of HAL library:

there is wrong FIFO treshold mode - when i use 8(or less) data size - 16bit FIFO treshold are selected and etc.

* - when i fix it, it gonna work as needed, maybe i'm something miss, but have this fact for now.

Sorry for my english, if someone need more details i can give it, Also i can attach the scheme of my board: there is stm32f746igt6, 64Mbytes ddr1, tft slot (18bpp, vs, hs, clk, de, spi), tsc2046(resistive sensor mcu), enc28j60(standalone ethernet mcu), at1248(spi flash), sd card slot(4-bit), HR91110 - rj-45 jack with trafo and leds inside, usb port.

Thx for your attention.

[piececakeof]

Posted on January 14, 2016 at 21:59

And please tell me how i can mark this theme as ''solved''?

[Amel NASRI]

Posted on January 15, 2016 at 15:33

Hi Roman,

I am not sure that the same threshold is used for both 8-bit and 16-bit data length.

In fact, for 16-bit, CLEAR_BIT is called. So FRXTH bit is 0.

However, for 8-bit, SET_BIT is called. So FRXTH bit is 1.

And this is aligned with the specification.

-Mayla-

[piececakeof]

Posted on January 16, 2016 at 07:29

Hi, Mayla. Please sorry me, i was download this libraries NOT from st.com site few month ago, and it was my mistake. The original HAL 1.30 that now avialable is works without any modifications....

Thanks for you'r reading this and have a nice day.