SPI 4-6 on STM32F767 Nucleo-144

[JSchn.1]

I'm using STM32F767 Nucleo-144 and am trying to get the SPI 4,5 and 6 working. SPI1-3 work fine. On the Nucleo Board manual I don't find any reference to SPI4-6 at all. So it is possible that those SPI aren't working on the Nucleo Board for some reason? I already created a post in the chibiOS Forum here: http://www.chibios.com/forum/viewtopic.php?f=35&t=5409&p=37247#p37247

I Just wanted to check if it's maybe a hardware issue.

[waclawek.jan]

> So it is possible that those SPI aren't working on the Nucleo Board for some reason?

No.

Except of course if no related pins would be present on the given mcu package, or if all those pins would be connected to some dedicated resource on that board in a disconnectable way. I'm not going to check, but I doubt it's the case.

Check the AF assignment to pins in the STM32F767 Datasheet.

JW

[JSchn.1]

Yes I already checked the AF Pins and configured accordingly (see my chibiOS forum thread). But to no avail, I will try to test a basic CubeMX application to see if it works there.

[waclawek.jan]

Elaborate on "not working".

Read out the relevant SPI and GPIO registers content and check/post.

JW

[JSchn.1]

They simply don't show any output.

Pin Configuration:

        /*
    * SPID5 I/O pins setup.(Overwriting board.h configurations)
    */
    palSetPadMode(GPIOF, 7,
                  PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_HIGHEST);    /* New SCK */
    palSetPadMode(GPIOF, 8,
                  PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_HIGHEST);    /* New MISO*/
    palSetPadMode(GPIOF, 9,
                  PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_HIGHEST);    /* New MOSI*/
    palSetPadMode(GPIOF, 6,
                  PAL_MODE_OUTPUT_PUSHPULL | PAL_STM32_OSPEED_HIGHEST); /* New CS*/

Bus Configuration

const SPIConfig hs_spicfg = {
        false,
        NULL,
        GPIOF,
        6,
        SPI_CR1_BR_0,
        SPI_CR2_DS_2 | SPI_CR2_DS_1 | SPI_CR2_DS_0
};
 

[JSchn.1]

Creating a basic STMCubeMX application for SPI5 produces some results. Must be an issue with my configuration above or the chibiOS hal driver.

Here are the SPI status registers from the debugger:

CR1 = {volatile uint32_t} 8 [0x8]
CR2 = {volatile uint32_t} 5895 [0x1707]
SR = {volatile uint32_t} 34 [0x22]
DR = {volatile uint32_t} 0 [0x0]
CRCPR = {volatile uint32_t} 7 [0x7]
RXCRCR = {volatile uint32_t} 0 [0x0]
TXCRCR = {volatile uint32_t} 0 [0x0]
I2SCFGR = {volatile uint32_t} 0 [0x0]
I2SPR = {volatile uint32_t} 0 [0x0]

[berendi]

Compare it with a working one. Are there any differences?

What do the GPIO MODER and AFR registers contain for each case?

[waclawek.jan]

> CR1 = {volatile uint32_t} 8 [0x8]

MSTR nor SPE are set, so why would that generate any output?

> SR = {volatile uint32_t} 34 [0x22]

MODF is set, so this is the case of master being turned to slave through NSS. Review NSS settings in RM.

JW

[JSchn.1]

Compared the registers for and and 5, exactly the same:

CR1 = {volatile uint32_t} 108 [0x6c]
CR2 = {volatile uint32_t} 5895 [0x1707]

Currently trying to figure out how to get the GPIO registers from chibios.

[JSchn.1 · Accepted solution]

Rechecked my DMA Config. DMA Channel 3 was used for 1 and 5. That solved it 🙂