Open MichelRottleuthner opened 5 years ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.
Not stale! SPI tests incoming.
Hi all!, I reproduce this error with a STM32F303CCT6 board.
I dont know if I'm forgotting something, but I resolved the problem adding a PullDown to SCLK pin with: GPIOB->PUPDR |= GPIO_PUPDR_PUPDR13_1; //PB13 = SCLK con pulldown GPIOB->PUPDR &= ~(GPIO_PUPDR_PUPDR13_0);
Maybe https://github.com/RIOT-OS/RIOT/pull/19431 fixed the issue?
Description
This issue is meant to keep track of the problems discovered when testing #7354. For more details see comments there. On some stm32 platforms the RIOT SPI driver generates faulty output on the SPI pins. For now the problem could be reproduced on the following boards: nucleo-f446ze, nucleo-l073rz and nucleo-l476rg (no other STM32 were tested until now).
Steps to reproduce the issue
Connect a logic analyzer to your spi pins, use tests/periph_spi and try the following cases: 1)
init 0 0 0 3 14
clock state is NOT reset to zero properly after transmission.2)
init 0 0 1 3 14
clock state is NOT reset to zero properly after transmission.3)
init 0 0 2 3 14
clock state is NOT reset to zero properly after transmission.4)
init 0 0 3 3 14
clock state is reset to zero properly after transmission.5)
init 0 0 4 3 14
clock state is reset to zero properly after transmission.Expected results
No additional clock cycles before/after sending data, clock returns to idle state after transmission.
Actual results
A) not returning to zero, using config (1) from above: B) returning to zero, using config (5) from above:
C) If you start another transmission after (A), you get this:
copied from #7354(comment):
Versions
The last version this was reproduced with is 3c9eb94 (between 2018.04 and 2018.07). Needs to be confirmed with current master again.