Here is a partial answer:
The motor outputs M1-M4 (and also their O1-O8 counterparts), are controlled primarily by firmware code that runs on the real-time Cortex-M4 processor inside the TXT 4.0. On the other hand, your Python program (or your Blockly program translated to Python) runs on the Cortex-A7 processor under Linux.
If your Python program on the Cortex-A7 processor does not send a stop command to the Cortex-M4 firmware (using Motor.stop() or some such call), perhaps because the program crashed or was terminated before it had a chance to do so, then the motor or output might not be reset.
There is a safety mechanism: when the Motor or EncoderMotor Python instance is released, then the lower-level C library that implements the communication with the Cortex-M4 side resets the "in use" flag for the motor(s) that your application used, which will eventually cause the Cortex-M4 firmware to reset those outputs.
However, all that communication is a bit fragile, so it is possible that under some circumstances it simply doesn't happen. In that case --and your description sounds like it-- the Cortex-M4 firmware doesn't know that the motor should be stopped and leaves it running.
In other words: it is not necessarily a question of "processes not being stopped"; it might just as well be that your visible (Linux/Cortex-A7) application process is stopped, but that the Cortex-M4 side was never informed that the motor or other output is no longer used.
If you would like to read more about this, then please check out my new book about the TXT 4.0 internal operation.
- Chapter 4 is the general software overview: Cortex-A7 versus Cortex-M4.
- Chapter 9 is about the motor and general outputs.
- Chapter 14 explains how the low-level C functions communicate with the Cortex-M4.
- Chapter 26 is about the Python Motor classes.
The eBook version can be freely downloaded from
https://tarma.com/embedded/txt4book
Hope this helps,
-- David
Hinweis: Ich poste auf Englisch, kann aber Deutsch lesen, Sie können also auf Deutsch antworten.