Doubts about disabling USB module

[E_Blue]

I'm working on a battery powered device and I want to disable USB module before the µC goes in to sleep mode and save power.

The µC is a PIC18F67J50 running a CDC CCS USB stack.

There's any routine to disable the USB module before the µC goes to sleep and re enable it when wake up or I just must change UCON.USBEN bit to 0?

Do I must to disable UCFG.UPUEN and set UCFG.UTRDIS?

Does RF3 and RF4 have pull ups when the USB module is disabled?

Because I'm worried about the floating inputs.
_________________
Electric Blue

[Ttelmah]

On this chip there is no internal voltage regulator for Vusb. I assume this is being driven by an external regulator?. The first thing that needs to go off is this. Since this is what powers the pull-ups, if this is off, these are disabled.
The transceivers are also powered from this, so if this is off, they also draw no power. Then if the clock is stopped, nothing else is needed. Without a clock, the module draws practically nothing.

[E_Blue]

Yes, there's a 3.3V LDO regulator but it supplies the internal 2.5V core regulator and VUSB, so I can't disable it.

Basically I'm using schematic of page 331 Figure 22-9 of datasheet 39775c.

I have about 4mA of power consumption with the external oscillator disabled, TMR1 oscillator at 32768KHz, and the core running from internal 500KHz oscillator, and non output active, so I think that the USB draining is power through the 900ohm resistors at RF3:4.
_________________
Electric Blue

[Ttelmah]

Study that circuit.

It is for _bus power only_. In other words, when the PIC is being powered from the USB supply only. It sounds as if you are trying to use this when the PIC is actually being supplied from the battery supply.

Not how you want to work.

Point is that for a battery system using low power, you want the fourth option (the one they don't illustrate...). 'Dual power with USB dominance'. On this, the battery only provides the CPU core, and the USB stuff is only powered when the USB connection is available. Microchip actually detail this in a separate application note (AN950), however this is for chips with internal USB regulators. Or even the fifth option 'Dual power with USB driving USB'. A lot depends on how much your circuit draws?. If it is under 100mA, then this is easy to implement, since USB allows this without having to be configured for bus power (most of the complexity in this AN). For chips like yours, this is best done with two 3.3v regulators, and the second is only powered to feed Vusb, when the USB connection is available.
You don't want to be powering the USB stuff, when the USB is not connected.

[E_Blue]

1) So I can have Vusb pin with 0V and the PIC and CDC CCS library should work OK? I mean when USB connector is unplugged.

2) What about the floating RF3 and RF4? Doesn't start to oscillate due to the lack of pullups resistor?

3) The CDC library doesn't disable USB module when the USB connector is unplugged?

I'm using RE0 to detect USB presence.

[Ttelmah]

It's a question of how low you want power to go?.
If you lower the Vusb power rail, the inputs are clamped by the internal reverse diodes in the transceivers, and the whole module is powered off. You need to be using usb_init_cs, but this does not fully disable the USB module as such. The connection sense, is technically _required_ by all USB devices that are not bus powered, for the handling of suspend states. The USB can be still connected, and the USB power will go off in some of the deep sleep modes....

In code, if you disable the USB interrupt, or stop calling usb_task, and then call usb_detach(), the peripheral will be switched off. It'll automatically be re-enabled, as soon as usb_task is again called (or the interrupt occurs). It's not designed for the user to call, but provides a tidy way of disabling the peripheral. Beware though. If (for instance) you have a program on the PC, that has the USB 'in use' as (say) a CDC peripheral, this can become deadlocked if the USB is disconnected. You need to think how the application will handle this... You also need to ensure the peripheral is woken ASAP, if the bus is attached. You only have a very few mSec after attachment, to get the peripheral running, or the PC will have problems re-enumerating.