Q_TRAN transitioning to itself instead of specified state?

[KJC]

I having issues with transitioning from one state to another after receiving and processing a subscribed signal. I have noticed that the me->super.super.temp.func pointer is being filled with the current state after the Q_TRAN macro is called? Can anyone provide when a sugestion on what could be happening? The code snippets are provided below. The problem occurs when the SAVE_TOOL_CFG_SIG is processed. Instead of transitioning to the CfgMgrSaveState state it transitions back to the CfgMgrIdleState state. I believe that soemthing is getting corrupted.

/ states /
QState CfgMgrInitState (AO_CfgMgr_t * const me, QEvt const * const e);
static QState CfgMgrHwInitState (AO_CfgMgr_t * const me, QEvt const * const e);
static QState CfgMgrIdleState (AO_CfgMgr_t * const me, QEvt const * const e);
QState CfgMgrSaveState (AO_CfgMgr_t * const me, QEvt const * const e);
static QState CfgMgrCrcWriteState(AO_CfgMgr_t * const me, QEvt const * const e);
QState CfgMgrRestoreState (AO_CfgMgr_t * const me, QEvt const * const e);
static QState CfgMgrCrcReadState (AO_CfgMgr_t * const me, QEvt const * const e);

...

/........................................................................../
QState CfgMgrIdleState(AO_CfgMgr_t * const me, QEvt const * const e)
{
switch (e->sig)
{
case Q_ENTRY_SIG:
{
return Q_HANDLED();
}

  case SAVE_TOOL_CFG_SIG:
  {
     return Q_TRAN(&CfgMgrSaveState);
  }

  case LOAD_TOOL_CFG_SIG:
  {
     return Q_TRAN(&CfgMgrRestoreState);
  }

  case Q_EXIT_SIG:
  {
     return Q_HANDLED();
  }

}
return Q_SUPER(&QHsm_top);
}/ end of CfgMgrIdleState /

[KJC]

I am using the microchip XC16 ver 1.23 compile, optimization is off
QP 5.3.0

[Quantum Leaps]

I would check the target state CfgMgrSaveState and all its superstates (ancestor states). If any of these states are coded incorrectly, the QEP event processor might get confused.

BTW, it seems that you still use the older way of coding state machines, which is not compliant with the MISRA rules for the switch statement. I would recommend that you take a look at the freeware QM modeling tool and try to generate code automatically. The QP baseline code distro contains plenty of model examples that you can simply try in a couple of minutes. The updated QM help is available at:

http://www.state-machine.com/qm/help

(The help is still under development, but should be already quite useful).

--MMS

[KJC]

Is there a way to verify where the Q_MSM_UPCAST(me))->temp.fun macro is writing too?

[Quantum Leaps]

I'm not sure that I understand the question, because the macro Q_MSM_UPCAST is not "writing" anywhere.

The macro Q_MSM_UPCAST is not used anywhere inside the QP/C or QP-nano source code and is only needed at the application level to encapsulate a MISRA rule violation. The macro is documented here:

http://www.state-machine.com/qp/qpc/qep_8h.html#a02785363be76278f9215a0bab212e445

[KJC]

Also, how do you feel about creating the object outside of the constructor ans passing a ptr to the object when calling the constructor?

ie

void CfgMgr_ctor( AO_CfgMgr_t * const me, TOOL_CFG *cfg )
{
QActive_ctor(&me->super, (QStateHandler)&CfgMgrInitState);
QTimeEvt_ctorX(&me->timer_, &me->super, TIMEOUT_SIG, 0U);
me->cfg_ = cfg;
crcInit();
}

....

main file

static AO_CfgMgr_t AO_config_manager;

CfgMgr_ctor(&AO_config_manager, &toolCfg);

[Quantum Leaps]

That's fine and probably even more "correct". Such a constructor with the "me" pointer is then a member of its class.

I attach a screen shot from QM that shows a "CfgMgr" class with the "ctor" operation.

And here is the code QM generated for this:

/*${Components::CfgMgr} ............................................*/
typedef struct {
/* protected: */
    QActive super;
} CfgMgr;

/* public: */
static void CfgMgr_ctor(CfgMgr * const me, TOOL_CFG * cfg);

/*${Components::CfgMgr} ............................................*/
/*${Components::CfgMgr::ctor} ......................................*/
static void CfgMgr_ctor(CfgMgr * const me, TOOL_CFG * cfg) {
    QActive_ctor(&me->super, Q_STATE_CAST(&CfgMgr_initState));
    QTimeEvt_ctorX(&me->timer_, &me->super, TIMEOUT_SIG, 0U);
    me->cfg_ = cfg;
    crcInit();
}

[KJC]

It turns out that it was the MPLABS debugger causing the problem.

thx for answers and support