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.

CCS/LP-CC2652RB: HWI Maintenance to mitigate Error_policyMin Hard Fault: FORCED: BUSFAULT: IMPRECISERR

Part Number: LP-CC2652RB

Tool/software: Code Composer Studio

I have 2 hardware interrupts enabled that post to binary semaphores (one at 250Hz, the other at 25Hz, operating on SPI and I2C ports respectively). My heap is 0x2000 and I've tried to increase the HWI stack size from 1028 to 2048, but my project still ends up at Error_policyMin with an exception after about a minute. I'm not sure how to interpret the exception below.

Task stacks and HWI stack appear to be padded with 0xBE.

  • I guess I'll try to answer my own question here with some direction.

    • 2.2 Debugging Common Application Issues with TI-RTOS was a helpful error primer
    • The SYS/BIOS docs on errors was helpful
    • Pausing the device at Error_policyMin() and checking ROV Viewer > BIOS Module > Scan for errors... easily identified an HWI overflow exception
      • The HWI Module/Exception tabs had some indication (i.e. address) of the task where the exception occurred
      • The real money is in the Task module, where stackPeak was 508 for my xlTaskFcn (after the exception) and the stackSize was 512
      • I increased that task's size to 1024, now it peaks at 528, and no exception has occurred after many minutes

    What I still don't understand is how a task eats the stack over time. I'm not creating new variables as time goes on (only modifying global buffers using pointers). If I wanted to run this project for a year, how would I begin to estimate my stackSize? Understanding how the stack accumulates and asymptotes would be helpful.

  • Hi,

    Nice work with debugging :)

    If the application works properly (i.e. if the code is correct) the stack used should not increased indefinitely. A continuously growing stack size is the sign of a memory corruption (probably some malloc not properly freed).

    In your case, it does not look like this. The tools measuring the stack peak do not work properly when the stack is overflowing. I would recommend to run the system for a while with the proper stack sizes and see if you can have a fixed stack peak.

    Keep us updated!

    Kind regards,