Hi Carlos,
Yes what I did was check with the scope the output of the USB_OTG1_PWR while toggling the PP bit in the PORTSC1 register with the debugger. So I was not actually running any code. Since we are developing for the SABRE board we don't have the option to use any other pin. I don't think the errata applies specifically but the problem may be related to it. It explains why the USB is powered on after reset. I'm not really familiar with all the details of how the internal hardware works in the USB controller but there seems to be a problem with this bit being reversed and getting the OTG1 to operate in host mode. Unfortunately all the information I've found seem seems to be related to device mode. I'll check the assignments but other bits in the register seem to be ok so I don't think there is a general register problem. I'm thinking there must be some test code somewhere where this port was run in host mode and how this issue was worked around.
Thanks
Ed
Hi Ed,
Have you verified the related hardware connected to the USB_OTG1_PWR pin on the SABRE board?
You could also take a look at the following links with related information
https://community.nxp.com/thread/435499
https://www.spinics.net/lists/devicetree/msg22355.html
Additionally, errata ERR009059 also includes some information regarding USB_OTG1_PWR issues on the i.MX6SX, you could take a look at it:
http://www.nxp.com/assets/documents/data/en/errata/IMX6SXCE.pdf
Finally, have you properly configured the domains for each core (A9 and M4) in order to assign the OTG1 module to be controlled by the M4 (you mentioned it is running MQX, isn’t it?)
Hope this will be useful for you.
Best regards!
/Carlos
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------