spiPolledExchange difference STM32F4xx, STM32F7xx Topic is solved
Posted: Wed Jan 09, 2019 1:10 pm
Hi,
I'm using spiPolledExchange to read data from an external ADC, one 16 bit sample at a time. The conversion is triggered using PWM (@109375 sps) and then I collect the result once I detect BUSY has cleared. I use SPI1 with PB3/4/5 pins.
I have this working using STM32F4 (tested with STM32F407-DISC board, Olimex STM32-E407 and NUCLEO-F429ZG). I originally developed this using ChibiOS 3.0.4, but have now upgraded to 18.2.1, and this works quite well.
I have also attempted to port this to STM32F7 (testing with NUCLEO-F746ZG and NUCLEO-F767ZI), but the data always comes back as zeros. This is the same code and hardware attached to the board as I used with the STM32F429 processor, so it's not a hardware problem. There is minimal code change to support the STM32F7 processor, mainly the config has flags SPI_CR2_DS_0 | SPI_CR2_DS_1 | SPI_CR2_DS_2 | SPI_CR2_DS_3
instead of SPI_CR1_DFF (as it's using the SPIv2 code rather than SPIv1).
I traced the lines, and the difference I see is that the SPI clock is always driving the pin (from spiStart to spiStop), whereas with the F4 processors, the SPI clock starts and stops driving the pin as I issue the spiPolledExchange call. This means that in the F7 case, the read is triggered by hardware (the clock pin) before I try to read the data, so when I attempt to read, I just get the zero values (as there is no more data at this stage).
I assume it's a change between the SPIv1 and SPIv2 code, but I've not worked out what the difference is yet, and I don't know if the F4 (clock driving pin when needed) or the F7 (clock always driving pin) method is the one expected. I'd assumed it was the F4 method - which helps as it keeps the crosstalk down while the ADC reads the values.
I'll probably change to circular mode, once I understand my current issue, but I wanted to understand why there is this difference first.
Any help much appreciated.
Mike
I'm using spiPolledExchange to read data from an external ADC, one 16 bit sample at a time. The conversion is triggered using PWM (@109375 sps) and then I collect the result once I detect BUSY has cleared. I use SPI1 with PB3/4/5 pins.
I have this working using STM32F4 (tested with STM32F407-DISC board, Olimex STM32-E407 and NUCLEO-F429ZG). I originally developed this using ChibiOS 3.0.4, but have now upgraded to 18.2.1, and this works quite well.
I have also attempted to port this to STM32F7 (testing with NUCLEO-F746ZG and NUCLEO-F767ZI), but the data always comes back as zeros. This is the same code and hardware attached to the board as I used with the STM32F429 processor, so it's not a hardware problem. There is minimal code change to support the STM32F7 processor, mainly the config has flags SPI_CR2_DS_0 | SPI_CR2_DS_1 | SPI_CR2_DS_2 | SPI_CR2_DS_3
instead of SPI_CR1_DFF (as it's using the SPIv2 code rather than SPIv1).
I traced the lines, and the difference I see is that the SPI clock is always driving the pin (from spiStart to spiStop), whereas with the F4 processors, the SPI clock starts and stops driving the pin as I issue the spiPolledExchange call. This means that in the F7 case, the read is triggered by hardware (the clock pin) before I try to read the data, so when I attempt to read, I just get the zero values (as there is no more data at this stage).
I assume it's a change between the SPIv1 and SPIv2 code, but I've not worked out what the difference is yet, and I don't know if the F4 (clock driving pin when needed) or the F7 (clock always driving pin) method is the one expected. I'd assumed it was the F4 method - which helps as it keeps the crosstalk down while the ADC reads the values.
I'll probably change to circular mode, once I understand my current issue, but I wanted to understand why there is this difference first.
Any help much appreciated.
Mike