I am getting this error when connecting my STM, how can I fix it?
Hello Ranieri
Please verify that your device is physically connected to your computer and that your device is not defective. Next, please check that the jumpers are connected as shown in the image below. Finally, click on the pencil icon and “scan” to select what target device you would like to communicate with over serial (or alternatively, use JTAG for External Mode by changing this setting in the Target–>External Mode tab).
All these steps have already been done and checked. When I change a certain configuration, PLECS reports another error. Below are the photos of the settings and the error.
In this case, if I ignore the error it gives this connection error, and if I try to build it reports the time error.
May I ask you to attach your PLECS model to see if I can reproduce the error on my system?
encoderFaseUnica.plecs (54.4 KB)
Hello Ranieri,
Thank you for attaching the PLECS model!
The problem is caused by CPU overload. The code generated for this model is too computationally heavy to execute on the selected target (STM32F303) within the discretization step size specified under Coder Options–>Scheduling.
A common way to check whether or not the code is executing on the target is to include a blinking status LED in the controller model. If the LED does not blink, the code is not executing.
There are a number of possible solutions to this issue:
- Using a more powerful microcontroller (e.g. STM32G474)
- Increasing the discretization step size if your application allows for this.
- Using multithreading to reduce the computational complexity of your controller if your application allows for this.
- Adopting a less computationally expensive controller if your application allows for this.
To optimize the discretization step size, the STM32 TSP provides a Base Task Load block. This block allows you to monitor the CPU load generated by the generated code when using single-tasking or the CPU load generated by the base task when using multi-tasking. This information is supplied via External Mode, implying that the block only works when the discretization step size is too large or optimal, but not when the discretization step size is too small. For robust operation, the CPU load may not approach 100 %. A good rule of thumb is to remain below 70 % - 80 % (or lower if using multi-tasking).
I am attaching a slightly modified version of your PLECS model. I increased the discretization step size under Simulation–>Simulation parameters…–>Initialization, added a status LED, and added a Base Task Load block to monitor the CPU load.
modifiedEncoderFaseUnica.plecs (57.1 KB)
It worked, the connection is working now, thank you very much. Now I would like to reproduce the results of the attached PLECS file using the modified file that you sent.
encoderGenerico.plecs (56.2 KB)
Hello Ranieri,
I have attached a rudimentary speed computation model that is somewhat related to the model you posted.
There are several key points that I would like to draw your attention to:
- Your model contains a triangular wave signal varying between 0 and the maximum encoder counter value. In the model attached below, we are using the Edge Counter block to count edges on a physical pin. In the simulation model, this can be represented by placing the Edge Counter block in a subsystem. When doing this, a port will appear on the subsystem in the higher-level schematic. This port represents the physical pin in simulation. The signal supplied to this port models an electrical signal whereas the output of the Edge Counter block models a software signal on an MCU. I supplied a square signal with frequency equal to the maximum encoder counter value to the physical pin. Note: Your triangular wave block can be viewed as an abstraction of this higher-fidelity model of your signal source, and a typical workflow in PLECS is to start out with a highly abstract representation of your system (e.g. using a triangular wave block to model the signal source) before moving to a higher-fidelity model!
- I explicitly modeled the trigger chain to ensure that the controller discretization is modeled accurately in the offline simulation. The code generated by PLECS Coder and the STM32 TSP is executed repeatedly on the STM32 MCU with a frequency defined by the discretization step size specified in the Coder Options menu. On the MCU, this is accomplished by using a TIM (used by the Timer and PWM blocks in the STM32 TSP), HRTIM, or ADC peripheral to generate an interrupt with the frequency defined by the discretization step size specified in the Coder Options. The trigger chain that generates this interrupt can be configured explicitly in PLECS. If the trigger chain is not modeled explicitly in PLECS, PLECS will automatically configure one, but the discretization is not always modeled correctly in the offline simulation (this is something that will be improved in a future PLECS version).
- The speed computation in the attached example is still very rudimentary and could be improved a lot. For example, the moving average filter could be replaced with a different kind of low-pass filter. Averaging a large number of samples is also quite computationally heavy, so it would likely be advantageous to adopt a large discretization step size for this part of your controller model (either by defining a large discretization step size for the entire controller, or by using multi-threading; the definition of “large” here depends on the range of speeds which you will be measuring and is not precise). Implementing signal processing of sensor read-out is the work of an engineer and there are many different design choices that one can make to accomplish this. PLECS provides tools to model and prototype different approaches to this problem, but no ready-made solutions.
rudimentarySpeedComputation.plecs (37.1 KB)