 Let's continue and let's jump on something a little bit more interesting and more detailed the advanced topics for the free Arto's and the way how to make the code More robust and more responsive to different types of errors So one very important part of the free Arto's architecture is the hooks Hooks are methods that are called in case something specific happens and It can be a reaction on a task switch. It can be a reaction on the memory allocation fail or Stack overflow and some others Normally the hooks are disabled and they are not called within the code. So it's covered by a macro And if the macro is disabled the calls are not there, but if you enable the calls You should define the appropriate function with a specific name But if you enable it in a cuba mix the function is generated So you only fill in your own body for such function The cuba mix generates the hook functions in free Arto's dot C file so you can find them here So the first thing is the idle hook The idle hook is a very interesting thing It's entered anytime when the idle Is entered you know that the idle task is Something that Runs when all other tasks are not available are blocked the free Arto's In fact doesn't have anything to do. So it calls the idle task and In the idle task we can set up idle hook and idle hook Should never be blocking or Suspending any other tasks. So it should be a pass through function You can see that this is an example of a good one We only increment a variable and exit The case where we stay in a while one in a blocking loop must not be present so If We want to use the idle hook We can enable it in the the list of the hooks in the config parameter stop for the free Arto's and And The advantage of the idle hook is that within this callback we can enter a low power mode Because if the microcontroller doesn't have anything else to do Typically it will be awakened on a system timer on external interrupts on Wake up from for example from the real-time clock or from communications So we can use the idle hook to put the microcontroller to sleep mode so when we enable it at the Free Arto's will be expanded by the prototype of the function and by a weak buddy You can see there is quite a long comment about when it's called and how it should be used One big remark don't use any blocking functions in this one I'll hook use it for entering into low power modes or you can as well mark the entry to the idle function and by using this time entry and entry to the next Task switch you can calculate how much time we spent in idle and how much time is used by other functions of the free Arto's So the idle hook can be as well used for monitoring the CPU load Another hook that gets called when it is active and activated in cuba mix is the tick hook This is a function that gets called periodically after the cystic interrupt gets Triggered so after every free Arto's time base activation the tick hook is called as well so again, it should be not blocking function because it would block completely the interrupt and You should use interrupt safe free Arto's functions Especially if using the native interface the from ISR suffix should be added and Because it's called from the interrupt context So this one when activated gives you the chance to react periodically with one millisecond It's the most effective place where a periodic timer callback can be placed another callback and this is a very important one is Activated when you enable the malloc failed this is Very important when you design your free Arto's with a dynamical memory allocation Why because whenever you put a new message in the queue or when it reorders the lists when you create a task when You operate with any object of the free RTOS it allocates and the allocates dynamically some memory and At the moment such memory is not available anymore due to the size of the heap or due to the fragmentation of the heap the malloc can fail and It will most probably give you a minus one or null pointer and You saw that Most of the code user code doesn't care about return values and doesn't care about pointers The RTOS does care and if you enable the malloc failed hook it will jump into this function if the V port malloc or PV port malloc function fails and Doesn't have any available space So it gives you one central point one central callback where it tells you hey your application failed and Here you can do a recovery steps typically logging it and resetting This hook is critical for proper application debug and even in a release mode You probably should use it to record any runtime issues and performance issues with your application I give you my own experience either I use this function or I can spend several days hunting really mystery errors because if you somewhere allocate an object with Completely nonsense pointer and Then you start using it somewhere With some delay because you normally don't need to use the allocated object immediately You just allocate it it fails Okay, put it in a pointer and use the pointer After some time when the communication arrives you need to put the data into this allocated memory and suddenly couple of seconds later There is no memory where you put the data to so you get a memory fault you get a hard fault and you know why So using this one really really helps It is activated again by a Cuba mix with the use malloc failed hook macro and It's generated in free artist.c file with a comment how to use it So in case you get here, I think it's Most probably unrecoverable state So if your application isn't dynamic enough that it can skip a functionality that relies on the memory allocation you can live with that but If you don't write such dynamic application, it's better to log it and restart So one example where you can see immediately how it works. We can have a malloc fail message and When we try to allocate too much memory the malloc will immediately fail because One megabyte cannot fit into few kilobytes of the microcontroller SRAM another very important thing is to check the stack overflow for your tasks You already know and some of you noticed when you edit new objects The Cuba mix already started complaining that the heap is too small This is a good thing because previously we didn't check the size of the memory and when you generated the project with the original three-kilobyte heap Many functions simply didn't fit So right now you have a message telling you hey you need more heap but If you don't do that or if you put too small stack for a given task It can happen that the stack gets overwritten By calling external or library functions where you don't know exactly how much local variables they allocate By calling recursive function that puts local variables on the stack by simply calling a too complex and the deeper a program or library So it's difficult to say how much stack you need and It's even more difficult to debug a program whose stack overflow Especially because while you are still in this program You own the memory you own all the content of the RAM So if you overflow some into other area at the moment you are the owner of the CPU You don't feel any issue The memory is still around so you can write anywhere you want and the the task works very well But at the moment when the kernel does a task switch and it starts reading the other tasks tcb and Returns to it. Suddenly it realizes. Well, there is a mess so When it jumps there It crashes the application will crash in many different ways in many different functions With many different errors It can be Wrong return addresses. It can be completely wrong parameters. It can be just a slight modification of a variable and Then you see different calculation results So you can really imagine thousands of different errors That can be emitted by a corruption of the stack and I can tell you that debugging such thing is like going blind Because you don't know where this came from why your perfectly written program simply doesn't work until you get an idea who's behind Your set of variables who's behind your own stack and You look at the other task asking hey could this overflow Friartos has means to test if the overflow occurred and It has to be enabled to do that to check if the stack overview for given function we get the Friartos when it sets up a stack For a given task it fills the memory with the pattern a5 Additionally it puts The high watermark record in the stack so we know how much of the stack was used and If we want to check in runtime if the stack did overflow We should be set these parameters to one use trace facility the function task gets stuck stick high watermark and There is a specific function that Will be able to calculate the high watermark of the stack Then we have to choose one of the methods for the stack overflow detection There are two of them The first one the simple one is where we set the macro check for stack overflow to value one at this point It will just check If the stack pointer contains value outside of the valid stack range So it will take the stack pointer that gets adapted during the program flow and When it is outside of the stack range Which is a very quick check. It's just two boundaries start and end of the stack is The PSP out or inside so if it's outside you get a call to the Stack overflow hook So it's a very basic thing. However, it can happen that your stack you overflow the stack but in the meantime you return from the functions so the Program stack pointer is within the boundaries again, so it went back and Then of course the first check will not give you an error even if the stack did overflow So if you see issue with this approach you can allow the option number two and the option number two is longer Takes more time during the task switch, but it takes The area at the bottom of the stack and checks its validity So there are four words with a pattern and this function will read it and compare it to the known pattern So if your stack overflow occurred Be this pattern will be corrupted so if you read it and It's corrupted, you know that your application most probably went through and came back So at this point you get again stick overflow with much bigger reliability So check for a stick overflow should be enabled with the option one or option two and Then it gives you the application stick overflow hook additionally, it Signals which task and the task name cost this stick overflow so if you utilize these two parameters you are able to print it and You know that this task needs to extend the stack size Or to optimize it at this point The stack overflow again should be or should somehow solve this situation so again, my suggestion is to lock such event including the task name and Restart or freeze the application because If you have got a stack overflow, you know that you have corrupted not only your own stack but a stack of some other task and If you let the scheduler jump to it It will be most probably destroyed so This way with the hooks you are perfectly able to react on a critical situations happening in your application in the Friartos environment So memory Maloch failed the stack overflow within the routines you You can react on low power mode with the idle hook and You can as well create very effective periodic functionality with the cheek hook Further, if you are interested in runtime behavior of the Friartos Apart from the debug environment, we saw already in Atolic that we can open some Friartos debug windows and when we break our application we can see the list of tasks and other objects queues, mutexes and The Atolic plugin is able to extract this data from the memory of the Friartos and the display it so you can see during debug how the tasks behave and This is a very useful thing for debugging on the other side who's interested in seeing this in runtime without debugger connected Are you interested in seeing how your tasks allocate the memory? How they switch how much time they spend inside and so on So it's a very nice application for a web server of your small device you can have one web page that shows all these tasks and You can check if the memory is at the limit How much is allocated in the heap how much stack is used for each single task in which order they are Executed whether they are suspended blocked and so on so the Friartos has support for this functionality and It can be collected by a function OS thread list this function calls a V task list and This one has or needs a pointer to the function that works like a print F so it gives you a formatted output text output and calls this printer function task by task and It formats the output and Then you can send it or store it anywhere you want But the prototype should look like a print F so You can implement your own method of storing or sending this data out Including it in a web page and so on To support this functionality you have to enable the trace facility macro and use stats formatting functions Be careful that the functions for start formal statistics formatting and needs to be added manually