AnsweredAssumed Answered

STM32F767ZG : Runaway debug caused by initializing PortE, Pin 1...

Question asked by Donald Bosley on Aug 18, 2017
Latest reply on Aug 18, 2017 by waclawek.jan

So I've had some recent lovely runaway debug sessions on a self-spun board with the STM32F767ZG. I have three of the boards, and they consistently exercise this behavior despite modifying / adding larger reservoir caps, triple checking other settings, layout and values. I think it's either an errata or something in the Cube Driver that's generating the code - although it's odd because the software works for every other pin in this design without issue.

 

I should add, I had the same thing happen with St-Link, J-Link Plus, both tested under different driver versions and servers on three different IDE's (Atollic, Eclipse MCU, and Segger Embedded Studio) - so it isn't a GDB server issue or something along those lines. 

 

So, when initializing the FMC controller, the debug session would run away when it got to initializing Port E. I narrowed it down to setting MODER bit for Pin 1. Removing pin 1, code runs fine, however I don't have a nibble control as a result.... 

So for HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

THIS FAILS --> /* GPIO_InitStruct.Pin = GPIO_PIN_7|GPIO_PIN_8|GPIO_PIN_9|GPIO_PIN_10
|GPIO_PIN_11|GPIO_PIN_12|GPIO_PIN_13|GPIO_PIN_14
|GPIO_PIN_15|GPIO_PIN_0|GPIO_PIN_1; */

 

THIS WORKS ---> GPIO_InitStruct.Pin = GPIO_PIN_7|GPIO_PIN_8|GPIO_PIN_9|GPIO_PIN_10
|GPIO_PIN_11|GPIO_PIN_12|GPIO_PIN_13|GPIO_PIN_14
|GPIO_PIN_15|GPIO_PIN_0;

 

And then once the port is initialized, I added this quick and dirty to the cube generated driver and it works : 
/* MANUALLLY ADDING THE CODE FOR THE PIN 1.... */
GPIOE->AFR[0] |= 0b110000;
GPIOE->MODER |= 0b1000;
GPIOE->OSPEEDR |= 0b1100;

 

I'm trying to understand why this works outside of the HAL function, but in essence the same thing inside of the HAL function does not. If anyone can shed light, please let me know.

Outcomes