Unknown function at <address> starts executing during the ISR's execution</address>

[morpho]

So...I have an idle task running then a UART interrupt fires upon a character being sent over the serial, and somewhere during the execution of the ISR, it attempts to execute an "unknown" function as shown in the call stack here

And here's the corresponding ASM code which I have no idea about cause I can't trace it.

Pressing the execute debugger button still executes the same function 0x774. Is it in sleep mode?

[Einar Thorsrud]

Hi,

This is within the MBR. The MBR forwards interrupts to the SoftDevice, which forwards them to your application. I am not sure what you mean by sleep mode? (If the CPU is executing code, it is not in sleep at that instant).

[morpho]

What's exactly MBR? Why is it getting "stuck" on here then once the interrupt is fired?

[Einar Thorsrud]

Hi,

The MBR is the master boot record. It is the first page of the SoftDevice. Execution should not get "stuck there". How did you end up here when debugging? As interrupts are forwarded by the SoftDevice I wonder if it could be simply that you are stepping through code execution also when it is outside your application binary, but that is just a guess.

[morpho]

Can you confirm if the scheduler wipes out the stuff allocated on the stack inside main once it runs?

[Einar Thorsrud]

Looking at your screenshot I assume you refer to the FreeRTOS scheduler. The stack will not be explicitly wiped out, no. However I believe the main stack is used for ISRs etc, so part of the data will be overwritten at some point.

[morpho]

So ISR uses the same kernel/main stack so it starts overwriting as soon as it's called. How do you verify this behavior? Do you see if MSP, when the interrupt is fired, starts at the base address of the kernel stack?
Clarifying because I have some instances of the peripheral defined inside main before the scheduler is called

[Einar Thorsrud]

Hi,

I am not sure I understand the question. Just to be clear data in the stack is overwritten after it is no longer used and the same region can be used again (think of the stack pointer going up and down, up and down etc. depending on the stack usage). You will note corrupt anything on stack by using more stack, other than things that have gone out of scope. There is no difference here compared to other use cases where you do not use FreeRTOS (when we look at the system stack and ignore each tasks stack).

I have a few question:

• Do you ask about what is at 0x744 because there is an issue or because of curiosity? If the former please elaborate on the issue.
• Which SDK and SoftDevice version are you using?

[morpho]

Hi

Sorry for the confusion. If you have something like the following, the stuff on the stack won't get cleared or overwritten though...whereas if you had a scheduler running before the while loop, according to you and what i've read, the main stack will get overwritten by, say, ISR if it were to fire.

int main(void) {

   Uart uartObj;
   int variable = 5;
   
   while(1);
}

That's all I'm trying to clarify - how come does scheduler "wipe out" the stuff on the main stack as soon as it runs that those instances aren't accessible elsewhere be it in the ISR? That's probably what's causing my issue because I'm accessing a Uart instance inside an ISR whereas the instance itself is defined in main.

- In addition to what's asked above, I'm curious to see how to actually know what is causing the issue by understanding what does unknown function at 0x744 refer to

- nRF5_SDK_17.0.2_d674dde

[Einar Thorsrud]

Hi,

morpho said:

That's all I'm trying to clarify - how come does scheduler "wipe out" the stuff on the main stack as soon as it runs that those instances aren't accessible elsewhere be it in the ISR?

I see. That is how this is typically done in FreeRTOS (see this thread). You can modify vPortStartFirstTask() in port.c to not reset the stack pointer if you want to avoid this, or simply make sure to not put any data you will rely on after starting the scheduler on the stack.

morpho said:

In addition to what's asked above, I'm curious to see how to actually know what is causing the issue by understanding what does unknown function at 0x744 refer to

I have assumed that you are using the MBR (implicitly if you are using the SoftDevice), but I did not get that confirmed. Do you use the SoftDevice? If so 0x744 is within the MBR and I will check tomorrow and get back to you. (If not, then 0x744 is within your application and I cannot say what is located there).

[morpho]

> That is how this is typically done in FreeRTOS (see this thread). You can modify vPortStartFirstTask() in port.c to not reset the stack pointer if you want to avoid this, or simply make sure to not put any data you will rely on after starting the scheduler on the stack.

fair. So it's more of a design thing to reset the MSP once the scheduler runs. Do you know how to verify the resetting of MSP? Initially when I run the program, it's set to `0x20040000` and when the IRQ is fired, it doesn't reset back to the same address

Einar Thorsrud said:

I have assumed that you are using the MBR (implicitly if you are using the SoftDevice), but I did not get that confirmed. Do you use the SoftDevice? If so 0x744 is within the MBR and I will check tomorrow and get back to you. (If not, then 0x744 is within your application and I cannot say what is located there).

Is this is the .hex file located under components\softdevice\SoftDevice\hex? I'm using Segger IDE and this link only has info on other IDEs. But all i'm doing is using one of the freertos apps and making changes on top of it, and running/debugging it