STM32F411RET6 hangs before boot

[waymond91]

Description

• Type: Bug

• Priority: Blocker

• Related issues:

I have seen this issue in a number of places online. The first place I encountered was here: https://developer.mbed.org/forum/bugs-suggestions/topic/5600/
But from what I have seen, this solution seems to have been rolled out a long time ago.

After rooting around online even more, it seemed issue #4532 captured a description of my problem.

But it seems like a lot of these similar problems were recently solved by pr #4543

I also found this post from over a year ago that seems very similar, the fact that no solution was found makes me feel like my current hardware design is dead in the water:
https://developer.mbed.org/questions/61589/Program-hangs-at-SetSysClock-on-a-custom/

Any ideas of what I should do? I felt like this must have been a hardware issue when I first started. But now I see that I can run & debug code if I use the system default clock, so I should be able to configure the HSI to run at a reasonabe speed, preferably with the Mbed environment!

---

Bug

Target
NUCLEO_F411RE

Toolchain:
GCC_ARM

Toolchain version:
6.3.1

mbed-cli version:
1.0.0

Expected Behavior
Platform should boot to the beginning of the main() function.

Actual Behavior
Application times out/crash before reaching the main application while configuring the MCU clocks.

Hey Guys,
After playing around with a Nucleo-F411 board for a while I decided I wanted to deploy this MCU to a custom PCB for my application.
I am using an external 8 Mhz crystal, and I believe I have selected the right capacitors for the oscillator.
Regardless, my system hangs and does not make it to the main() function of my code when building via mbed-cli.
I have tried removing the external crystal and configuring the HSI. However, when using the mbed compiler does not work because the program doesn't reach my main function.
If I comment out this line of system_stm32f4xx.c
237 SetSysClock();
the program will make it to my application, but of course everything runs at the default 16Mhz, while the rest of the application expects 96Mhz.

So from here I should be able to configure the HSI to run similarly to the HSE:

SYSCLK = 96 Mhz
AHBCLK = 96 Mhz
APB1CLK = 48 Mhz
APB2CLK = 96 Mhz

But I don't really know how much of this configuration Mbed is performing in the background.
Using CoIde + ARM_GCC, I have tried to configure the clocks in a variety of ways, shown below.
But the program often crashes after HAL_RCC_OscConfig(&RCC_OscInitStruct) although sometimes it runs if I step the processor through the entire stm32f4xx_hal_rcc.c file manually?

#include "stm32f4xx.h"
#include "stm32f4xx_hal_gpio.h"
#include "stm32f4xx_hal_rcc.h"

GPIO_InitTypeDef GPIO_InitStructure;

void Error_Handler(void);

int main(void)
{
	HAL_Init();

	RCC_OscInitTypeDef RCC_OscInitStruct;
	RCC_ClkInitTypeDef RCC_ClkInitStruct;

	/**Configure the main internal regulator output voltage
	*/
	__HAL_RCC_PWR_CLK_ENABLE();

	__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

	//Configure Internal Oscillator
	RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
	RCC_OscInitStruct.HSIState = RCC_HSI_ON;
	RCC_OscInitStruct.HSICalibrationValue = 16;
	RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;

	RCC_OscInitStruct.PLL.PLLM = 16;
	RCC_OscInitStruct.PLL.PLLN = 192;
	RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
	//RCC_OscInitStruct.PLL.PLLQ = 2;


	//Configure External Oscillator
	/*
	RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
	RCC_OscInitStruct.HSEState = RCC_HSE_ON;
	RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
	RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

	RCC_OscInitStruct.PLL.PLLM = 8;
	RCC_OscInitStruct.PLL.PLLN = 192;
	RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV4;
	RCC_OscInitStruct.PLL.PLLQ = 2;
	*/
	if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
	{
	Error_Handler();
	}



	RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
		              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
	RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
	RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
	RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
	RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

	if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3) != HAL_OK)
	{
	Error_Handler();
	}

	/**Configure the Systick interrupt time
	*/
	HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

	/**Configure the Systick
	*/
	HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

	/* SysTick_IRQn interrupt configuration */
	HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

	__GPIOC_CLK_ENABLE();
	GPIO_InitStructure.Pin   = GPIO_PIN_8;
	GPIO_InitStructure.Mode  = GPIO_MODE_OUTPUT_PP;
	GPIO_InitStructure.Pull  = GPIO_PULLUP;
	GPIO_InitStructure.Speed = GPIO_SPEED_FAST;
	HAL_GPIO_Init(GPIOC, &GPIO_InitStructure);

	HAL_GPIO_WritePin(GPIOC, GPIO_PIN_8, GPIO_PIN_SET);

	//printf("Yeah Right\n\n");

	while(1)
	{
		HAL_GPIO_WritePin(GPIOC, GPIO_PIN_8, GPIO_PIN_SET);
		HAL_GPIO_WritePin(GPIOC, GPIO_PIN_8, GPIO_PIN_RESET);
	}
}

void Error_Handler(void){}

[LMESTM]

@waymond91 Hey, let's try to address your own issues.
#4532 and #4543 are very recent issue and I think they were fixed before any online release - so those are different from your own request.

So let's focus on your need: you want to boot F411RE based HW from HSI with the online compiler right ?

[waymond91]

@LMESTM Sorry I wasn't trying to dredge up the past, just looking for a solution that might already be out there.
Yes! That is exactly what I am trying to do.
However, when I upload my code to my PCB, the application never appears to run.
In an effort to get the online compiler working, I have poked around using the MBed CLI, and ARM-GCC (with OpenOCD and GDB for debug).
Doing a little debugging seems to reveal that the program is hanging somewhere waiting for/configuring the HSE.
I am using a custom designed PCB, and this is my first legitimate attempt at doing an ARM board, so I am worried that it may be a hardware problem.
However, my program does seem to make out of the SystemInit() function from system_stm32f4xx.c so it is not simply a dead chip...

[LMESTM]

@waymond91 there is ongoing work to make selection of clock source easier so we'll keep you informed on this. And in the process we'll make sure that NUCLEO_F411RE can boot from HSI when using online IDE.

[waymond91]

Sorry, I am very new to the work flow around here.
How will I know when any updates have been made to the online compiler that pertain to my issue?
Thank you for the help!

[LMESTM]

@waymond91 We'll keep you posted on our findings here. Then when it comes to releases to the online compiler, there will be some delay, but we can rely on ARM maintainers to confirm to us when this is available.

[waymond91]

@LMESTM Thank you, once again!
I would love to know what you find so I can try changing some local build files on my end during that delay!

[jeromecoutant]

Hi
With MBED, you don't have to configure the clock setting in the main part of your code!
You only have to include mbed.h:

#include "mbed.h"
int main() {
printf("SystemCoreClock %ld MHz\n", SystemCoreClock/1000000);
while (true) {
}
}

About setting the clock source, in the current default code, HSE is tried; then if it fails, after a timeout period, HSI is configured. (see #4422)
You can check targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F411xE/TARGET_NUCLEO_F411RE/system_stm32f4xx.c file.

In the future (see #4421) you will be able to configure explicitly your clock source thanks to mbed_app.json file. Note that this method will work with online compiler and with local IDE.

[waymond91]

Thank you for letting me know!
Yes, my problem is that the program never makes it to main() in the first place, so any code I put in there is moot.
I knew that those timeouts had be lengthened substantially (5 seconds), but I did not know they were brought back down to 100ms.

[LMESTM]

@waymond91 what I'd suggest is that you try to use mbed master branch together with #4421 proposals and try to boot your board from HSI by setting the proper setting in mbed_app.json. This would validate the concept that @jcostm is proposing

[waymond91]

Ok, so I have updated my mbed cli and looking through the target files for the stm32f411 it seems like the clock config has been moved to a json file per system_clock.c in for the nucleo board on line 42

  42|    // clock source is selected with CLOCK_SOURCE in json config
  43|    #define USE_PLL_HSE_EXTC     0x8  // Use external clock (ST Link MCO)
  44|    #define USE_PLL_HSE_XTAL     0x4  // Use external xtal (X3 on board - not provided by default)
  45|    #define USE_PLL_HSI          0x2  // Use HSI internal clock

I have been suspecting that what may have been the issue is that most of the stm32 discovery boards use a 25Mhz crystal for the HSE and I am using an 8 Mhz.
Where is the mbed_app.json file?
Do I to configure the HSE xtal frequency here or somewhere else?

Best regards gang

[jeromecoutant]

HSE_VALUE value is defined in targets/TARGET_STM/TARGET_STM32F4/device/stm32f4xx_hal_conf.h

#if !defined (HSE_VALUE)
#define HSE_VALUE ((uint32_t)8000000U) /*!< Value of the External oscillator in Hz /
#endif / HSE_VALUE */

You can update it.

Another way is to define in in mbed_app json files:

    "config": {
        "hse_value": {
            "value": "25000000",
            "macro_name": "HSE_VALUE"
        }
    },

[LMESTM]

@waymond91 have your questions been successfully answered ?

[LMESTM]

@waymond91
Unless there are other questions, I think this issue has been addressed.
ST_TO_BE_CLOSED

[bcostm]

Bump
Bump?