Hi,
On our NRF52840 Based product, we have enabled USB CDC Use.
We see increase of ~0.5 mA when enabling USB . We are ok with this , However - when we remove the USB cable , we still see this 0.5 mA increase.
I'd like to de-init the PHY once I detect USB Removal . How do I do that ?
Hi, this sounds like the USB is not de-initialized correctly and that the HF clock is still running when the USB cable is unplugged. Do you see this with the USB CDC SDK example? Which version of the SDK is this, and if you are using nrfx drivers, which driver version are you using?
This was tested with 3rd party USB Driver ( Segger emUSB ) , I will test with Nordic's CDC.
HF Clock will be used by SD any case right ?
For Nordic's CDC\USB - Is there de-init function somewhere I can reference ?
The HF clock (HFINT, not to be confused with the crystal (HFXO)) is used by the softdevice, CPU and many other peripherals, It turns on and off by request from the peripherals, so it's not running all the time. Generally, if the peripherals are not de-initialized correctly the clock request might never be released, and the clock is then stuck. The only way of releasing the clock is then to power cycle the peripheral.
How to power cycle peripherals is described in this errata: https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev2/ERR/nRF52832/Rev2/latest/anomaly_832_89.html?cp=4_2_1_0_1_26 The errata is written for SPI and TWI, but you can try this on the USB peripheral as well. Note that the base address for the USB peripheral is 0x40027000, so the POWER register will have the address: 0x40027FFC.
Try this out and see if the current consumption is going down afterwards. If it is, then the high current is most likely caused by the HF clock.
The drawback of power cycling the peripheral is that all configuration registers are cleared, so the USB peripheral will have to be re-initialized. So ideally you should figure out why the driver is not de-initializing the USB correctly.
As a reference the nrfx USB driver is documented here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/group__nrfx__usbd.html?cp=7_1_6_9_0_43_1
And the disable function: https://github.com/NordicSemiconductor/nrfx/blob/9136253e271f978a8da735864fc50d60e0ed68c6/drivers/src/nrfx_usbd.c#L1835
The HF clock (HFINT, not to be confused with the crystal (HFXO)) is used by the softdevice, CPU and many other peripherals, It turns on and off by request from the peripherals, so it's not running all the time. Generally, if the peripherals are not de-initialized correctly the clock request might never be released, and the clock is then stuck. The only way of releasing the clock is then to power cycle the peripheral.
How to power cycle peripherals is described in this errata: https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev2/ERR/nRF52832/Rev2/latest/anomaly_832_89.html?cp=4_2_1_0_1_26 The errata is written for SPI and TWI, but you can try this on the USB peripheral as well. Note that the base address for the USB peripheral is 0x40027000, so the POWER register will have the address: 0x40027FFC.
Try this out and see if the current consumption is going down afterwards. If it is, then the high current is most likely caused by the HF clock.
The drawback of power cycling the peripheral is that all configuration registers are cleared, so the USB peripheral will have to be re-initialized. So ideally you should figure out why the driver is not de-initializing the USB correctly.
As a reference the nrfx USB driver is documented here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/group__nrfx__usbd.html?cp=7_1_6_9_0_43_1
And the disable function: https://github.com/NordicSemiconductor/nrfx/blob/9136253e271f978a8da735864fc50d60e0ed68c6/drivers/src/nrfx_usbd.c#L1835
