Get Task Handle from ISR with MPU.

Kernel
1

hofan-de-bosh wrote on Monday, September 16, 2019:

Hey!
I am running into a bit of a pickle here.
The main essence is. I want to check what the last current tcb was from an ISR.
The whole system runs with an MPU enabled and custom regions defined.
Now when i use xTaskGetCurrentTaskHandle it runs in the MPU wrappers which promptly try to raise privilidge. That results in a Hard Fault.

Is there a Interface i am missing? Is somethin like xTaskGetCurrentTaskHandleFromISR implemented?

BR Andy

2

hofan-de-bosh wrote on Monday, September 16, 2019:

Same with pvTaskGetThreadLocalStoragePointer/vTaskSetThreadLocalStoragePointer

3

richard_damon wrote on Monday, September 16, 2019:

Part of the issue is that you are asking for something that isn’t quite defined, an ISR doesn’t really run in the context of a task, so there isn’t a ‘Current’ task. The closest thing to that is the task that was interrupted, or maybe the task that will be returned to (which might not be known at the moment if the scheduler has been pended).

That said, if you really need to know that information (and I am not sure why you would, but I’ll trust you), I don’t think there is anything in the current API to get that, but it is something that could easily be added with the freertos_tasks_c_additions.h interface, you just need a function to return the value of pxCurrentTCB.

4

hofan-de-bosh wrote on Monday, September 16, 2019:

It has to do with knowing which function is the last that was executed before an exception started. I know it sounds weird, we use it for some debugging and for some custom system calls.

Thanks for the information, i will implement it as you suggested.

BR Andy

5

rtel wrote on Monday, September 16, 2019:

If you are in an ISR then you can only call FreeRTOS API functions that
end in “FromISR” - hence xTaskGetCurrentTaskHandle() assumes you are
outside of an interrupt running without privilege and attempts to raise
privilege (the ‘FromISR’ functions should not attempt to raise
privilege, although a few did, which have since been cleaned up).

You would need an xTaskGetCurrentTaskHandleFromISR() function, but
unfortunately there isn’t one, although you can add one easily enough as
per Richard D’s post.

6

hofan-de-bosh wrote on Monday, September 16, 2019:

Thanks for the fast and good explained support!
I worked my way around it a little bit.
I rewrote the “isPrivilidged” funtion to also consieder if we are in an ISR (reading ispr).
Then all works as I intended.

BR Andy

7

richard_damon wrote on Monday, September 16, 2019:

After I posted and saw your second question, the thought did come that maybe this was a form of Software Generated Interupt/Exception. The additions interface will be what you will need to do, and you will need to make sure that no other ISR can change the current task, which depend a lot on the port/processor you are using. Exceptions tend to be very high priority, so not a problem (but that might mean they can’t use ANY FreeRTOS calls), if the processor can’t nest an ISR inside your ISR then also not a problem. If nested ISRs are allowed, often they use a very low priority interrupt to do the scheduler, so you system call interrupt needs to have blocked that interrupt.