Skip to main content
brubinstein
brubinstein
Associate II
December 24, 2014
Question

Hard fault on os_tsk_self()

  • December 24, 2014
  • 2 replies
  • 866 views
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
    This topic has been closed for replies.

    2 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    December 24, 2014
    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.
    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    brubinstein
    brubinsteinAuthor
    Associate II
    December 28, 2014
    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.
    Terms & ConditionsAccessibility statement