many component failures - ESP32 alternatives

goosst

New member
I don't think I did anything wrong with usage of the robot (did some somewhat successful trials yesterday on the lawn).
However this morning when powering up a major amount of components failed:
  • IMU was broken (replaced it with a spare component I've had and works again)
  • ESP32 was broken, didn't get connected to internet anymore
  • constantly get motor driver errors now
  • the start-stop button already didn't work anymore
  • who knows what else I don't know yet ...
  • (good thing the ntrip board still seems to function at first sight)
Maybe the 5V supply got a major spike ?
I'm really not convinced about this whole charging logic to be honest and this doesn't increase trust.

  1. Are there similar experiences of such failures? If so, any clue how to avoid it?
    What is the maximum voltage the board can handle? Can it be because of a crappy charger?
  2. Since my ESP32 is dead, are there any known to work variants with antenna and integrated camera (ESP32-CAM)?
  3. Any known drop in replacements for this MC33926 motor driver (even just to have as spare part so the mower isn't down for weeks). The shop who sells the ardumower-parts seems to be down for a long time, doesn't seem like something I want to rely on.
 
i got similar errors last year after a water damage: imu dead, some mosfets died, i2c bus converters faulty, the ina169 had a short circuit, the mow motor (brushed) had a short circuit and finally my arduino DUE got a short circuit at the processor.
 
So I've swapped the ESP32, reflashed its software with same settings as before.
Wifi and Bluetooth is fine but I don't get any communication anymore with the arduino due ... .
  • beeptest from Tx, Rx pins on U2 Bluetooth_CZ_HC_05 to U15 and U16 seems ok
  • beeptest from other pins on U15 and U16 to Rx2 and Tx2 (on arduino due) seems also ok
So I'm suspicious if those SN74LVC1T45DBV transceivers got a failure.

Possible things to try: (maybe somebody has a recommendation?)
  • Is there an easy check possible on these transceivers (I don't have a scope)?
    Both boards (ESP32 and due) work on 3.3 V, can I bypass these safely without risk of further damage?
  • If not, I would consider testing the Rx1 and Tx1 (only intended for esp8266?) and swapping Serial1 with Serial2 in this code definition.
    Assuming not all transceivers failed - due to reasons I still have no clue what went wrong ... .
    • #ifdef __SAM3X8E__ // Arduino Due
      #define WIFI Serial1
      #define ROBOT Serial1
      #define BLE Serial2
      #define GPS Serial3
edit: also found out later the battery voltage reported over serial is ~3.7 volt wrong (27.8V is reported as 24.1V).
 
Zuletzt bearbeitet:
Both boards (ESP32 and due) work on 3.3 V, can I bypass these safely without risk of further damage?
Yes with DUE, do not forget to swap Rx Tx between the 2 board.
For your over voltage issue:
A crash of the DC/DC step-down is certainly the problem, but on some config with big brushless Mow motor it's also possible on an emergency brake to have a feedback voltage on the 24V line .
What kind on mow motor and driver did you use ?
 
i had corrosion under the relay on the pcb. The due got the wrong voltage value and reported the wrong voltage. i have bypassed the trace on the PCB to fix it.
if you get a serial output via usb, your due should work, but maybe has a wrong config, also the esp32. ca you show us the serial output from usb?
 
good news :).
I connected the ESP32 and due directly with each other as suggested --> connection was working fine.
So the only conclusion I could make is the transceivers were not doing their job anymore.

So swapped Serial1 and Serial2 in the firmware (wifi and robot are not used anyway on due). And used the Tx and Rx pins, originally foreseen for the ESP8266.
Now the boards are again communicating with each other. Motors spin, connection to cassandra works again etc. .
#define WIFI Serial2
#define ROBOT Serial2
#define BLE Serial1
#define GPS Serial3

The remaining weird thing is the not-stable battery voltage reporting (example figure when sitting idle).
1708462577287.png
I thought removing the jumpers related to the same transceivers (JP10 and JP4), fixed the issue but seems like it's not (it's just less worse).
The pinbatteryvoltage on due seems to be correct when measuring with a multimeter. But I believe the 3.3V IOref seems to vary with a similar percentage. I don't quite know what would cause such a slow oscillation.
 
Oben