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:
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.
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:
However, it will still not boot correctly. The IMXRT is designed to control the power of the 3.3V regulator:
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.
Thanks for looking into this!
Am I correct that:
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.
- 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.
Hi there,
not sure whether a new post would have been needed, but since I am trying out the RT1062 (I previously used the H7+), I was wondering whether it is the expected behavior that the IDE cannot interrupt a running script to connect to it.
To reproduce:
insert an SD card into the RT1062
connect the RT1062 (with dev firmware) to the openMV IDE
load the advanced FD on memory script onto the SD card as main.py (I added some green LED signal when triggered so it tells me when it’s running)
disconnect the RT1062 from IDE, unplug
Plug the RT1062 back into the computer (wait for the script to run as indicated by green LED)
Try to connect through the IDE → “No OpenMV Cam found”
Only solution so far was to introduce a delay for the user to have time to connect before the script proceeds with time.sleep_ms(5000).
Hmm… that seems like a different issue. No cameras found means the serial port hasn’t been enumerated yet. The RT1062 uses TinyUSB which handles USB packets in between Python C function calls. The in memory advanced frame differencing script should invoke the TinyUSB handler often enough for things to work.
Just tried the script the the latest firmware and it appears to work fine…
OK I’ll post it as a different issue since I actually never get to “no openMV cam found”
