Using Application Hooks

Kernel
1

I have configure OS hooks
especially vApplicationMallocFailedHook() & vApplicationStackOverflowHook

My application leverages of AWS FreeRtos. I just wanted to know if can delete all tasks inside these hooks and call a function to update a certain MQTT topic that my application has crashed before rebooting.

2

A stack-overflow means that some memory has already been corrupted - you cannot do any operation (other than reboot) reliably at that point as you do not know what memory is corrupted. Treat this more of a development/debugging aid and configure your stack sizes to ensure no overflow. If that still happens at runtime, you should just reboot.

Malloc failures on other hand can be handled more gracefully in your application by checking the return value if you expect the memory to be available at a later point. Something like:

uint8_t * memory = pvPortMalloc( sizeof( myDataStructure ) );

if( memory != NULL )
{
    /* The memory is available and we can continue the operation. */
}
else
{
    /* There is no memory right now - we will attempt the operation again
     * in future.

     * Note that an inherent assumption here is that the memory will be
     * freed by someone in future. */
}

The malloc failed hook should also be considered a development/debugging aid to help you configure the heap size correctly.

In either case, you do not need to delete tasks.

Thanks.

3

Thanks @aggarg .
Is there anything I could do flash the reasons of failure to memory which I can access later on(on restart) to report my ‘crash incident’ to Cloud?

4

Maybe implement the application hook to write the reason to flash, then have your startup code read the reason for the last reset?

5

A number of MCUs provide a reset/startup mode and other related information b/c usually they have reset-controllers and power-supply monitors built-in.
In a project I store kind of ‘dirty’ flag in EEPROM on startup (with properly running FW) and set it to ‘clean’ on normal restart/shutdown/power-off.
On next startup this flag is checked along with the mode from the reset-controller to provide some diagnostic information.
I’d not recommend to do much work like storing something to flash/EEPROM in a crash handler.
Another feasible strategy is to store some information e.g. in a reserved part of RAM (not cleared/initialized on startup) and reset the MCU in a crash handler.
Then on the following startup you can retrieve and report this diagnostic information.