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