Strange bug, sending system parameter commands in a short period of time will result in an error.

[hanke-cnc]

My host computer needs to send certain essential system parameter configuration commands every time it starts up. However, I have noticed that if there is not enough delay between each command, grblhal will return error 2. Even with a delay of 1 second, I occasionally encounter errors. This has been causing me a lot of frustration. As a result, I conducted extensive testing to identify the cause of the problem, but I have been unable to resolve it.

I have performed USB virtual serial port and serial port settings on both f401 and f407. Here are some test conclusions:

For USB virtual serial port, there is no issue with sending system configuration commands with a delay of 10 milliseconds. However, for the serial port with a baud rate of 115200, even with a delay of 1 second, occasional error 2 occurs. If the result of this configuration is the same as the original grbl settings, there is no error even with a delay of 10 milliseconds. I do not believe it is due to the communication speed of the 115200 baud rate being insufficient. I suspect it could be related to the handling of write-related settings. If the current settings are the same as the original grbl settings, there is no need to write the settings again.

The following is the test code I used to configure grbl on my host computer. There is nothing special about it. sendCommand("$110=111"); yanci(100); sendCommand("$111=111"); yanci(100); sendCommand("$112=111"); yanci(100); sendCommand("$113=111"); yanci(100); sendCommand("$114=111"); yanci(100); sendCommand("$120=111"); yanci(100); sendCommand("$121=111"); yanci(100); sendCommand("$122=111"); yanci(100); sendCommand("$123=111"); yanci(100); sendCommand("$124=111");

[hanke-cnc]

I haven't conducted tests with higher baud rates yet, so I don't believe the issue is due to the speed of the 115200 baud rate.

[terjeio]

Encapsulate a block of commands that write to NVS storage with % to delay the write until all are sent:

sendCommand("%");
sendCommand("$111=111");
yanci(100);
sendCommand("$112=111");
yanci(100);
sendCommand("$113=111");
yanci(100);
sendCommand("$114=111");
yanci(100);
sendCommand("$120=111");
yanci(100);
sendCommand("$121=111");
yanci(100);
sendCommand("$122=111");
yanci(100);
sendCommand("$123=111");
yanci(100);
sendCommand("$124=111");
sendCommand("%");

Writing to the NVS, especially flash, may disable interrupts until the erase/write cycle is completed. So either add delays or use the encapsulation method above. There is nothing I can do about interrupts beeing disabled when wrinting to flash, it is (often) a precondition for writing to flash.

Note that the STM32 family of chips are often fairly slow to handle NVS writes to flash as the flash block sizes is rather large (16 -128K). And the whole block has to be erased before each write.

FYI EEPROM will be (potentially a lot) faster than flash, FRAM even faster than EEPROM as the 5ms write delay after each block is written is not needed.

[karoria]

I learned something new! Thanks.

[hanke-cnc]

terjeio

That's awesome, Terjeio! This problem that has been bothering me for a long time is finally resolved. I'm really grateful!