QP Real-Time Event Frameworks & Tools / Bugs / #193 QXK: context switch from extended to basic thread fails

Quantum Leaps - 2017-11-29

Description has changed:

Diff:

--- old +++ new @@ -1,3 +1,3 @@ -QXK context switch from an extended thread to a basic thread (active object) fails in the QXK activate function, because the `QXK_attr_.next` thread is NULL. +QXK context switch from an extended thread to a basic thread (active object) fails in the `QXK_activate()` function, because the `QXK_attr_.next` pointer (the next AO to activate) is NULL. --MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anonymous
  
  Add attachments
  Cancel
  You seem to have CSS turned off. Please don't fill out this field.
  
  You seem to have CSS turned off. Please don't fill out this field.

Comment has been marked as spam.
Undo

View and moderate all "bugs Discussion" comments posted by this user

Mark all as spam, and block user from posting to "Bugs"

Anonymous - 2017-12-06

Hi Miro,
I have just debugged a hardfault in my simple test involving an extended thread and a basic AO. I have come to the exact same conclusion. Any idea how this can be fixed?

In qxk_port.s, the clearing of the QXKattr next pointer is relatively recent (compared to 5.7.4):

PendSV_restore_ao:
MOVS r0,#0
STR r0,[r3,#QXK_CURR] / QXK_attr_.curr := 0 /
STR r0,[r3,#QXK_NEXT] / QXK_attr_.next := 0 / // <<<---- new

Are there any side effect of removing this line?

This is a critical issue since in almost any QXK system, there will be switching between Xthread and basic AO!

Is there an old version I can safely switch back to?

Thanks
Lawrence

Hi Miro, I have just debugged a hardfault in my simple test involving an extended thread and a basic AO. I have come to the exact same conclusion. Any idea how this can be fixed? In qxk_port.s, the clearing of the QXKattr next pointer is relatively recent (compared to 5.7.4): PendSV_restore_ao: MOVS r0,#0 STR r0,[r3,#QXK_CURR] /* QXK_attr_.curr := 0 */ STR r0,[r3,#QXK_NEXT] /* QXK_attr_.next := 0 */ // <<<---- new Are there any side effect of removing this line? This is a critical issue since in almost any QXK system, there will be switching between Xthread and basic AO! Is there an old version I can safely switch back to? Thanks Lawrence

Add attachments
Cancel
You seem to have CSS turned off. Please don't fill out this field.

You seem to have CSS turned off. Please don't fill out this field.

New Attachment:

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anonymous
  
  Add attachments
  Cancel
  You seem to have CSS turned off. Please don't fill out this field.
  
  You seem to have CSS turned off. Please don't fill out this field.
- Quantum Leaps - 2017-12-06
  
  Yes, the clearing of the QXK_attr_.next pointer at this point is a bug introduced in 6.0.1. This line should be removed from qxk_port.s. But all this is already done in the QP 6.0.2-beta, which is available for download from: https://sourceforge.net/projects/qpc/files/QP-beta . Please use this one for now. The official QP 6.0.2 should be released soon.
  --MMS
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Anonymous
    
    Add attachments
    Cancel
    You seem to have CSS turned off. Please don't fill out this field.
    
    You seem to have CSS turned off. Please don't fill out this field.

Law - 2017-12-06

Thanks so much for confiming the fix. I have tried the 6.0.2 version and this issue is gone. However I ran into another hardfault by just haveing one xthread! I post an event to it before calling run(). The xthread is waken up and got the event from the built-in queue. I then dispatch the event to the composed QHsm inside a the xthread (in a class derived from it). The QHsm got the event but some time later either it got a hardfault or assert when calling get from the queue again. Looks like memory is corrupted. The only other thing that's going on is the systick timer. Maybe the interrupt restore still has an issue. I will investigate further.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anonymous
  
  Add attachments
  Cancel
  You seem to have CSS turned off. Please don't fill out this field.
  
  You seem to have CSS turned off. Please don't fill out this field.
- Quantum Leaps - 2017-12-06
  
  No, you cannot use an extended thread as an active object with an internal state machine, because the extended thread uses the inherited attributes designated to HSM in the superclass for different purposes. You can, however, have an QHsm component ("Orthogonal Component") inside an extended thread. You can dispatch events to that QHsm component from the extended thread.
  --MMS
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Anonymous
    
    Add attachments
    Cancel
    You seem to have CSS turned off. Please don't fill out this field.
    
    You seem to have CSS turned off. Please don't fill out this field.

Quantum Leaps - 2017-12-12

status: open --> closed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anonymous
  
  Add attachments
  Cancel
  You seem to have CSS turned off. Please don't fill out this field.
  
  You seem to have CSS turned off. Please don't fill out this field.

Quantum Leaps - 2017-12-12

Fixed in QP/C/C++ 6.0.3.
--MMS

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anonymous
  
  Add attachments
  Cancel
  You seem to have CSS turned off. Please don't fill out this field.
  
  You seem to have CSS turned off. Please don't fill out this field.

QXK: context switch from extended to basic thread fails

Real-Time Event Frameworks based on active objects & state machines

Group

Searches

Help

#193 QXK: context switch from extended to basic thread fails

Discussion