Microcontroller ARM burnt


#1

Hi,

One week ago I tested the new ODrive 3.4 with one motor and with commands over USB/UART.
So was connected on the board : alim, M0, resistor, encoder, STlink, gpio 1 and 2 for UART. All was ok.

Yesterday I wanted to reiterate tests with the same configuration,firmware, programs but impossible to activate UART. However USB was operational.

Today I decided to try again with the last firmware but nothing and without explanation the microcontroller broke down : ARM is hot and the board cosumes 6W with nothing wired on.

I thing the microcontroller is dead and have to be changed. Something caused this issue but I don’t know what, apart to flash the ARM and to restart the ODrive many times I dont thing to have done « extreme operations”.


#2

That is unfortunate, let’s see if we can figure out what may have caused it. Do you have the facilities to replace the microcontroller?

What is “alim”? What other device was connected on the UART? Did you connect GND as well as GPIO 1,2? What gnd pin did you use for that?


#3

Yes somebody will can change it for me. I want to unmount the ARM first and see if the driver M0 is ok before to replace the microcontroller.

I use a 12V power source (alim). I connect an STM32F1(maple mini or bluepill) to communicate via UART, this one is connected to my laptop by USB. I connect the ODrive to the laptop either by USB or by the STlink in order to have the GND. Is it a good way to do ?


#4

Hm, it is important to always have a GND together with the UART lines. Improper grounding can inject current in the GPIO pins, and break the microcontroller. Sorry if that wasn’t clear, I have added the info about grounding on the getting started instructions.


#5

The Odrive has been fixed, now it works !
Communication by USB is OK. I tried UART by following your advice, I can send orders but I haven’t callback. I have to investigate deeper to understant.

Thanks


#6

Since the issue with the ARM I have a random error that appear : n°20 (nFAULT) . This error come from the driver 8301. I saw that the nFAULT errors can be read in the status register of the DRV8301 .
Is it possible to access to this register in order to have the detail of the error ?


#7

Yes you should be able to read the registers to check. But we don’t have the code there to automatically read it when there is a fault. You can add this if you want. You can use the same functions we use in DRV8301_setup to read from the DRV.


#8

I succeeded to isolate the problem but I don’t know why I have the NFault error. I tried to read the errors in the register but no error detected. The two nFault of the drivers are common and only few errors are detailled in the DRV register.

The only way I found to can work with the Odrive is with the motor 0 and the driver 1 desactivated .

DRV8301_setup(&motors[0]);
//DRV8301_setup(&motors[1]);

If not I have the nFault error that appear .

Now if I connect the motor 1 only with the same parameters and with :

DRV8301_setup(&motors[0]);
DRV8301_setup(&motors[1]);

the motor vibrates during the calibration but I don’t have any errors… All this is very strange moreover I never used the motor 1 before.

In the next days I would like to remove the driver of the motor 1 and run only the motor 0.


#9

That does indeed seem very strange. Better than removing the DRV chip is to just cut the nFAULT line from M1 side: removing the DRV can possibly let the FETs conduct randomly, since there will be nothing holding their gates down.


#10

Finally we found the cause : bad welding between the ARM pins and the board . We fixed the connections and now the board work perfectly.

Thanks for the support.