search

Zubax / canface_cf2

All-in-one hardware solution for developing UAVCAN-compatible devices.
https://shop.zubax.com/collections/development-tools/products/zubax-babel-babel-all-in-one-debugger-for-robotics-drone-development
4 stars 3 forks source link

DCP enters the bootloader mode at first power on #9

Closed pavel-kirienko closed 1 year ago

pavel-kirienko commented 3 years ago

The DCP tends to occasionally freeze up when high-voltage power is applied to the target with Babel-Babel connected. Steps to reproduce:

  1. Connect Babel-Babel to the (unpowered) target via both CAN interfaces, the DCP port, and the USB.
  2. Connect Babel-Babel to the USB host (in my case this is a USB hub with a dedicated wall power supply).
  3. Apply high-voltage power to the target (Myxa B0 in my case).
  4. Observe DCP disappear from the list of connected devices on the host.

It may take several attempts to reproduce the problem.

The issue affects none of the other three devices connected to Babel-Babel. The DCP can be brought back to life by physically re-connecting Babel-Babel to the host with the DCP port unplugged, and then plugging the DCP port back in.

I suggest equipping the DCP port with EMI mitigation measures, perhaps resistors or chokes. Also, increasing the decoupling capacitance on the MCU might help.

j3qq4hch commented 3 years ago

I think there should also be added an additional button for DCP reset to avoid endless fuss with connectors.

suzonch commented 3 years ago

"Observe DCP disappear from the list of connected devices on the host." you mean device manager or ucvan gui? I'm trying to reproduce the error.

pavel-kirienko commented 3 years ago

The USB device is detached from the host. It is not related to UAVCAN at all.

suzonch commented 3 years ago

"Apply high-voltage power to the target (Myxa B0 in my case)." spin the motor?

pavel-kirienko commented 3 years ago

No, just connect high voltage power supply. On my setup it is sufficient to trigger a failure.

pavel-kirienko commented 3 years ago

I recorded this video for Alexander some time ago:

https://user-images.githubusercontent.com/3298404/127881942-90d8cda2-7a54-4f2c-a128-d2abc3533548.mp4

suzonch commented 3 years ago

So one or all of those 4 devices should be disconnected if that error happens, right? Trying, hasn't happened yet. Screenshot from 2021-08-02 18-55-29

pavel-kirienko commented 3 years ago

Hmm. This is an EMI issue so I would expect it to be difficult to reproduce. Can you try longer USB cables? A USB hub or two? Longer DCP cable?

suzonch commented 3 years ago

I don't think we have that long micro usb cable, I tried adding 2 extension cables. Works normally, Do we have longer DCP cable? Could be something with your USB hub/desktop?

pavel-kirienko commented 3 years ago

Extensive testing shows that it is my computer to blame. Closing.

dimracer commented 3 years ago

Apparently, we have the assembly problem of the one particular device. Let's try to reproduce the issue on the other devices

pavel-kirienko commented 3 years ago

This is not an EMI problem, this is a schematics issue. The DCP starts the bootloader instead of launching the main firmware. It is designed to do so if the BOOT button is pressed at power on, so we should ensure that the button is routed correctly. Maybe its pin is left floating?

pavel-kirienko commented 3 years ago

On the original Dronecode Probe design, the button pin is pulled up externally:

image

On Babel-Babel it is left floating:

image
pavel-kirienko commented 3 years ago

The boards that are already manufactured should be patched with a jumpwire between SWITCH and VDD_3V3:

image