Menu

Global variable, QF_readySet_, not initialized in QDK/C-TMS320C28x-C2000

Full name
2015-05-27
2015-05-27
  • Full name

    Full name - 2015-05-27

    I may be mistaken, but the global variable, QF_readySet_, is not initialized to zero in QDK/C-TMS320C28x-C2000. I found this out because I kept catching Q_onAssert in qhsm_init.c at line 53, where Q_REQUIRE(t == me->temp) fails.

     
  • Quantum Leaps

    Quantum Leaps - 2015-05-27

    The TI C2000 startup code fails to clear the uninitialized data (.bss section), which is in violation of the C Standard.

    As a workaround for such non-compliant initialization, the QF_init() function has been specifically modified to explicitly clear all internal QF variables, such as QF_readySet_. However, this workaround has been implemented in QP5 and is not available in QP4.5.x.

    I understand that the QDK/C-TMS320C28x-C2000 has not been officially ported to QP5 yet and therefore you are forced to use the older QP4. The upgrades of official ports to TI C28 and C55 are planned, but are not available yet. Hopefully, the next QP/C release will provide them.

    --MMS

     

    Last edit: Quantum Leaps 2015-05-27
    • Quantum Leaps

      Quantum Leaps - 2015-05-27

      OK, I have looked a bit deeper into the QDK/C-TMS320C28x-C2000, and this QDK has a workaround for clearing the .bss section. Specifically, the qf_port.c file has a function called QF_zero(). But I agree that this function fails to clear the QF_readySet_ variable. So, the following snippet shows the corrected QF_zero(), which you can copy-and-paste into your file ports\tms320c28x\vanilla\c2000\src\qf_port.c:

      void QF_zero(void) {  /* see NOTE01 */
          extern uint8_t QF_intLockNest_;
      
          QF_intLockNest_     = (uint8_t)0;
          QF_maxPool_         = (uint8_t)0;
          QF_timeEvtListHead_ = (QTimeEvt *)0;
          bzero((uint8_t *)QF_active_, sizeof(QActive*)*(QF_MAX_ACTIVE + 1));
          bzero(&QF_readySet_, sizeof(QF_readySet_)); /* <== */
      }
      

      On a side note, please remember that this workaround does not clear your application-level variables, so there might be some ticking bombs in there. You need to be very careful, because such problems are notoriously difficult to find through testing. The garbage inside un-initialized variables might just happen to be harmless. There is a good reason for the C-Standard to require clearing of the entire .bss!

      --MMS

       
  • Full name

    Full name - 2015-05-27

    Thank you for the quick, thorough reply.

     

Log in to post a comment.

MongoDB Logo MongoDB