iCubGenova09 (iRonCub3) S/N:000 – Error with iRonCub where BAT goes in HSM HW fault while walking

[MSECode]

Robot Name 🤖

iCubGenova09 (iRonCub3) S/N:000

Request/Failure description

As pinged by @antonellopaolino, we have noticed that while walking iRonCub robot goes in HW fault.

Detailed context

Specifically the motors are switched off due to an error of HSM HW Overcurrent triggered by the BAT board and visible both on the robot display and on the logs of the battery/bat/data:o port.
As you can see from the following image, the screen is showing that the HW fault error related to the HSM (Hot Swap Manager ) has been risen.

Moreover, by looking at the yarp port where we are streaming the BAT data at a certain point the status value (rightmost entry) changed from 172 (al good) to 1158 --> 1156 --> 1152 (HSM HW FAULT). This status value is a 16bit number shown in decimal on the port. In order to see which are the status and error bits risen to 1 you can check the meaning of the status value here: https://icub-tech-iit.github.io/documentation/battery_boards/bat_board/bat_board/#types-of-data-transmitted
Looking at that part of the documentation it is easier to understand the meaning of the decimal value of the status.

Analyzing those data, I suppose that the error is due to an overcurrent (higher that 50A) that triggers the GPIO PIN on the BAT related to the FAULT of the HSM. This spikes of current is such fast that the HSM SW Fault (set to 38A of overcurrent) never rises. Furthermore, we cannot read the spike from the logs since we cannot stream the data with a frequency higher enough to catch that spike (we should use current probes eventually with an oscilloscope).
If you are interested the part of BAT fw responsible for catching the fault is this: https://github.com/robotology/icub-firmware/blob/master/emBODY/eBcode/arch-arm/board/bat/BAT_Rev_B/Src/main.c#L338-L349
and as you can see, being an HW trigger that comes from the GPIO, we are quite sure that it is not a false positive and that we actually have a spike.
Understanding which is the core cause of this OC is more complicated. However, since that is coming from an HW trigger, as said, I suppose it can be due to a component on that BAT that is damaged, most likely a mosfet or a diode near it, or even the shunt, which if it is even slightly damaged it can have false readings.
For now I'll not ping everyone. Let's try to analyze the problem and when we have a more clear idea we can ask support from proto.

cc: @valegagge @andresoll

Additional context

No response

How does it affect you?

No response

[antonellopaolino]

cc @gabrielenava