Call Stack Usage in ES

This section provides detail to how to exploit the feature of Call Stack Usage in Embedded System IDEs.

Ever wondered why are we trapped in the hard-fault-handler? The example below is used to explain the solution.

https://github.com/manvendra88/STM32/blob/master/Hard-fault-handler.c

As i run this code in the debug mode, i found I was unable to execute all the lines and every time i stopped the debugger, it got stuck at hard-fault-handler.

Why?

Because we are trying to fetch instructions from an illegal address. But, how do we get know which line among all is causing this? Here, we use the call stack.

Resolving

Now that i know, what is causing this issue, i can put a break point and see till where my code is working fine. In my case, till :-

2. Watch Window

I went to definition of some functions of my code and dragged and drop a few variables to see how their values are changing. As i have not ran the code yet, any of these values can't be evaluated.

But, as soon as i put the break point one the function that takes argument 'num', the num value is written into the variable.

As i carried stepped into the next function, all the variable values are shown with their types :-

As soon as i stepped out of the last function, the variables used inside it are gone :-

3. Memory Window

What if we want to see the contents of our memories like FLASH, RAM, or peripheral memory. Let's start with where our code is stored in the memory?

1. Code is stored in the FLASH. What is the base address of the FLASH?

0x0800 0000

2. RAM Base Addr

0x2000 0000

Does this code utilizes RAM? https://github.com/manvendra88/STM32/blob/master/RAMContent.c . Well, as we can see, the RAM is almost empty! Why because our code doesn't utilizes the RAM yet.

I took help from http://ecomputernotes.com/what-is-c/function-a-pointer/type-casting-of-pointers to understand type-casting of pointer which is used in ram_read function of my code.

I have added one function in the code that reads data from the RAM. Comments in the code are helpful enough to understand what's going on.

As i wrote 12 into the memory, it is reflected on to the value variable in Watch1 section. But its written as 0x00000012. This is because, ARM represents variable in Little Endian approach that is reverse order of the memory when it is written to the variable. Humans like Big Endian as they write MSB first but processors are happier with LSB first to be efficient.