Separated IRAM for bootloader and application

[lgoti]

Hello all

I have application that use some functions from bootloader. Sometimes when I call function from bootloader some of my variables in IRAM get changed by bootloader and that is causes problems to me. To fix that issue I decide to split IRAM to 2k for bootloader and 6k for application. I've made changes in "options for target" in both bootloader and application. After I've done this changes I have new issue with my application, it doesn't work properly and application is resenting after 2-3 minutes. 6k is more then enough memory for my application so I don't know what could cause this problems.

Does anybody have some idea what could be the problem or how to start diagnostic :)

[Tesla DeLorean]

I guess you have to learn how to debug things..

Check your stack allocation and usage.

Instrument your code so you understand what it is doing, and the paths of execution involved. Instrument HardFault_Handler and Error_Handler to provide actionable information if it reaches those.

Do you have a Watchdog timer running?

On CM0 parts make sure you've suitably relocated the Vector Table.

[Mario Simunic]

Actualy, I was looking for good examples for HardFault_Handler() and Error_Handler().

I found none.

Please, could You give some points to literature or web sites which explains debugging process needed for Luka.Gotic's problem?

[Tesla DeLorean]

Anything would be better than a while(1) loop of silent death.

I've gone over this topic space ad nauseam, does Google not function for people, do I live in a bubble of service? Learn how to use search properly. Look harder, use better search terms.

https://community.st.com/s/question/0D50X0000Az372YSQQ/stm32l412-hardfault-while-using-minimal-cubeide-example

Instrument your code, output diagnostic/telemetry data to a serial ports so you know WTF your code, that you wrote, is doing.

If you have to single-step everything to unpack your own logic, you have failed.

Do static analysis of your call tree. Use that, and some margin, and understanding of interrupt call trees to pick a minimum depth.

Do dynamic analysis of your stack usage, measure how deep it gets, determine some high/low water marks. Enable stack-checking where supported.

Wrap malloc()/free() usage so you know if you are leaking resources, or double releasing memory.

Walk the allocation lists, determine if the list is fragmented.

Walk the stack.

Write routines that walk the stack/heap automatically. Write routines that can dump internal state information, and decompose peripheral/register settings.

Have your production code output enough data to the user that they can provide useful diagnostic information on a call.

If you're not good at detective work, or the behaviour of your own code/logic, consider trace tools, that can allow for dynamic profiling, and how-did-I-get-here failure analysis.

Don't use the Error_Handler(void), use the Error_Handler(__FILE__, __LINE__) so you have some idea where it faulted, better yet have effective failure recovery, or fail safe behaviour, at the points you would have called it. Output a diagnostic message.

I feel a lot of this is basic (embedded) programming competency, but I suspect having multi GHZ/GB systems tends to hide the complications of a resource bound system.

#GroundhogDay #EmbeddedKindergarten