• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 423 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352P: Event_Post from HWI Results in Task-Switch and Failing Stack Check

J K
Prodigy 50 points
Part Number: CC1352P
Other Parts Discussed in Thread: SYSBIOS

Part of my code is running in an ISR (Hwi Thread) and it calls a function pointer that posts an Event using Event_Post . According to the SYSBIOS User Guide, it is safe to call this API from a Hwi Thread.
Before calling the Event_Post  function I disable all interrupts using Hwi_disable().  According to the User Guide, this should also disable the Thread Scheduler. (See image below)

When running my application, the Event_Post  function called from a Hwi Thread results in a Task_restore call that enables the interrupts, tries to switch the executing Task and following that a failing stack check. (Because of the comparison of wrong stacks)
I read in the User Guide that the mentioned behaviour of the *_Post functions is deliberate when a Task is calling the function:

"There is a situation in which interrupts become re-enabled when you would expect them to remain
disabled. This occurs when a Task thread calls Mailbox_post(), Semaphore_post(), or Event_post()—or
a similar call not including Swi_post()—while hardware interrupts are disabled but the task scheduler is
enabled. All XXX_post() APIs (except Swi_post()) call Task_restore() internally, which in this case ends
by calling Hwi_enable()."


Is this really the correct behaviour if I call the *_Post function from a Hwi Thread?
I suspect that I am doing something wrong here.

  • 0
    Prodigy 50 points

    Additionally, I found the following in the User Guide:

    In addition to preserving the interrupted thread's context, the SYS/BIOS Hwi dispatcher orchestrates the
    following actions:

    • Disables SYS/BIOS Swi and Task scheduling during interrupt processing
    • Automatically manages nested interrupts on a per-interrupt basis.
    • Invokes any configured "begin" Hwi Hook functions.
    • Runs the Hwi function.
    • Invokes any configured "end" Hwi Hook functions.
    • Invokes Swi and Task schedulers after interrupt processing to perform any Swi and Task operations
    resulting from actions within the Hwi function.

    I don't understand why the *_Post functions, called from Hwi result in a Task_restore call.

  • 0 in reply to J K
    TI__Expert 3886 points

    Hi J.K.

    This is a very particular question. So I'll need to look into it. I'll get back to you once I have an answer.

    BR,
    Andres

  • +1 in reply to AndresM
    Prodigy 50 points

    Hello  Andres,

    thank you for your response.
    I think I found the origin of my problem. It seems that my problem was the interrupt priority.
    ARM's NVIC in this case seems really odd. I was specifying an IRQ priority of 2 and did not recognize that this results in a Zero Latency IRQ, which is not dispatched and therefore should no call the SYSBIOS APIs like I did.

    One needs to know how the NVIC priorities are interpreted:

    For most TI MCU devices, 8 priorities are supported. A peculiarity of ARM's NVIC is that, although the priority field is an 8 bit value, the range of supported priority values are left-justified within this 8 bit field. Consequently, the 8 priority values are not 0 thru 7 as one might expect, but rather:
          0x00    // highest priority, non dispatched, Zero Latency priority
      0x20    // highest dispatched interrupt priority
      0x40
      0x60
      0x80
      0xa0
      0xc0
      0xe0    // lowest dispatched interrupt priority, (default)

    The information is available in the API doc of the ARM M3 HWI:
    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_76_04_02/exports/bios_6_76_04_02/docs/cdoc/ti/sysbios/family/arm/m3/Hwi.html (See INTERRUPT PRIORITIES and Details of config Hwi_disablePriority)

    It would may help people if this Information is available in the TI-RTOS Kernel (SYS/BIOS) User's Guide where the information I cited above is documented.

  • 0 in reply to J K
    TI__Expert 3886 points

    Hi J K,

    I'm glad that you found the origin of your problem. And thank you for the information.

    BR,
    Andres