[ESP32S2, ARDUINO] MOTOR SKIPS EVERY 2 SEC, EVEN IN OPEN LOOP[BUG]

[rm2488]

Describe the bug The motor skips approx every 2 seconds, in open loop as well as closed loop.

Describe the hardware setup

• Which motor - 1.8 degreee stepper

• Which driver - Custom 4PWM driver

• Which microcontroller - ESP32S2

• Which position sensor - Irrelevant

• Current sensing used? - NO

• Arduino IDE

While I am submitting a bug report, I already have a solution, so please forgive me if this is in the wrong place. There may be better solutions out there.

I investigated everything (Including a lot of time looking at the total angle stored as float precision issue) until it hit me-

this code has the glitch- (paraphrasing for clarity)

**void setup() { do_setup(); }

void loop() { motor.loopFOC(); motor.move(); motor.monitor(); command.run(); }**

This one fixes it:

**void setup() { do_setup(); while(1) { loop(); }; }

void loop() { motor.loopFOC(); motor.move(); motor.monitor(); command.run(); }**

Effectively equivalent to placing the contents of the loop function in the while loop. Therefore, the loop function never runs as a task in FreeRTOS. Otherwise there is apparently some delay between loops from time to time.

This issue is explored here: https://www.reddit.com/r/esp32/comments/t9aqr6/what_on_earth_is_my_esp32_doing_between_loops/

It may be specific to the ESP32S2, and there may be other repercussions to my workaround.

EDIT: To be clear, this is an issue with the Arduino IDE, and not SimpleFOC

[runger1101001]

Hey, thank you for reporting this.

May I ask, are you using any of the chips radio functions like BLE or WiFi in your code? Or is it just SimpleFOC with no other functions?

It's certainly an interesting finding, and important for us as many people do use ESP32. I wonder why it has not been reported before? Can you think of something unique in your setup that could be causing it?

[rm2488]

Hey, thank you for reporting this.

May I ask, are you using any of the chips radio functions like BLE or WiFi in your code? Or is it just SimpleFOC with no other functions?

I am using WiFi in AP mode to configure the device. However, given the limited power supply (more about thermal limit) capability of the board and to ensure that SimpleFOC runs close to real-time, it is an either-or case: a button state is read on startup, which branches into either one of two sequences:

1. (BUTTON NOT PRESSED)- Init FOC, do not init WiFi. Then the rest of the control functions for the board run as per application requirement.
2. (BUTTON IS PRESSED)- Init FOC, then disable motor driver, then init WiFi. The loop now runs only loopFOC() and WiFi functions, so that comm with the encoder is maintained and angle is updated. This allows me to use the shaft angle (used to configure the hardware for the required application- the shaft is actually turned by hand and I need to track the rotation). The ESP is restarted over WiFi once config is completed.

It's certainly an interesting finding, and important for us as many people do use ESP32. I wonder why it has not been reported before? Can you think of something unique in your setup that could be causing it?

My setup is itself fairly unique- it is a custom 4 layer board, directly using the ESP32S2FH4 chip, instead of a module or devkit (space was a premium on the board, and I did not want to add external flash). However, I think the issue has its root somewhere in how the arduino uses the IDF and RTOS behind the scenes.

This board was certainly a first for me in many ways- 4 layers, design of onboard antenna, using WiFi, using bare chip, as well as being my first ever implementation of SimpleFOC. Hence my implementation was also step wise- I implemented SimpleFOC before moving on to WiFi, and the issue has been present since day 1, when the WiFi code was not even included.

If it were the hardware, simply relocating the loop() to the end of setup would not have solved the problem. I looked at almost everything- the use of LEDC instead of MCPWM on the S2, the particular encoder I am using (TLE5012B - turning off prediction mode helped somewhat), changing the processor frequency(no effect), changing the PWM frequency (no effect on this issue). Perhaps someone who has implemented FOC on an S2 can test- I am fairly certain that the issue would likely not be apparent on a BLDC- the high pole pair count of a stepper likely makes it more sensitive to timing glitches.