HardFault_handler in GUI_Init ()

[FLast.14]

Posted on August 02, 2016 at 16:06

Hi,

I've just soldered a second PCB with a STM32F429ZIT6. The first PCB runs perfectly, so the code seems correct. I compile, and debug the code. The code is loaded correctly because there is any complain from Keil.

I've inherited this code from my old colleage which he currently isn't in my company, so I soldered this new board according to the schematic and I’ve resoldered all solders.

So, I’ve compile the code and load through debug and starts, goes fine untill arrives in GUI_Init which crashes!

I’ve debug the code and crashes in the last line of GUI_X_Config function:

void GUI_X_Config(void) {
//
// 32 bit aligned memory area
//
#ifdef GUI_BUFFER_IN_EXT_RAM
static U32 aMemory[GUI_NUMBYTES / 4]__attribute__((at(GUI_BUFFER_ADDRESS)));
#else
static U32 aMemory[GUI_NUMBYTES / 4];
#endif
//
// Assign memory to emWin
//
GUI_ALLOC_AssignMemory(aMemory, GUI_NUMBYTES);
//
// Set default font
//
GUI_SetDefaultFont(GUI_FONT_6X8);
}

I go over to disassembly code and in the line

0x08003C6A BD10 POP {r4,pc}

The code goes to HardFault_Handler function.

The disassembly code is below:

0x08003C5E 4803 LDR r0,[pc,#12] ; @0x08003C6C
0x08003C60 F7FDFF22 BL.W GUI_ALLOC_AssignMemory (0x08001AA8)
104: GUI_SetDefaultFont(GUI_FONT_6X8);
105:
0x08003C64 4802 LDR r0,[pc,#8] ; @0x08003C70
0x08003C66 F7FFFD81 BL.W GUI_SetDefaultFont (0x0800376C)
106: }
0x08003C6A BD10 POP {r4,pc}
0x08003C6C 0000 DCW 0x0000
0x08003C6E D060 DCW 0xD060
0x08003C70 0B30 DCW 0x0B30
0x08003C72 0804 DCW 0x0804
88: {
0x08003C74 B510 PUSH {r4,lr}

Is it possible that the code is the problem?

If, for example, the display is not connect correctly should be the problem?

What does exactly GUI_Init function? does it check the hardware?

Thanks!

#crash #emwin #hangs #gui_init

[FLast.14]

Posted on August 08, 2016 at 09:38

Hi Clive, 

Ok, thank you! Now doesn't hang but doesn't print anything... :'( I've configured the Trace too.What I do wrong?

[Tesla DeLorean]

Posted on August 08, 2016 at 17:47

Are you sure the F429 is actually running at 168 MHz, and not something like 180 MHz? The setting of the clock is critical. Check the PLL setting in system_stm32f4xx.c and on the pins, ie MCO PA8

You should try doing a printf() early in main() to confirm you have connectivity.For an 84 MHz system I'd set trace like this

[FLast.14]

Posted on August 09, 2016 at 13:08

Hi Clive1,

I've compute the value and obtain 168MHz. The clock is configurated as:

void SystemClock_Config(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_ClkInitTypeDef RCC_ClkInitStruct;
RCC_PeriphCLKInitTypeDef PeriphClkInitStruct;
__HAL_RCC_PWR_CLK_ENABLE();
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
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 = 336;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 7;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
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_DIV4;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5);
// Clock de LCD
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC;
PeriphClkInitStruct.PLLSAI.PLLSAIN = 100;
PeriphClkInitStruct.PLLSAI.PLLSAIR = 2;
PeriphClkInitStruct.PLLSAIDivR = RCC_PLLSAIDIVR_2;
HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);
HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_PLLCLK, RCC_MCODIV_1);
HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);
HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);
/* SysTick_IRQn interrupt configuration */
HAL_NVIC_SetPriority(SysTick_IRQn, 15, 0);
}

By other hand, I add the MCO because there is not activated before (it's the first time that I work with MCO) I don't know if I have to configurate other things. I recreate the STMCube project in order to check what is the code to add, so I think it's enough. Also I want to share with you (and the readers) my Clock tree configuration, maybe it can help to detect the problem: I just check MCO1 pin and the result is 168MHz. This is correct, isn't it? But I can't achive view any printf :'(

[Tesla DeLorean]

Posted on August 09, 2016 at 15:15

Make sure PB3 SWO is connected on your debug interface, this is required for SWV/Trace

[FLast.14]

Posted on August 10, 2016 at 12:03

Yes... but can't view any printf...

By other hand, I program into STM32F429I-DISCOVERY board and either I can't see printf (but the code runs correctly!).I don't understand why in DISCOVERY board the code run perfectly and in my 2nd, 3th, 4th, board not (''my first'' board it runs ok, but it was programed by my old colleague). Is it possible that is there anything that it is necessary programed first, like a bootloader in order to it  works? because the both boards with the code runs contains a microcontrollers which not virgin. I'm in a well :(

[FLast.14]

Posted on August 11, 2016 at 15:45

Hi Clive, 

I've achived view the last instruction before the code hangs thanks to this application note

https://www.segger.com/downloads/appnotes/AN00016_AnalyzingHardFaultsOnCortexM.pdf

But in that point, I don't know interpret what these values mean. Can you help me?Thanks

[Tesla DeLorean]

Posted on August 11, 2016 at 18:03

I'm not able to make any determination from that information.

If the Discovery board always works, and yours doesn't start looking very carefully at the hardware, especially the power, VCAP voltages, and understand where the designs diverge.Look at the code at, and immediately before, the fault.

[FLast.14]

Posted on August 12, 2016 at 14:28Hi Clive1, From your last answer I've searched what is happening, maybe the capacitor values are wrong. I've found this page http://electronics.stackexchange.com/questions/102082/minimal-arm-circuit-is-not-working and I've changed the capacitors between Vdd and Vss instead of 100nF, I've soldered 100nF//1uF. And voilà! The 2nd own board prints perfectly for LCD, so runs correctly. 

Buuuuut

! The rest of boards (which they are identical from the 2nd) don't work... I've test 4.7uF instead of 1uF, I've soldered a ferrite (L1 BEAD) as Discovery board, but nothing... Its hard for me understand why the same code, in the same schematic circuit, some boards works and some boards not... Thank you very much for your attention, I've learnt a lot with you, from all my heart. Thanks again. I hope I will learn more :)

[Tesla DeLorean]

Posted on August 12, 2016 at 20:26

It is not hard to build circuits with shorts or opens, or wrong components. It is very hard to diagnose things through the key-hole.

What voltages are you seeing on the VCAP pins?Make some simple test programs.

[FLast.14]

Posted on August 31, 2016 at 08:12

Hi Clive1, 

Sorry, I was out of the office. I'm going to measure the Vcap values and I will notify to you. If I not wrong, the Vcap values were between 1.34v and 1.40v. I'm going to test again, and I will explain you. Thanks