ERROR_ILLEGAL_HALL_STATE with 3 hall bldc

1

Hi and tx for your great engineering work.

I run into ERROR_ILLEGAL_HALL_STATE as well. It is a skateboard sensed bldc. The hall states encode like this when checking on arduino. In another post you say all sensor inputs being either 0 or all 1 are an illegal state. With this sensor setting it seems i cannot avoid these states. Is the motor not suited for odrive?

Tx and best

0 0 0 =0
1 0 0 =1
1 1 0 =3
1 1 1 =7
0 1 1 =6
0 0 1 =4
0 0 0 =0
1 0 0 =1
1 1 0 =3
1 1 1 =7
0 1 1 =6
0 0 1 =4
0 0 0 =0
1 0 0 =1
1 1 0 =3

2

Is it possible that somehow one of the hall sensors is inverted? If you invert the second column, it looks like the correct sequence. Do you have any circuitry between the sensor and the ODrive that could cause that?

3

I got it. However it was not straight forward to find.

I summarize in brief - Hoverboard wheel motors seem to encode different than e-skateboard motors.

Motor with 3 sensors hall sensors have six encoder states. 3 bit can however encode 8 different states totally. But two of them dont make sense. For hoverboard wheel motors this seems mostly 000 and 111 and the odrive firmware declares them as illegal.

But my e-skateboard motor this is a legal state, but 101 and 010 are illegal states.

Either i put translater in between or i will recompile the firmware as proposed down below.

4

Thx for your reply. inverting does not solve the issue. The illegal states just move up or down. you can invert any column up there. The illegal state appears somewhere else. Thx

5

no, I really think column 2 is inverted. 101 and 010 are not illegal states. Bit 2 is inverted, and these become 111 and 000 which are illegal.

Look at your table again - if you flip bit 2, then all the states are valid.

Maybe your sensor is faulty - but you can fix it with an op-amp or transistor inverter.

6

We recently added better hall encoder calibration routines to the devel branch on our github. The new calibration finds which 6 of the 8 possible hall states are expressed by your motor and then sets up the necessary parameters to convert them into the set that is valid for ODrive. It will also calibrate the phase offsets of each hall edge for better control if the alignment is slightly off.

2 Likes
7

Thanks towen. You are right. Then i get the states below. I think i dont like the cables all around and give the devel branch a try.

Tx and best

0 0 1 =4
1 0 1 =5
1 0 0 =1
1 1 0 =3
0 1 0 =2
1 1 0 =3
0 1 0 =2
0 1 1 =6
0 0 1 =4
1 0 1 =5
1 0 0 =1
1 1 0 =3
0 1 0 =2
0 1 1 =6

1 Like
8

Thank you. i pulled and flashed the latest devel branch. However odrivetool is unable to find the board then. i flashed the fw-v0.5.1 back and i can connect again to it. I do realize that with fw-v0.5.1 i do have a ttyACM0 (and much more entries on udevadm monitor -u) which i cannot remember being there on the devel branch.
Does the devel branch come up with different device setting?

Compiler version:
arm-none-eabi-gcc (15:9-2019-q4-0ubuntu1) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

Thank you

ONFIG_BOARD_VERSION=v3.6-56V
CONFIG_USB_PROTOCOL=native
CONFIG_UART_PROTOCOL=ascii
CONFIG_DEBUG=true
CONFIG_DOCTEST=false
CONFIG_USE_LTO=true

9

It should be the same. We’ve seen some issues with link time optimization, unsure of the cause. Can you try compiling again, with CONFIG_USE_LTO=false ?

Also, since you are using devel, you should use odrivetool from the repo. It’s under the tools folder.

10

done as you proposed (with LTO=true and tools/odrivetool). No luck however. tools/odrivetool doesnt seem able to find it. For some reason, something with the devel branch is closing the usb device.

When in dfu mode then i see following when plugging in and out.
@am4:~/ODrive$ sudo udevadm monitor -u
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing

UDEV [428612.750295] add /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6 (usb)
UDEV [428612.753406] add /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6/1-6:1.0 (usb)
UDEV [428612.760018] bind /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6 (usb)
UDEV [428618.519044] remove /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6/1-6:1.0 (usb)
UDEV [428618.521129] unbind /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6 (usb)
UDEV [428618.522567] remove /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6 (usb)
UDEV [428620.518401] add /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6 (usb)
UDEV [428620.520866] add /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6/1-6:1.0 (usb)
UDEV [428620.526869] bind /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-6 (usb)

when in run mode then udev monitor is completely quiet when plugging in and out.
@am4:~/ODrive$ sudo udevadm monitor -u
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing

It tells me there is a usb found but disconnected and no /dev/ttyACM or /dev/ttyUSB is mapped.

[428552.126622] usb 1-6: USB disconnect, device number 31
[428612.082552] usb 1-6: new full-speed USB device number 32 using xhci_hcd
[428612.340207] usb 1-6: New USB device found, idVendor=0483, idProduct=df11, bcdDevice=22.00
[428612.340211] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[428612.340213] usb 1-6: Product: STM32 BOOTLOADER
[428612.340215] usb 1-6: Manufacturer: STMicroelectronics
[428612.340217] usb 1-6: SerialNumber: 2081366A5753
[428618.122488] usb 1-6: USB disconnect, device number 32
[428619.850610] usb 1-6: new full-speed USB device number 33 using xhci_hcd
[428620.108129] usb 1-6: New USB device found, idVendor=0483, idProduct=df11, bcdDevice=22.00
[428620.108132] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[428620.108135] usb 1-6: Product: STM32 BOOTLOADER
[428620.108136] usb 1-6: Manufacturer: STMicroelectronics
[428620.108138] usb 1-6: SerialNumber: 2081366A5753
[428799.254546] usb 1-6: USB disconnect, device number 33

11

CONFIG_USE_LTO=false, not true.