I have a strange problem which I believe should not be happening. I have a parent state "P1" which has 2 child states "C1,C2" and the one child has a child which I will call Grand Child 1 "GC1". The assertion occurs when the child C1 tries to transition to G1. The behavior that I would expect is that an exit to occur from C1 prior to an entry into C2 and then an entry into G1.
I have checked for malformed states.
Does anybody have a suggestion on why this is occurring?
You didn't state it explicitly, but I assume that GC1 is a child of C2, not C1? And C1 and C2 are peers?
Also, presumably you are using the QM modeling tool, correct? If so, could you please post the model? Your post's body just says "strange problem" but the nature of the problem isn't clear. The title talks about an assertion, the body talks about a state not being exited...
Basically, more info (in the form of a model) would be helpful, thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The assertion qhsm_dis#220 fires when the QEP event processor discovers state nesting that is too complex (more than 6 levels of nesting or so). This typically is indicative of a coding error. For example, you might have a circular nesting (e.g., state G1 nested in C1 nested in P1 nested in G1 again). Please check the arguments of your Q_SUPER() macros in your code.
Of course, if you would use QM, such coding errors would never happen...
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suspect you might have a copy & paste error in one of your Q_SUPER() macros, or perhaps a Q_TRAN() in an entry or exit action.
Any chance you could post the code? I realize it might a little sensitive, but otherwise this is all just speculation, it's hard to say where the problem lies.
Alternatively we could try drawing (modeling) it in QM & generating code, and you could compare the generated code to your code. (Since you're not using QM, I assume you're not using the QMSM base class, but the normal QHSM. QMSM is essentially a QM-only feature...)
P.S. Regarding the modeling tool -- I hand-coded QP state machines for 10 years, I know how to do it, I'm comfortable doing it, etc. But that said, now with the QM modeling tool, I'm spoiled, I'll never go back to hand-coding ;-) I suspect whatever issue you're facing would be absent if you were using the QM & code generation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you "flatten" your HSM to contain less nesting levels;
you increase the constant QHSM_MAX_NEST_DEPTH_ in qep_pkg.h header file (inside the qep\source directory) and recompile the QP library. Please note that by increasing the nesting level, you will use a bit more stack space for calling QHsm_dispatch().
you switch to the QMsm or QMActive base classes, which do not have the limitation on the state nesting level. This would require you to use the QM modeling tool...
Personally, I would recommend switching to QM, and if this is not an option, to "flatten" your HSM.
--MMS
Last edit: Quantum Leaps 2014-11-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a very old post, but upgrading my project to qpcpp v7.3.3 exposed this (almost exact) problem 10 years later (Cortex-M4 project). I thought I'd point this out in case anyone else runs into the same issue. And I apologize if anyone already raised this (I did search for it but couldn't find anything related).
I hit the qep_msm:310 assertion, meaning I had hit the nesting limit as well. I have to clarify, I hit the second assert on line 233, because, unfortunately, there are two asserts that use the same value (not uncommon in the QP code base, and perhaps for good reason).
I use QM to model my tool, so I reckon the second statement above is no longer valid (about QMsm/QMActive not having this limitation). Or, what is this assert trying to tell me in this particular situation?
I also found that it's acceptable to increase the constantMAX_NEST_DEPTH_. I tried this and it solved my problem (I only increased its value by 2, which matches the level of nesting).
Cheers,
Sander
Last edit: Sander Huijsen 2024-08-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The assertion IDs should be unique (mostly), so this will be fixed.
Regarding the limits on state machine complexity, they are now enforced more strictly as part of the functional safety updates. Specifically, now all loops must have a numerical upper bound. The currently limits can be increased slightly but the formal testing will be limited to what is provided in the official code. I hope this makes sense to you.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a strange problem which I believe should not be happening. I have a parent state "P1" which has 2 child states "C1,C2" and the one child has a child which I will call Grand Child 1 "GC1". The assertion occurs when the child C1 tries to transition to G1. The behavior that I would expect is that an exit to occur from C1 prior to an entry into C2 and then an entry into G1.
I have checked for malformed states.
Does anybody have a suggestion on why this is occurring?
QEP Version: 5.30
Processor: Microchip dsPic33
Compiler: XC16
Last edit: KJC 2014-11-14
You didn't state it explicitly, but I assume that GC1 is a child of C2, not C1? And C1 and C2 are peers?
Also, presumably you are using the QM modeling tool, correct? If so, could you please post the model? Your post's body just says "strange problem" but the nature of the problem isn't clear. The title talks about an assertion, the body talks about a state not being exited...
Basically, more info (in the form of a model) would be helpful, thanks.
I'm sorry, you are correct. GC1 is a child of C2 and C1 and C2 are peers.
No, I am not using QM. The code is in "C".
The assertion qhsm_dis#220 fires when the QEP event processor discovers state nesting that is too complex (more than 6 levels of nesting or so). This typically is indicative of a coding error. For example, you might have a circular nesting (e.g., state G1 nested in C1 nested in P1 nested in G1 again). Please check the arguments of your Q_SUPER() macros in your code.
Of course, if you would use QM, such coding errors would never happen...
--MMS
I suspect you might have a copy & paste error in one of your Q_SUPER() macros, or perhaps a Q_TRAN() in an entry or exit action.
Any chance you could post the code? I realize it might a little sensitive, but otherwise this is all just speculation, it's hard to say where the problem lies.
Alternatively we could try drawing (modeling) it in QM & generating code, and you could compare the generated code to your code. (Since you're not using QM, I assume you're not using the QMSM base class, but the normal QHSM. QMSM is essentially a QM-only feature...)
P.S. Regarding the modeling tool -- I hand-coded QP state machines for 10 years, I know how to do it, I'm comfortable doing it, etc. But that said, now with the QM modeling tool, I'm spoiled, I'll never go back to hand-coding ;-) I suspect whatever issue you're facing would be absent if you were using the QM & code generation.
It appears that I hit the 6 levels of nesting limit.
At this point you have two options:
you "flatten" your HSM to contain less nesting levels;
you increase the constant
QHSM_MAX_NEST_DEPTH_inqep_pkg.hheader file (inside theqep\sourcedirectory) and recompile the QP library. Please note that by increasing the nesting level, you will use a bit more stack space for callingQHsm_dispatch().you switch to the
QMsmorQMActivebase classes, which do not have the limitation on the state nesting level. This would require you to use the QM modeling tool...Personally, I would recommend switching to QM, and if this is not an option, to "flatten" your HSM.
--MMS
Last edit: Quantum Leaps 2014-11-14
This is a very old post, but upgrading my project to
qpcppv7.3.3 exposed this (almost exact) problem 10 years later (Cortex-M4 project). I thought I'd point this out in case anyone else runs into the same issue. And I apologize if anyone already raised this (I did search for it but couldn't find anything related).I hit the
qep_msm:310 assertion, meaning I had hit the nesting limit as well. I have to clarify, I hit the second assert on line 233, because, unfortunately, there are two asserts that use the same value (not uncommon in the QP code base, and perhaps for good reason).I use QM to model my tool, so I reckon the second statement above is no longer valid (about
QMsm/QMActivenot having this limitation). Or, what is this assert trying to tell me in this particular situation?I also found that it's acceptable to increase the constant
MAX_NEST_DEPTH_. I tried this and it solved my problem (I only increased its value by 2, which matches the level of nesting).Cheers,
Sander
Last edit: Sander Huijsen 2024-08-16
Thanks for reporting.
The assertion IDs should be unique (mostly), so this will be fixed.
Regarding the limits on state machine complexity, they are now enforced more strictly as part of the functional safety updates. Specifically, now all loops must have a numerical upper bound. The currently limits can be increased slightly but the formal testing will be limited to what is provided in the official code. I hope this makes sense to you.
--MMS
Thank you, Miro.