Hey guys,
So I just updated my boards’ firmwares to 5.2 and am suddenly running into a ENCODER_ERROR_ILLEGAL_HALL_STATE error on both of them. I connected an oscilloscope to the A B and Z lines and they move as I turn the motor. The connections are also the exact same as they were when my system worked in firmware 5.1. Was anything changed that may have caused this?
Hi,
can you observe that shadow_count on axis0 remains 0 while hall_state is changing? I ran into the same issue, after upgrading from a very old firmware to 0.5.2. reverting to 0.5.1 solved the issue, but introduced others (related to 0.5.1 and not having the proper documentation for the older firmware)
Kind regards,
Tim
@timoldenb That’s interesting! It could be a configuration bug then.
You could try backing up and erasing your config.
odrivetool backup-config borked_config.json
odrv0.erase_configuration
At the same time you could also update the firmware to 0.5.3
I wonder if this could be @JacksonMarkow’s problem too, from Illegal hall state error - #5 by towen
Btw, you can find the older documentation here: ODrive/docs at fw-v0.5.1 · odriverobotics/ODrive · GitHub
thanks, I was sure that it will be somewhere in the git repo but had no time to search for it yet 
Hey @towen ,
In my scenario, I frequently used the erase_configuration to be sure not to have older config artifacts and work with a default setting config provided by the firmware. I posted my experiences in another thread: Error in Firmware - shadow_count - #3 by timoldenb
I cannot say if the original post is caused by the issue I am having here. I cannot replicate it yet as I do not have another controller to compare, but I have had 6 different motors and cable sets
Greetings from Switzerland,
Tim
I recently had this issue happen on 2 more oDrives so it’s a bit more serious than I first thought. Right when I update firmware using odrivetool dfu, they throw hall state errors after hall polarity calibration step, even in the exact setup as before where my system worked. Extremely confused. I have eliminated EMI noise too with ferrites and 22nf capacitors
So, I have spun up a hoverboard motor with Hall sensors on a power supply, and I think I have replicated this issue.
I found that at first, despite ferrites, twisted wiring, separation of encoder and power cables etc, I needed to add capacitors otherwise I would get ILLEGAL_HALL_STATE even to enable the motor at 12V with zero current demand.
After adding capacitors, it spins merrily up to about 20V, but if I go higher then I get ILLEGAL_HALL_STATE. But I haven’t been able to capture an illegal state on the liveplotter.
If I set encoder.config.ignore_illegal_hall_state then obviouslt I can go higher - this is a transient issue after all. But at around 40V, I can hear that something is wrong.
If I open the liveplotter, then I can still see no illegal states, but something is wrong - I would expect the distribution of Hall states to be uniform - i.e. a noise signal (it’s spinning way too fast for the liveplotter sampling) but with equal probability for each of the six valid Hall states.
Instead, I get this:
So I got out the scope, and it’s pretty obvious what’s going on: The capacitors that I added aren’t helping at all - the rise time of the signal is much too slow, so it takes about 2ms to reach 3.3v.
Without the capacitors, it’s a lot quieter, draws less from the power supply, and the liveplotter is correct.
There is some noise, obviously (as it still doesn’t work without ignore_illegal_hall_state) but the noise is only at the ‘logic high’ state.
So, I think that these particular Hall sensors would benefit more from stronger pullup resistors than they would capacitors.
