Hard fault on os_tsk_self()

[brubinstein]

Posted on December 24, 2014 at 06:38

Don't really know what else to say.

I'm using uVision4.74 and RTX. Please don't suggest to switch to uVision 5 and CMSIS-RTOS RTX. This line is a part of a function that was called many times before, so it is not this but what? Where to dig? How? At the point of failure I just initialize I2C BEFORE RTX was started inprivileged mode. Will appreciate your help. Thanks.

This is the line of code that brings me trouble:

OS_TID rtx_id;
/******/
rtx_id = os_tsk_self();

#rtx-hard-fault

[Tesla DeLorean]

Posted on December 24, 2014 at 16:50

Perhaps it's not the code itself that's the problem, but rather a data structure it acts upon. Like a corrupt heap,or overrun stack? They almost always occur because you are accessing some unavailable memory, or attempting to execute some incorrect code.

Trace the disassembly view, not the source view. Use a proper Hard Fault handler that provides information about the registers, and processor state at the fault site, and then review why that combination caused the fault, and why they got to be that way.

[brubinstein]

Posted on December 28, 2014 at 02:56

here is the function which somehow causing this issue:

bool lock (volatile bool *lock) {
bool ena, tmp;
ena = __disable_irq();
tmp = *lock;
*lock = true;
if (ena) __enable_irq();
return (tmp == false);
}

Don't understand why and what could be wrong here...Simple atomic operation.