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?
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).
What's exactly MBR? Why is it getting "stuck" on here then once the interrupt is fired?
> 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
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
morpho said: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
It is only "reset" when the first task starts. After that, it behaves just as normal stack. I am not sure what you want to verify, but you can check the stack pointer from the debugger.
morpho said:Is this is the .hex file located under components\softdevice\SoftDevice\hex?
Yes (though the path is a bit different with different variants). All BLE projects use the SoftDevice.
morpho said:I'm using Segger IDE and this link only has info on other IDEs.
This is independent of which IDE / toolchain you use.
morpho said:But all i'm doing is using one of the freertos apps and making changes on top of it, and running/debugging it
There are several example apps in the SDK, both using a SoftDevice and not using it. Please check if you are using a SoftDevice (and thus MBR) or not, as that is key to know if 0x744 is within something we provide (the MBR) or the app you built yourself. If it is in the MBR as I assumed, it is in the interrupt vector table, so related to interrupt forwarding. See Exception model in the SoftDevice specification.
It is only "reset" when the first task starts. After that, it behaves just as normal stack. I am not sure what you want to verify, but you can check the stack pointer from the debugger.
Yeah but that's what I'm trying to do: to figure out how to actually see this behavior by navigating MSP. As described, the initial value is `0x20040000` at the start of main. Is it supposed to reset back to `0x20040000` once the task starts?
Sorry, you didn't seem to answer my dumb question: how do you verify if the softdevice is being used on my device?
Hi,
morpho said:Sorry, you didn't seem to answer my dumb question: how do you verify if the softdevice is being used on my device?
What is the start address of your application? If it is at 0x0, then you are not using MBR or SoftDevice. If it is higher than that, you are typically using the SoftDevice (even if it is not enabled, it will forward interrupts to your application). If you let me know which example project you have based your app on I can check for you. To be frank I think you need to read up a bit on the overall architecture before digging into such details as it seems to me you may be missing the over all understanding that should be in place first.
Update: I see i referred to 0x744 instead of 0x774 and that typo stuck in this thread. However, both are within the interrupt forwarding code of the MBR, so that is certainly what is going on.
MSP, as mentioned earlier, at the start of the application is 0x20040000, which according to your description, means I'm using a SoftDevice?
I'm building stuff on top of ble_app_hrs_freertos project. And I agree with you on learning about the softdevice architecture itself.
MSP, as mentioned earlier, at the start of the application is 0x20040000, which according to your description, means I'm using a SoftDevice?
I'm building stuff on top of ble_app_hrs_freertos project. And I agree with you on learning about the softdevice architecture itself.
morpho said:MSP, as mentioned earlier, at the start of the application is 0x20040000, which according to your description, means I'm using a SoftDevice?
No.
morpho said:I'm building stuff on top of ble_app_hrs_freertos
That project uses the SoftDevice, and thus MBR. Then we can conclude that 0x774 is from the interrupt forwarding code in the MBR, so all seems good.
MSP, as mentioned earlier, at the start of the application is 0x20040000, which according to your description, means I'm using a SoftDevice?No.
Mind elaborating on what your initial request was then? Doesn't MSP tell you the start address?
> The SoftDevice inspects the SVC number, and if it is equal or greater than 0x10, the interrupt is processed by the SoftDevice.
Is 0x774 the SVC number?
> The SoftDevice uses the first eight bytes of RAM when not enabled. Once enabled, the RAM usage of the SoftDevice increases. With the exception of the call stack, the RAM usage for the SoftDevice is always isolated from the application usage. Therefore, the application is required to not access the RAM region below APP_RAM_BASE. The value of APP_RAM_BASE is obtained by calling sd_softdevice_enable
where's sd_softdevice_enable located? i can't seem to find it in my application
Hi,
morpho said:Mind elaborating on what your initial request was then? Doesn't MSP tell you the start address?
I was referring to the start address of the application in flash as a simple way to know if you use a SoftDevice. If you application starts at 0x0, you do not. If it starts at 0x1000 you are probably using the MBR only. If it start at something higher than that you are probably using a SoftDevice (which includes the MBR).
morpho said:Is 0x774 the SVC number?
No, it is within the interrupt forwarding table. It seems to be for UART0/UARTE0 (UART0_UARTE0_IRQHandler), which is enabled by default in the example project for UART logging.
morpho said:where's sd_softdevice_enable located? i can't seem to find it in my application
If you are still using ble_app_hrs_freertos() and have not removed large parts of the code, then you call sd_softdevice_enable() indirectly from ble_stack_init() by calling nrf_sdh_enable_request() (see implementation in <SDK>\components\softdevice\common\nrf_sdh.c).
