Store Codes in the Flash Memory in the STM32

[AE104]

Hello,

I am using stm32f767 as a microprocessor. After power off, the codes are deleted from the microprocessor. But when I checked with the STlink Utility, I saw that the codes are stored in the Flash memory. Is the reason of non operative processor after power off related with some parts of the code not stroing flash memory properly or hardware issue?

Thank you,

[Tesla DeLorean]

Make sure BOOT0 pin is pulled low.

Check Option Bytes for boot and banking options.​

[AE104]

Boot0 is grounded through 100kOhms. How can I check this "Check Option Bytes for boot and banking options.​"? @Community member​ 

[Tesla DeLorean]

I believe the bits in the option bytes are in the RM, you'd start perhaps by inspecting the values in the unit(s)

I'd pick something significantly more aggressive for a pull-down.

It could be your code is actually starting, but dies in Error_Handler() or HardFault_Handler(), have some GPIO's toggle there so you know if it started and failed.

[TDK]

Use STM32CubeProgrammer to inspect them in the "OB" tab. Can also use the deprecated ST-Link Utility.

100k pulldown should be fine.

You can attach the debugger to an already-running chip to find out where the processor is at within the code.

[AE104]

Thank you @Community member​ and @TDK​ !

I have attached the STM32CubeProgrammer screenshots. My impression is that all settings are correct to write the codes in the FLASH memory.

Sorry, I mistyped the resistor value. There is 10kOhm resistor at BOOT0 pin.

When the debugger connected and in the debug mode, the code is stuck at void HardFault_Handler(void). Attached the screenshots

 

 

[TDK]

Use the information that it's providing you. What is at main.c line 284?

[AE104]

Oh now I recognized that on the error. There is a calculation. @TDK​ 

AmpModFreqCalculation = round((1000000 / (ModulationFreq * 128)));  

So, the ModulationFreq value doesn't have a value every time. In a certain condition, the variable has value. Is it because of that?

[TDK]

Do you mean that sometimes it has a value of 0? Divide by zero can cause a hard fault. Using floating point instructions when FPU is not enabled can also cause a hard fault.

[AE104]

Yes. For testing purposes, I set the AmpModFreqCalculation as 78, and the error was gone. Thank you @TDK​ !

But the system is still not working after power off and on. Basically, I hit the 'Run' on the CubeIDE. At the end of its process, I removed the debugger from the connector. Then, I powered off the system and powered on back. I can connect to Bluetooth successfully with an interface. But there is no receiving and transmission. Interesting thing is that when I connect the debugger after powering off and on, the system works.