VSDSP Forum

A few starting points:
- To control the resistors, the USB needs to be set to NOHIGHSPEED and enabled in USB_CF, and naturally all respective analog powers and bias generators enabled in the ANA_CF registers.
- For the host pull-downs the USB needs to be in host (master) mode, possibly. For the 1.5k pull-up it needs to be slave mode, possibly.
- USB_UTMIW is the register to try. You can control what gets put in the USB pins by setting the UTMIW_ORIDE, set OPMODE to 2, and set either J or K. But if I understood, you don't want the pins to drive, just the host pull-downs. There are also RCVSEL and TERMSEL. I would try setting ORIDE and then seeing what those SEL signals do.

Unfortunately I don't have time right at the moment to measure what happens.

As always, thanks for the responses Hannu and Pasi! Your help has been instrumental in helping move this project forward.

Hannu wrote: ↑Mon 2022-06-27 13:50 I am also on uncharted waters and I'll try to get you a better answer, but USB_UTMIW register is the one register to poke.

Ok. I wasn't sure if there were additional registers that weren't documented due to not normally needing to be accessed directly. I haven't tried, but I don't think the UTMIW registers would be helpful. I will investigate further

I took a look at the spec and then I remembered again that this is USB. Too many TLAs and ETLAs for my taste to give quick answer.

I understand! No need for too much investigation

So you want USBP 1.5k pull-up and USBN 15k pull-down. Is there need for some signaling ? Or just to keep the system passive and resistors on?

The USB DCP spec is simple. A DCP is something like the power adapter you plug into a mains outlet and has a USB port that you plug devices in to charge, such as phones etc. The spec says that such a charger should have D+ & D- on its port shorted together with no more than 200 Ohms. Since such a charger is "dumb" because it provides no capability for enumeration, the device being charged needs to be able to detect the short on D+/D-. The way the spec recommends it is to drive the D+ line to 3.3V, and have a resistor on D-. Then, you read the state of D-, and if it is high, then it is shorted to D+, meaning it is a DCP device. Of course, you might want to toggle the 3.3V on D+ and check the results on D- just to make sure.

So there is no signaling. Just need a way to check for a short.

I found this from kernel sources (scsi.c) and optimized it for you

Code: Select all

u_int16 MyUSBReadLines(void) {
   return PERIP(USB_UTMIR)>>14;
}
/* Actually fastest implementation: #define MyUSBReadLines() (PERIP(USB_UTMIR)>>14) */

Thanks for this! It was right in front of my eyes, and I didn't see it. Time for some glasses
This gets me most of the way there.

What else is needed, I don't currently know. Some hints could be found from UsbHost porgram code and umsc code from kernel If you want to have an interesting journey around USB hardware.

I spent much of last week digging through the usbmsc and related code trying to figure out how to implement multiple configuration descriptors. Pretty sure I got it figured out and have all the relevant code for enumeration in place, but I haven't tested it yet. I am not an expert programmer, so a lot of the VLSI code looks like magic that I'll never understand

pasi wrote: ↑Mon 2022-06-27 16:53 A few starting points:
- To control the resistors, the USB needs to be set to NOHIGHSPEED and enabled in USB_CF, and naturally all respective analog powers and bias generators enabled in the ANA_CF registers.
- For the host pull-downs the USB needs to be in host (master) mode, possibly. For the 1.5k pull-up it needs to be slave mode, possibly.

This is the impression that the UTM bit tables gives me as well as another comment in the datasheet. It was the graphic in figure 23 that gave me some doubt.

- USB_UTMIW is the register to try. You can control what gets put in the USB pins by setting the UTMIW_ORIDE, set OPMODE to 2, and set either J or K. But if I understood, you don't want the pins to drive, just the host pull-downs. There are also RCVSEL and TERMSEL. I would try setting ORIDE and then seeing what those SEL signals do.

To my understanding, all chirps are differential, so it wouldn't work. Thanks for the tips on ORIDE and the OPMODEs. The function of these were a bit of a mystery to me.

Unfortunately I don't have time right at the moment to measure what happens.

No problem! You have helped me plenty!


I think the UTMIR_LSTATE bits and the D+ pull-up resistor gets me almost there. I will also need to do something about the 1M pull-up resistors on D+/D- which I now understand are used for the MyUSBIsDetached() function. Maybe the remainder of my solution lays in switching these resistors in and out of circuit, high and low, as necessary, directly from GPIO? That way I can still use the technique for connection detection and switching them out so as to not interfere with DCP detection, or maybe even help with it.

Any thoughts driving those resistors from GPIO instead of directly from AVDD? As in, is it a bad idea for some reason?

If you can spare one GPIO, you can perform attach and detach detection from VBUS, like it should be done and do without the 1M pull-ups.

If you also want to use the port with system's USB drivers, you might need a bit of patching.

AVDD is raised during USB operation for compliant levels. (I'm not sure if vs1010 always runs with the high AVDD.) If the difference between IOVDD and AVDD is larger than a diode threshold voltage, a small current will flow through the protection diodes. With 1MOhm though, that should be very small with 3.3V IOVDD (even if you don't touch it). You might have issues shutting down, i.e. power-off. Edit: Nevermind, not from IOVDD directly, but from GPIO, so power-off should not be affected if you turn them into inputs before shutting down.

pasi wrote: ↑Tue 2022-06-28 15:52 If you can spare one GPIO, you can perform attach and detach detection from VBUS, like it should be done and do without the 1M pull-ups.

My charging scheme will require detection of Vbus, so I will be using a GPIO for that already. I read elsewhere that it is suggested to use D+/D- connection detection rather than relying on Vbus power detection, I believe for timing purposes since Vbus and GND make contact on the USB connector first before the data lines. I thought that might have been the reason for the 1M pull-ups. If not, then I will probably omit them and only use a pull-down on D- with the other end attached to GPIO for DCP detection purposes.

If you also want to use the port with system's USB drivers, you might need a bit of patching.

Do you mean on the VS1005 firmware side? I will remove the detach detection code, if that's what you meant. Although looking at the VLSI USBMSC code, it doesn't appear to do anything?

AVDD is raised during USB operation for compliant levels. (I'm not sure if vs1010 always runs with the high AVDD.) If the difference between IOVDD and AVDD is larger than a diode threshold voltage, a small current will flow through the protection diodes. With 1MOhm though, that should be very small with 3.3V IOVDD (even if you don't touch it). You might have issues shutting down, i.e. power-off. Edit: Nevermind, not from IOVDD directly, but from GPIO, so power-off should not be affected if you turn them into inputs before shutting down.

I do recall in the datasheet or elsewhere that it specifies that the USB hardware sets AVDD high. Yes, the current plan is to pull a high value resistor attached to D- low using a GPIO pin only during the DCP detection routine. Once detection is complete, I will set that GPIO pin to High-Z input. Assuming this scheme works (I don't currently see why it would not), then it is a simple and low cost method to implement DCP detection. Most typical methods require specialized ICs or at least a USB mux IC.

Thank you for the help!

Just some random thoughts which have popped up to my head from this thread and can be totally irrelevant to your design:

If VBUS is connected to VHIGH, you can read it with SAR. If VHIGH is measured, it is possible then to check how the data pins are and after that start USB device program. If there isn't GPIO trigger for it.

I believe that the resistors are for USB host program to detect usb stick. And I have impression that you are working with USB device mode. I didn't find anything which needs them on on VSOS kernel USB msc mode.

Also kernel in USB msc mode puts AVDD to 3.6 V.

Most pins have internal pull-down, some don't and floating pin without any pull will consume power quite much.

Hannu wrote: ↑Wed 2022-06-29 13:47 Just some random thoughts which have popped up to my head from this thread and can be totally irrelevant to your design:

If VBUS is connected to VHIGH, you can read it with SAR. If VHIGH is measured, it is possible then to check how the data pins are and after that start USB device program. If there isn't GPIO trigger for it.

I believe that the resistors are for USB host program to detect usb stick. And I have impression that you are working with USB device mode. I didn't find anything which needs them on on VSOS kernel USB msc mode.

Also kernel in USB msc mode puts AVDD to 3.6 V.

Most pins have internal pull-down, some don't and floating pin without any pull will consume power quite much.

You are correct: my project uses USB MSC device drivers (contents of internal SD card will be published over USB as a mass storage device). Besides that, USB will be used to charge my device, so I modified the USBMSC code to enable 2 configuration descriptors: The first is to request 500mA in bMaxPower during enumeration, but if the host doesn't approve that (such as when connected to an unpowered hub or most smart phones/tablets), then the other is the standard 100mA which all standard hosts must support. The DCP detection is so I can safely draw 500mA in case Vbus is detected, but all enumeration fails.

Best I can tell, the 1M pull-ups are to detect connection to a host because the 15k pulldowns on D+/D- of a host device will overpower the weak 1M pull-ups, and so data pin connections can be determined by seeing D+/D- going low, whereas if they are disconnected they would show high. From what I read, doing this kind of detection is good practice, but not mandatory.

"Most pins have internal pull-down, some don't and floating pin without any pull will consume power quite much."
I would like to better understand why a pin without a pulldown would consume much power. Wouldn't a pin set to High-Z input consume the same amount of power through the input transistor regardless of whether there is a pull-up/down resistor on it?

Thanks,
Mark

The pull-down is about 1Mohm and you can see them from pin table. DIOPD type pin is with and DIO without pull-down.

Normally those pins without pull-down don't use more current but if those pins are left to floating or some other chip has pull-ups and then those pins are biased somewhere around IOVDD/2 problem starts. A simplified idea is that the pin has P and N FET and gates are connected to the pin. Normally these FETs would put the pin high or low read value. Now in IOVDD /2 input both are conducting and current flows from IOVDD to ground through them very easily and what you read with processor from is unreliable. This is true to all digital input pins with or without pulling resistors.

That's why it is recommended to give good digital values to input pins. And in the case of USB 1Mohm pull-ups hooked up to a gpio pin. Just drive them down. USB 90 ohm differential 45 single ended will easily overpower them.

Hannu wrote: ↑Thu 2022-06-30 8:45 The pull-down is about 1Mohm and you can see them from pin table. DIOPD type pin is with and DIO without pull-down.

Normally those pins without pull-down don't use more current but if those pins are left to floating or some other chip has pull-ups and then those pins are biased somewhere around IOVDD/2 problem starts. A simplified idea is that the pin has P and N FET and gates are connected to the pin. Normally these FETs would put the pin high or low read value. Now in IOVDD /2 input both are conducting and current flows from IOVDD to ground through them very easily and what you read with processor from is unreliable. This is true to all digital input pins with or without pulling resistors.

That's why it is recommended to give good digital values to input pins. And in the case of USB 1Mohm pull-ups hooked up to a gpio pin. Just drive them down. USB 90 ohm differential 45 single ended will easily overpower them.

This is a great lesson! It is something I never thought about, but seems to make good sense!

I'm back once again with another question

I am curious what some of your thoughts are on supplying the AVDD bus not only from the internal regulator but also sometimes from an external regulator at 3.6V when VHIGH might also only be 3.6V? Here's a simple block diagram of what I have in mind:



Can I do this without bad things happening?

My problem is that, due to the battery charging/PMIC I'm planning on using, with VBUS on the PMIC input, it regulates voltage output to the load at 200mV above the voltage of the battery down to a minimum of 3.6V. Ideally, I would just select a different part that doesn't have this behavior, but given the current state of the IC supply chain, I'm leaning towards parts that look like they'll have good availability when it comes time for production. And besides this one issue, the PMIC does nearly everything else I need.

Since the vs1005 datasheet specifies minimum voltage to VHIGH at 4V when using the USB peripheral, I cannot meet that requirement if the battery is at a low state of charge. One option is to just wait until the battery reaches a higher state of charge before enabling communication, but not only would I prefer to not do that, it causes other potential issues which are better avoided. Another option is to just OR VBUS and PMIC output into VHIGH using something like diodes. That would likely be fine for VBUS, but even Schottky diodes drop several hundred mV, which will negatively affect battery operation. Another option is to use some sort of solid-state switch to select different power sources feeding into VHIGH. This might be the only other practical solution, but I'm not ready to go that route unless someone from VLSI deems the regulator option a bad idea.

Basically your plan is OK. If you provide external voltage which is higher than internal regulator sets, the internal regulator gives up.

You have to know that there is a vbus so that you can enable the external regulator. Also check that if there is no VBus, and the regultaor is off, it isn't pulling the output down. Actually check all the states, Enable on-off and VBus available-not available. Some regulators are sneaky little creatures which don't behave at all.

And when enabling the external regulator, I would even do some evil things such as lower the internal regulator voltage. for example 3.5V so the internal regulator doesn't regulate the AVDD. And also make a good filter for the AVDD. If it is bad, it ruins audio, USB and your day.