Odrive suddenly loses complete configuration

Hello,

I am using 2 odrives v3.6 54V with firmware RC 0.5.1. The commands are send via ASCII on UART with a MCU.

The problem is that the configuration sometimes is completly wiped. Everything is back to stock values and it needs to be reconfigured.
This is really anoying since it can happen after a powercycle of after the MCU is being reset.

What could be the problem?

Are you by any chance accidentally sending se\n down the serial port? (i.e. the “Erase config” command)

No, that is never being send. The other system commands are also not being send

Is there any other command that you are sending that could somehow be corrupted into this?

I’m not very familiar with the ASCII protocol (I prefer to use either USB or CAN) but is there any way to turn on “remote echo” so that you can see what the ODrive received?

There is no other command being send that looks like se\n
The ASCII protocol does not have a option to enable “remote echo”. It needs to be added in firmware

You could edit the firmware and comment out the definition of the se command, to be absolutely sure that it isn’t being triggered somehow.
You’d just need to open Firmware/communication/ascii_protocol.cpp and comment out the lines

        } else if (cmd[1] == 'e'){ // Erase config
            odrv.erase_configuration();

Is there another way that the odrive can reset its config? ASCII is not the culprit

Did you try the above firmware modification and it still loses config?
If not, please try it, and see if your problem “goes away”.
It’s possible that “sr” has only 1 bit difference to something that you are sending regularly, and therefore some corruption induced by noise is causing this. There’s no CRC on the ASCII protocol, that’s part of the reason I don’t like it.
I can’t think of any way that the config could return to its default values except by an erase config command.

If the data is corrupted it will fail CRC and load the default config.