Weird behavior at HAL_GPIO function. Why the microcontroller is unable to set some pins after execute HAL code assertion statement?

[genisuvi]

I was running and debugging a part of my application on a stm32F207zg microcontroller.

Microcontroller is on a custom PCB that is in validation process.

This part of application has to set or clear 16 gpios configured as output.

If they are initialized to be "on", outputs start with "on" state correctly. So, the whole output port can be written with "high logic level". If LEDs are connected on there, they turn on.

In other part of my code that I'm using to play with output operations for testing purposes, a function is writing high level state at whole GPIO output port (x16 pins) once again. But the weird behavior comes here: pin4, pin 5 and pin16 don't set their values.

I was debugging HAL_GPIO_WritePin function.

Remembering how does HAL set the value I share the code from HAL_GPIO lib:

* @param GPIOx where x can be (A..I) to select the GPIO peripheral for all STM32F2XX devices
 
 * @param GPIO_Pin specifies the port bit to be written.
 
 *     This parameter can be one of GPIO_PIN_x where x can be (0..15).
 
 * @param PinState specifies the value to be written to the selected bit.
 
 *     This parameter can be one of the GPIO_PinState enum values:
 
 *      @arg GPIO_PIN_RESET: to clear the port pin
 
 *      @arg GPIO_PIN_SET: to set the port pin
 
void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState)
 
{
 
 /* Check the parameters */
 
 assert_param(IS_GPIO_PIN(GPIO_Pin));
 
 assert_param(IS_GPIO_PIN_ACTION(PinState));
 
 
 
 if(PinState != GPIO_PIN_RESET)
 
 {
 
  GPIOx->BSRR = GPIO_Pin;
 
 }
 
 else
 
 {
 
  GPIOx->BSRR = (uint32_t)GPIO_Pin << 16U;
 
 }
 
}

Thread is running by the correct way, the same when the other pins are puting '1' on there. But this part of the code where pin is set..

if(PinState != GPIO_PIN_RESET)
 
 {
 
  GPIOx->BSRR = GPIO_Pin;
 
 }
 

..seems not to work for the indicated pins. Microcontroller actually puts '0' there.

So I was looking for suspicious thread paths, even unespected var values while debugging.

And I found this situation even when output pin is being updated correctly with "high" level:

 

I can't see any value at BSRR field even after being updated. Despite of this, writing '1' is working for this GPIO_pin writing.

When watching the same window after the same thread actions for a set pin failure this can be seen:

 

I'm unable to apreciate too much differences between previous image and that one.

Does anyone see any relevant value that could explain why after the statement execution microcontroller is unable to put 3.3V on this pin?

The crazy data is that doing this during initialization:

{
...
HAL_GPIO_WritePin(gpio_outputs[i].tPort, gpio_outputs[i].tPin, GPIO_PIN_SET);
}

This '1' writing is working for all the pins that I have mentioned.

Any help, any comment, etc.. will be helpful. Thanks in advance.

[KnarfB]

BSRR is write-only. So the value the debugger is displaying is irrelevant. IDR shows the pin state as measured by the input part of the GPIO.

hth

KnarfB

[waclawek.jan · Accepted solution]

Please set your debugger to display in hexadecimal. Decimal display of registers is mostly useless.

Storing 2048=0x0800 into BSRR means that you are trying to set pin 11 of given port, and indeed, ODR=0x0F00 which means pin 11 is set. However, you've set MODER to 0x54150000, which means that pin 11 is set to 0b00 = Input.

JW

[genisuvi]

Thanks a lot for your answer and your observations. I will answer soon to your comment.

It would be a sign of overwriting the pin mode field of those pins at some point of the code, after being them initialized.

But I have just checked this issue and you are right. The content of the MODER register is configuring the two pins that dosn't work correctly after initialization.

I have found that I was overwriting this register bits in other part of the code, after output initialization.

Your comments and your observations has been very helpful.