Strange behavior when configuring GPIOc, Pin 1 as an output

[anonymous.8]

microcontroller: stm32h753VI

ST HAL version: STM32Cube_FW_H7_V1.3.0, from download en.stm32cubeh7.zip

         patched from download en.patch_cubeh7.zip [package.xml says (FW.H7.1.3.2)]

Toolchain: IAR Embedded Workbench, version 8.4 using I-Jet probe in SWD mode

hardware: custom

PH0/OSC_IN,PH0/OSC_OUT = 25MHz

PC14/OSC32_IN, PC15/OSC32_OUT = 32.768KkHz

There are (4) GPIO lines between the 753 and another processor:

Pin 15 [PC0] GPIOC, Pin 0 INPUT to 753

Pin 16 [PC1] GPIOC, Pin 1 OUTPUT

Pin 63 [PC6] GPIOC, Pin 6    INPUT to 753

Pin 64 [PC7] GPIOC, Pin 7    INPUT to 753

Problem Description:

Configuring GPIOC, Pin1 as an output causes the microcontroller to executing code outside of the program when executing the following line inside ST HAL:

stm32h7xx_hal_gpio.c(229)

/* Configure IO Direction mode (Input, Output, Alternate or Analog) */

GPIOx->MODER = temp;

The assembly language for this statement:

 LDR R0, [SP] - instruction completes ok

 STR R0, [R4] - instruction causes the execution to jump to 0x1ff0'9abc

This address is outside of the software.

Strangely I can successfully configure Pin 0, 6, or 7 as an output, but not Pin 1...

I can configure Pins 0, 6, 7 as inputs and see the signals change correctly.

Code that reproduces the problem (100% reproduction sequence):

int main(void)

{

 GPIO_InitTypeDef init;

 HAL_Init();

 SystemClock_Config();

 memset(&init, 0, sizeof(init));

 __GPIOC_CLK_DISABLE();

 HAL_GPIO_DeInit(GPIOC, GPIO_PIN_1); 

 __GPIOC_CLK_ENABLE();

 init.Pin = GPIO_PIN_1;

 init.Mode = GPIO_MODE_OUTPUT_PP;

 init.Pull = GPIO_NOPULL;

 init.Speed = GPIO_SPEED_FREQ_VERY_HIGH;

 HAL_GPIO_Init(GPIOC, &init);

 while (1)

 {

  ;

 }

}

/* stolen from STm32h753xi-EVAL board example code */

static void SystemClock_Config(void)

{

 RCC_ClkInitTypeDef RCC_ClkInitStruct;

 RCC_OscInitTypeDef RCC_OscInitStruct;

 HAL_StatusTypeDef ret = HAL_OK;

 /*!< Supply configuration update enable */

 MODIFY_REG(PWR->CR3, PWR_CR3_SCUEN, 0);

 /* The voltage scaling allows optimizing the power consumption when the device is

   clocked below the maximum system frequency, to update the voltage scaling value

   regarding system frequency refer to product datasheet. */

 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

 while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}

 /* Enable HSE Oscillator and activate PLL with HSE as source */

 RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;

 RCC_OscInitStruct.HSEState = RCC_HSE_ON;

 RCC_OscInitStruct.HSIState = RCC_HSI_OFF;

 RCC_OscInitStruct.CSIState = RCC_CSI_OFF;

 RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

 RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

 RCC_OscInitStruct.PLL.PLLM = 5;

 RCC_OscInitStruct.PLL.PLLN = 160;

 RCC_OscInitStruct.PLL.PLLP = 2;

 RCC_OscInitStruct.PLL.PLLR = 2;

 RCC_OscInitStruct.PLL.PLLQ = 4;

 RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE;

 RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_2;

 ret = HAL_RCC_OscConfig(&RCC_OscInitStruct);

 if(ret != HAL_OK)

 {

  Error_Handler();

 }

/* Select PLL as system clock source and configure bus clocks dividers */

 RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_D1PCLK1 | RCC_CLOCKTYPE_PCLK1 | \

                 RCC_CLOCKTYPE_PCLK2 | RCC_CLOCKTYPE_D3PCLK1);

 RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

 RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;

 RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV2;

 RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV2;

 RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV2;

 RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV2;

 RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV2;

 ret = HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_4);

 if(ret != HAL_OK)

 {

  Error_Handler();

 }

}

[Tesla DeLorean]

Very odd. The address looks to be the System ROM, which might suggest some sort of FAULT condition, and the SCB->VTOR pointing to the wrong memory space.

Check state of BOOT0 pin

Value in R4 what?

Clearing of auto variables strongly recommended.

 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

 RCC_OscInitTypeDef RCC_OscInitStruct= {0};

[waclawek.jan]

What's connected to that pin? Doesn't it fight when turned to output?

Probably not the reason for the problem, but I wonder what is this supposed to do

 __GPIOC_CLK_DISABLE();

 HAL_GPIO_DeInit(GPIOC, GPIO_PIN_1); 

 __GPIOC_CLK_ENABLE();

JW

[anonymous.8]

The answer turned out to be an unexpected reset coming from the other microcontroller in the system.

When the 753 register was written, the output became active, and the other microcontroller ended up resetting the 753 in short order...

My guess is that because the 753 was in the middle of a SWD debugging session on the JTAG port the STM32 System Memory Boot code was executed, but ended up in a loop at / near 0x1ff0'9abc. I can understand that the STM factory boot code probably didn't like the state it found itself in...

Pressing [BREAK] on the IAR embedded workbench debugger caused it to get a hold of the cpu, breaking it's execution in a loop around 0x1ff0'9abc.

Not sure why the STM32 System Memory Boot code ended up in that place instead of completing the reset and boot,

or what that loop is about near 0x11f0'9abc

but, of course this is a very unusual situation and it's very reasonable(maybe even correct) that it gets "stuck"...

Thank you both for answering.

Mark