On the STM32L073 Nucleo board, I configured pin A5 as follows:
- GPIO mode (MODER): A5 configured as alternate function (0x02)
- GPIO alternate function mux setting for A5 is 0 (SPI SCK)
- Pull-up enabled on A5 (PUPD5 = 0x01)
- SPI1 peripheral is clocked but SPI is disabled (SPI1->CR1 bit SPE is clear)
Under these conditions, the voltage on pin A5 is driven to 1.76V.
Why 1.76V and not 3.3V (VCC on the Nucleo board)?
If I change the mode from alt function to output (MODE5 = 0x01), and set the output value to 1, pin A5 is driven to 3.25V. If I leave the alt function as 0 (SPI) and enable the SPI controller, the clock swings from 0-3.25V as expected during the transfer. Clearly, the STM32L073 can put >3V on this pin, but the internal pull-up isn't strong enough to get there when the pin is connected to the SPI controller but a SPI transfer is not running. Adding an external 4.7k pull-up to this pin doesn't help -- something much stronger is holding or clamping it.
Note that the STM32F303 does not behave this way: its SPI1 SCK pin can be pulled all the way up to VCC with the internal pull-up.
I checked the errata and there is nothing to indicate that this pin has any known defects. The schematic for the STM32L073 Nucleo board also does not show anything else on this net that could be driving it.
This is causing me problems because I need the SPI SCK to idle high when CPOL=1. I am driving the SPI chip select as a GPIO, and between when the chip select is asserted and the SPI controller is enabled, SCK must remain high or the slave device may detect an edge. Since SCK is stuck at around 1.8V, its logical value at the slave device (VCC=3.3V) cannot be guaranteed to be 0 or 1. I have unsuccessfully tried a couple of workarounds:
- A stronger (4.7k) external pull-up does not help (and may risk damaging something in the STM32 by forcing it to sink more current)
- Driving the pin as an output and switching to alternate function immediately before enabling the SPI transfer causes a glitch on the clock line which could easily be interpreted as a clock edge. (Whatever is driving the pin is strong enough to pull it all the way from 3.3V to 1.8V in the time it takes to change the alt function and enable SPI.)
- Switching the pin mode from GPIO output to SPI alternate function immediately after enabling the SPI transfer causes the first half clock cycle to be too short, and with the possibility of unrelated interrupts, could cause clock cycles to be missed entirely.
Any idea what is going on here?
