GPIO pin does not stay high

[BKölz.1]

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 solution]

> 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]

> 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.

[BKölz.1]

Sorry for the logic error in the above code snippet. That was a remnant of me trying all kinds of things to get the signal to behave in the way I want.

In the meanwhile I think I found my problem: It seems that in Keil's debug mode I have to set the breakpoint in the line after the assignment I am interested in to actually view the value the variable is holding when the assignment is completed. So instead of setting the breakpoints in the check status lines, I set them one row below . Now the value is 1 after I read from a SET pin and 0 after I read from a RESET pin.

Anyway, thanks for your answers. I will now go hide under some rock.

[turboscrew]

" I will now go hide under some rock." :D :D

Don't. Those things can happen to anyone. :)