GPIO pin does not stay high

Question

Hi everyone,I am trying to use CubeMX and the HAL library to get two STM32F411E discovery boards to communicate with each other via SPI. In a first step I am simply trying to configure the master correctly. I want to drive the NSS pin of the slave with a standard GPIO pin from the master and to this end have the following code in the while loop: while (1) {      slaveStatus = HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_4);            // check status 1      HAL_GPIO_WritePin(GPIOB, GPIO_PIN_4, GPIO_PIN_SET);         // activate slave      slaveStatus = HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_4);            // check status 2      HAL_GPIO_WritePin(GPIOB, GPIO_PIN_4, GPIO_PIN_RESET);    // deactivate slave      slaveStatus = HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_4);            // check status 3 }slaveStatus is set as a global variable so I can monitor its value with breakpoints in the Keil debugger. During the first run through the while loop, everything is fine. The GPIO pin is at first high for check status 1, then low during check status 2, and at the end of the loop high again for check status 3. However, for all subsequent loops slaveStatus will always be 0 for check status 1.Looking around on different forums for an afternoon I figured that sometimes problems like these are caused because no pull-up / pull-down is configured, but I am fairly certain that this is not my problem. I have tried every possible combination of the GPIO configuration for this pin and even switched to another pin, to no avail. It looks like the pin is brought low between each cycle, but I have no clue why. Any suggestions as to what I can try to remedy this situation would be much appreciated.

berendi · Accepted Answer

> During the first run through the while loop, everything is fine. The GPIO pin is at first high for check status 1, then low during check status 2, and at the end of the loop high again for check status 3.

No, that's not fine.

When entering the loop at check status 1, the pin state would of course depend on whatever state it was left by code executed before. If it was not touched before entering the loop, the pin status should be low.

The pin is set to high before check status 2, so it should read back 1 (high).

The pin is reset before check status 3, so at this point it shgould read back 0.

Then check status 3 is immediately followed by check status 1, so the result should be the same.

Pullups have no effect when the pin is configured as push-pull output.

Also note that peripherals are usually activated on a low level signal, and deactivated on a high level signal. Check the datasheet of the slave to be sure.

TDK · Answer

> The GPIO pin is at first high for check status 1, then low during check status 2, and at the end of the loop high again for check status 3.This is not consistent with the code you posted. Are you sure? Check status 2 should be high since the pin is SET.> However, for all subsequent loops slaveStatus will always be 0 for check status 1.This is consistent with the code you posted. RESET state is 0.Note the the SPI CS pin is typically active low. So reading of 0 would enable the slave.Edit: this is the same as berendi's post. I missed seeing that before I posted.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded