hard

[Jessy J]

.

[Tesla DeLorean]

Posted on May 18, 2018 at 15:08

Review the processor registers and assembler instructions at the fault to get a better idea of what the cause might be.

Generally will be issues accessing memory, either memory that doesn't exist or alignment issues. Check things like stack size, potential corruption on stack. Make sure not to link 32-bit code into the project.

Do you have a teacher, colleague or supervisor who can work with you on these things?

[Jessy J]

:(

Thank you for your help in advance

[Jessy J]

Posted on May 18, 2018 at 16:23

How to 

stack size, potential corruption on stack pleaase ?? 

and how to 

Make sure not to link 32-bit code into the project. ??

[Bogdan Golab]

Posted on May 18, 2018 at 16:56

If the project is empty and generated by the CubeMX - please check the clocking. Try HSI as it is build-in clock and check again.

[Jessy J]

Posted on May 18, 2018 at 17:10

I tried HSI  instead of HSE  in systemClock_config and it is same '' Hard fault handler ( FORCED) '

:(

 ;( 

[Jessy J]

Posted on May 18, 2018 at 17:22

Yes I am using this board T32479I EVAL..

Idid not understand your question 

25 MHz?

Running at 128.57 MHz? 

it is 

FLASH_LATENCY3 shall I increment it to four for example ? 

[Tesla DeLorean]

Posted on May 18, 2018 at 17:26

You're clearly plugging some parameters into CubeMX about the clock settings.

I'm observing that the generated example looks to run at 128.57 MHz, is that expected?

Issues with FLASH can cause Hard Faults, try FLASH_LATENCY_4

Do you work with anyone with more experience who can work with you on this?

[Tesla DeLorean]

Posted on May 18, 2018 at 17:45

Review the board schematic. The board should have a 25 MHz clock. I would expect the PLL_M parameter to be 25, and the definition of HSE_VALUE in the project should be 25000000

If CubeMX is not generating viable code with the settings you are inputting, perhaps try the HAL examples for the board.

STM32Cube_FW_F4_V1.21.0\Projects\STM32469I_EVAL\Examples\UART\UART_Printf

Consider also posting the registers reported at the hard fault, and the disassembly view of the instructions that are faulting..

If you can get the USART_Printf example working perhaps add a HardFault_Handler that printf() data about the situation rather than looping in a while(1);

[AvaTar]

Posted on July 05, 2018 at 12:38

I would honestly suggest to look for a local mentor, who can sit at the screen with you.

Seems you are a bit overtasked.