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

[Donald Bosley]

Posted on August 18, 2017 at 02:48

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.

#stm32f767zg #stmcubef7 #stm32f7 #gpio

[Tesla DeLorean]

Posted on August 18, 2017 at 03:39

GPIOE->AFR[0] |= 0b110000;

AF3? That's LPTIM1, assuming a typo

GPIOE->AFR[0] |=0xC0; // or 0b11000000 FMC = AF12, also assumes AF0 initially

Do you do this before the FMC has it's clock enabled, initialized?

Watch for EXTI on other pins.

Short of some trace, hard to think why it would go pear-shaped.

[Donald Bosley]

Posted on August 18, 2017 at 05:59

...AF3? That's LPTIM1, assuming a typo... 

No type-o, directly copied and functional. I don't see how I could have verified a read of randomly written numbers across every memory address of the two 32 MB RAMs connected to the FMC if this bitfield were set wrong. I've also halted and manually compared the numbers in the randomly generated arrays against those in the RAM from a memory browser, so it's not a case of an improper read coupled with an improper write that allows them to match.

Do you do this before the FMC has it's clock enabled, initialized?

Cube generated Hal Driver enables FMC clock before GPIOs are set, and GPIO_Init enables GPIO clocks before FMC_Init is called, so in short, yes.

Short of some trace, hard to think why it would go pear-shaped.

Yeah, it doesn't make a whole lot of sense, why it works outside the driver but not within. And the registers are set pin by pin in the driver so it's not like a bulk mask vs a single bit-field. 

Thanks.

[waclawek.jan]

Posted on August 18, 2017 at 10:33

So I've had some recent lovely runaway debug sessions

What is it?

JW