STM32H725VGT6 not responding even though it's behaving like it's running. Edit: Solved.

[YBCH_.1]

Hi,

I'm working on the FW for STM32H725VGT6 MCU and something strange is happening.

I've created a simple project with cubeIDE (with usart2 and a GPIO to toggle) and the code created and compiled with no issues. After uploading the code with debug mode and running it, everything looks regular and according to the IDE the code is being executed (a test value being increased within the while loop and I can see its value changing in the "watch" window) but actually the MCU is not responding, there's no prints on the UART and the GPIO is not being toggled.

I'm writing the MCU with the STLink of STM32H7 nucleo board.

I'm not new to STM32 MCUs nor to cudeIDE and I never came across such thing.

Also, the boot0 pin is tied to GND.

With the nucleo everything was OK and had no issues.

I remember that the first time I programmed this specific MCU the STM32CubeProgrammer tool send me a message about the option bytes but I don't remember what this message was. There's a chance this issue related to the option bytes?

#STM32H7​ 

[gbm]

Use the debugger to single-step through your code, check the GPIO registers content before and after toggling.

[Karl Yamashita]

Post your code so we can see how you're transmitting on UART and toggling the GPIO.

[YBCH_.1]

#ifdef __GNUC__
#define PUTCHAR_PROTOTYPE int __io_putchar(int ch)
#else
#define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)
#endif /* __GNUC__ */
 
PUTCHAR_PROTOTYPE
{
 HAL_UART_Transmit(&huart2, (uint8_t *)&ch, 1, 50);
 return ch;
}
 
 
int main(void)
{ 
 HAL_Init();
 SystemClock_Config();
 PeriphCommonClock_Config();
 MX_GPIO_Init();
 MX_USART2_UART_Init();
 
 uint8_t val = 0;
 
 while (1)
 {
 printf("Print test with value %d\n\r", val);
 HAL_GPIO_WritePin(Test_GPIO_Port, Test_Pin, 1);
 HAL_Delay(1000);
 HAL_GPIO_WritePin(Test_GPIO_Port, Test_Pin, 1);
 HAL_Delay(1000);
 }
 
}

This the parts where I added my code.

It's a simple code, and as I said, I'm new to STM32 at all...

[LCE]

Checked the UART init?

Checked the UART registers?

Maybe the other UART side has wrong settings?

Checked the UART pins with a scope?

BTW, I don't see "val" changing.

And there is no GPIO toggling code, as you write the same value twice.

[Karl Yamashita]

You want something like this

uint32_t val = 0;
uint8_t str[32] = {0};
int main(void)
{
	while(1)
	{
		sprintf(str, "Print Test with value%d\r\n", val); // assuming val is changed somewhere else
		HAL_UART_Transmit(&huart2, str, strlen((char*)str), 100);
	
		HAL_GPIO_WritePin(Test_GPIO_Port, Test_Pin, GPIO_PIN_SET);
		HAL_Delay(1000);
		HAL_GPIO_WritePin(Test_GPIO_Port, Test_Pin, GPIO_PIN_RESET);
		HAL_Delay(1000);
	}
}

[YBCH_.1]

Hi,

Thanks for your answers but it's not in the simple loop FW.

This specific FW works just fine on the Nucleo.

To make sure, I've pasted this suggested FW and run it. Same result - No MCU response.

[Karl Yamashita]

There is no way the code you've posted will make the led toggle on/off. You set the led, and set it again instead of clearing it. If you used the code i posted and the led still doesn't blink then you have not set up the GPIO correctly. Post your IOC file

[YBCH_.1]

Hi,

Thanks for your help but it's not in the simple FW... I know how to toggle IO...

Attached my IOC file.

Thanks a lot

[Karl Yamashita]

I've generated your IOC. I've compared the code and noticed your have and function call to PeriphCommonClock_Config() that you've posted. Not sure what you're doing here?

[YBCH_.1]

Thanks for all of the answers but my problem's solved.

Apparently I was programming the Nucleo's MCU, even though JP3 (MCR_RST) was open (on Nucleo-H723ZG board).

I've connected my custom board to the JTAG connector of the Nucleo (CN5) and opened JP3 and I though this is how to use this Nucleo as a programmer for another board.

I though I was programming my MCU because all of the other indications suggested that this is the case: for example, every time I've turned off the power to my custom board, the STM32CubeProgrammer tool lost contact with the STM32 targer and was stupid enough not to read the DeviceID of the connected target.

To solve this issue I switched to Nucleo-L476RG as an external programmer to my board and with the two jumpers of CN2 open, I have aclear SWD interface with no issues.