USB-C: No OpenMV Cam found on OpenMV RT, after booting with 3v3

OpenMV Boards
1

Hi,

I have an openMV RT connected to a 3v3 robot. When the camera boots with the robot it works fine. However, when I then plug it into usb-c with my mac, it refuses to connect. “No OpenMV cam found.” The workaround is to boot the camera with usb and power on the robot later. This behavior is pretty annoying, and my OpenMV H7 doesn’t show this error. The H7 can boot with the robot and connects fine. Is that a firmware issue? Or hardware?

More info on my project is here:

2

Mmm, sounds like a driver issue.

Can you make a bug ticket on GitHub?

That said, I checked that I was able to connect to the device via USB when it was previously powered on by VIN a while back. I’ll recheck.

I won’t be able to debug this till next week.

3
4

I checked applying 3.3V to the 3.3V pin. The 3.3V power seems to flow to every 3.3V rail on the system and even into the VDD_SNVS rail.

However, the MCU does not boot. When you apply 3.3V to RAW it does boot. However, RAW may have 5V injected onto it from USB or VIN.

When you power the system from USB or VIN (which was the design goal) it will boot correctly. VIN needs at least 3.4V.

…

It would appear the issue comes from the VDD_SNVS being powered behind the 3.3V rail which makes the processor fail to boot incorrectly. I noticed that if you hold the power button for about 1 second the system will then turn on.

So, the system can work if you apply power via 3.3V. You just need to press and hold the power button until it powers on.

…

Note: I tried soldering the VDD_SNVS rail to 3.3V:

image
image695×636 70.1 KB

However, it will still not boot correctly. The IMXRT is designed to control the power of the 3.3V regulator:

image
image1045×504 23.8 KB

Via PMIC_ON_REQ. Forcing 3.3V onto the 3.3V rail bypasses the CPU’s power concept. The 3.3V rail is supposed to turn on after VDD_SNVS.

5

image
image900×937 128 KB

Yeah, back-powering the 3.3V rail bypasses the power concept.

6

Thanks for looking into this!

Am I correct that:

  • If I build a standalone robot on a 3V3 and connect the robot to OpenMV RT 3v3, the OpenMV will always require a manual intervention to boot?
  • If the RT boots on 3V3 the power led is blue?
  • If the RT boots on USB, the power led is green?
  • If I connect my robot 3V3 to OpenMV RT Vin, the OpenMV will boot. But if I later connect the OpenMV RT to USB, while the robot is still on, this could burn my robot microprocessor by sending 5V over Vin into the Robot?

If all that is true, I prefer the H7 power concept!

Anyway:
I was very lucky to find a workaround for LEGO hubs. The LEGO protocol can request for 8V, but you need to be able to send a few bytes to the robot. Luckily the OpenMV RT boots just long enough to execute the bit of Python code that begs for power. I have a BUCK converter on my adapter board that converts that 8V to a flat 5V to Vin. Just in time to keep the processor happy. Please don’t break this function!

If I don’t request power, the RT fails to boot fully in my case, and even the power button won’t help. When I later connect USB, the power led goes white. Then after some interaction over USB, it goes green.

7
  • If I build a standalone robot on a 3V3 and connect the robot to OpenMV RT 3v3, the OpenMV will always require a manual intervention to boot?

Seems like it. I tried soldering some wires around on it and couldn’t stop this from happening. It seems to be an issue with how the RT1062 works. Even with applying 3.3V to the always-on and main voltage rail at the same time it failed to bootup correctly.

  • If the RT boots on 3V3 the power led is blue?

That means you have VIN power.

  • If the RT boots on USB, the power led is green?

Green is power good. VIN/USB is determined by the blue LED.

  • If I connect my robot 3V3 to OpenMV RT Vin, the OpenMV will boot. But if I later connect the OpenMV RT to USB, while the robot is still on, this could burn my robot microprocessor by sending 5V over Vin into the Robot?

VIN won’t work with 3.3V, you need at least 3.4V. If you use VIN then you can apply USB or VIN safely.

I was talking about the RAW pin which is meant to be an always-on output which you can apply 3.3V to make the system boot. However, it will probably raise up to 5V when USB is applied.

I was very lucky to find a workaround for LEGO hubs. The LEGO protocol can request for 8V, but you need to be able to send a few bytes to the robot. Luckily the OpenMV RT boots just long enough to execute the bit of Python code that begs for power. I have a BUCK converter on my adapter board that converts that 8V to a flat 5V to Vin. Just in time to keep the processor happy. Please don’t break this function!

We will not be changing the RT design anymore expect to fix manufacturing issues and bugs.