Lets for testing leave OTG enabled and just disable Host part of OTG driver.
under [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\USBOTG\Hdc]
rename dll entry by adding _ in front.
Peter.Tx will give you some instructions on what voltages to measure to get some more information.
Maybe it is worth checking whether the issue is related to back feeding. Back feeding is really hard to avoid on the Colibri Vybrid and is normally not an issue. However, if the voltage level is too high, it could cause issues of not booting reliable.
Can you measure the voltage level of the main input rail of the module while it is turned off? Can you compare the voltage with different use cases and whether you can see any correlation between the voltage and the boot errors? As a test, could you add an additional load (resistor) to the rail in order to lower the back feeding voltage? Do you see any difference in the boot behavior?
Hi @peter.tx
I think that you’re right and the issue is related to back feeding.
We did a series of test with Evaluation Board V3.2A and Colibri VF61 256 MB IT V1.2A.
We used an external power supply to supply VCC_USB5 voltage (instead of USB cable connected to X29). In this way we can control the voltage itself.
In the following tables there are the voltage levels of the main input rail (3.3V_COLIBRI) when the module is turned off:
You can see that the main input rail is powered, and this is not good for the device itself (I think).
Maybe D10 (RCLAMP0504S) on EVB is part of the problem when 5V is not present on the board while VCC_USB5 is present; maybe it’s not. I don’t know.
In all the above conditions, the VF61 module shows sporadic booting issues.
Then we tried to increase RA28A series resistor (on EVB) while applying VCC_USB5 = 5V:
Based on our test, back feedings on VF61 modle is a big issue.
On our carrier board, we connect an analog input voltage to SODIMM_8;
this input comes from a circuit which is battery powered and so the voltage is present even if the module is off.
For this reason VF61 modules could have big boot issues if the voltage level of the battery is high.
We did tests with MX7 module and it seems it’s not affected by this back feeding issues.
Do you have any suggestions to avoid this problems?
In some scenarios, voltages can come from other fields devices even if VF61 module is off.
A back feeding on around 900mV is quite high, but we do not expect any physical damages on the module itself. For most of the applications, it is not even an issue. However, interesting to hear that in your case, the boot issue is related to it. I am not aware that we got similar reports so far.
Back feeding is not easy to resolve. At first, we need to try to avoid any IO pin being high when the module rail is removed. However, this is not possible for all interfaces such as the USB_C_DET if a USB cable is plugged in or your battery monitor pin.
The second approach is trying to reduce the actual current that is flowing over the protection diodes into the system. One of the simplest approach is to add a series resistors (as you did with your tests) or in case of the USB_C_DET making the voltage divider R73/R74 bigger (e.g. 5.7k/10k).
Another thing is to reduce the number of pins that are actually back feeding. Very often the back feeding is caused by multiple pins. Do you have any further pins that could cause back feeding (DDC, UART, USB, etc)?
The last counter measurement is adding a discharge circuit. Add additional load resistors (e.g. 10R) to the 3.3V rail. In order to reduce power consumption, add a transistor switching circuit in order to enable it only during the power up sequence. However, this should be only the last solution if all other solutions are not resolving the issue.
Hi @peter.tx
I confirm that no other pins were powered during our tests (apart from USB_C_DET).
In some other scenarios, RS232 from the PC can hold some pins HIGH; and so we need to take care about this situation too.
The issue from USB_C_DET can be mitigated with a higher series resistor and a stringer voltage divider R73/R74.
The discharger circuit is not a realistic option, I think.
Another different fix is needed to avoid back feeding from SODIMM_8 (which brings the battery voltage through a voltage divider).
This is analog input pin and so a higher series resistor can’t be used without modifying the analog input voltage.
Based on our experience, I think that you can write a new KB describing the back feeding issues for VF61 and giving some tips to the customer to verify and mitigate this problem.
I agree with you, creating an article can help customer with similar issues. I have noted it down. I hope, I will find soon some time to create such a guidance.
The whole back feeding issue seems to occur only since you have implemented a client only port. The issue does not appear when an OTG circuit is used. Even tough, you only need the client function, maybe it is possible to implement still the ID pin switching in your design. Of course, this is only possible if you are using a Micro USB-B jack and not a regular USB-B in which the ID pin is missing.
The whole back feeding issue seems to
occur only since you have implemented
a client only port. The issue does not
appear when an OTG circuit is used.
Could you clarify, please?
The back feeding happens when the module is powered off (so the USB software configuration doesn’t matter) and I connect my PC to X29 regular USB-B connector of EVB (and EVB has OTG circuit).
Moreover I saw the back feeding even before having reconfigured the module as USB client only.
Since I need USB client only (i.e. I want to connect my device to a PC as a standard mass storage device), I don’t need ID pin at all.
Am I wrong?
Dear Luka,
I have a similar problem, using VF61 after 4 hours with PIN 137 high a memory leak happens…
My Usb port is isolated and it has not Cable Detected, moreover I use the port as client and not as host.
Have you found any solution at this problem?
Thank you
Matteo
@luka.tx answered above.
You need to change some registry settings and leave SODIMM 137 as it is (do not configure it as GPIO, and don’t set it high).
This worked for me.
Thank you for you answer,
Could you give me a suggestion about your registry settings?
You can find them in the message from Luka that I linked above
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\UFN]
"Dll"="usbfn.dll"
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\USBOTG]
"Dll"="_otg_vybrid.dll"
Dear @Matte,
Could you please download this registry and import using RegEdit tool and SaveReg and Reboot. Verify USB function driver(serial_class) is working on this device.
Please let us know if you face any issue on this.
Dear @Matte
Thank you for your patience.
Could you please wait for some days, our vybrid developer is on vacation and he will be back in August. We will get back you once we discussed this issue with him in early August.
Internal: Waiting for Luka from vacation. It is pending from our side.
Hello,
Have you just discuss about this problem?
Do you have some news about it?
Thank you
Hello,
The PIN 137 is set to default (AlFn Name RCN27)
I changed the registers like above, save and reboot.
But the USB is not working…
Thank you,
I’m waiting your news.
If I can do some tests or help you in someways tell me…
Matteo
Dear @Matte,
Thank you for your patience.
Could you please share this schematic part of yours
Could you please answer my below questions, we will try to come up with a solution to your problem.
Is USBC_CableDetect pin used? Is it left free?
Do you need only Client functionality on that port?
Is that USB client cable always connected or dynamic insert/removal support needed?
Dear @raja.tx,
tell me if this part of schema is sufficient or I need to send anything.
I need only Client functionality on that port.
The USB client cable needs a dynamic insert/emoval support.
Thank you
Dear @Matte,
The SODIMM 137 (USB_C_CABLEDET) is multiplexed on the Colibri VFxx board:
So, you must use USBC_CABLEDET(pin 137) for USB Client functionality. Please refer our Colibri Evaluation board or carrier board schematic for reference and then use default registry.
Please let me know if you have any other questions