USBD starting up lowers board's overall current draw

Hi,

Our custom board using the nRF52840 with SDK 15.0.0 experiences a higher current draw if it starts up without the USBD module enabled at some time.  The first screenshot is when I power up and no USB is present, so USBD doesn't start up:

As you can see, there is a baseline current draw of around 600uA.  If I power up with USB attached and then remove USB after USBD has started, I get the following current draw:

This time the baseline current draw is less than 100uA.  I should note that I have to leave the USB in long enough to let the USBD start running, then I can remove the USB cable.  If I remove USB before it starts, it goes back to the current draw as when it powered up without USB.  If I comment out the USBD, it draws the high current even if I started it up with USB, so it appears to be a difference in something USBD does when it runs.  Shutting down USBD after it has started leaves that change in place.

I am initializing the DCDC regulators for both Vdd and Vddh, and I have changed the defines in sdk_config.h to 1 so that the USBD also uses them and doesn't undo using the DCDC regulators.

Has anyone else come across something similar or know what the USBD changes that could cause this.  I am wondering if it changes a pin's configuration or state that stops the extra current draw, but I cannot find anything like that.

Thanks for any ideas,

Kraig

Parents
  • Hi,

    I can't say that I've seen this before. Maybe something else in your code is effected when you comment out the USBD part. Have you tried flashing a development kit with your project? Do you measure the same with the dk?

    regards

    Jared

  • Sorry for the delay in my response.  There could very well be another reason unrelated to the USBD.  It is because I can repeatably get a difference in the current draw depending if I let the USBD start up or not that I was focusing on it.

    Unfortunately because the code base runs on our custom board with different pin assignments and chips than what is on the DK board, it would be a significant amount of modifications to make it run on the DK.  I don't think the code would be anywhere near representative, so I don't think it would be worth the effort at the moment.

  • My guess is that something else is being indirectly affected when you comment out the USBD part. Is there any other code part that depends on that module? Are you using the logger, if so what backend? Have you reproduced this on multiple samples?

  • There is no other code that uses the USBD module.  We don't use the Logger module.  We do use the Segger RTT print statements, but that code is ifdef'd out.

    Yes, we have quite a few samples showing this, but if we re-flash the entire chip, the problem goes away.  I haven't nailed down the procedure to make a sample start doing it.

    I was thinking the same as your guess.  Because it is a rise in the steady current draw, I was thinking some pin is configured bad for the circuitry, causing a current leak.  I did see that the lower USBD driver had calls to disable pull-ups, but calling that directly didn't make a difference.  I also tried to directly call start/stop functions with no luck either, hoping they would disable interrupts or other pin assignments.  Not sure if I can call those directly.  I am just trying random stuff now.

Reply
  • There is no other code that uses the USBD module.  We don't use the Logger module.  We do use the Segger RTT print statements, but that code is ifdef'd out.

    Yes, we have quite a few samples showing this, but if we re-flash the entire chip, the problem goes away.  I haven't nailed down the procedure to make a sample start doing it.

    I was thinking the same as your guess.  Because it is a rise in the steady current draw, I was thinking some pin is configured bad for the circuitry, causing a current leak.  I did see that the lower USBD driver had calls to disable pull-ups, but calling that directly didn't make a difference.  I also tried to directly call start/stop functions with no luck either, hoping they would disable interrupts or other pin assignments.  Not sure if I can call those directly.  I am just trying random stuff now.

Children
  • Kraig said:
    There is no other code that uses the USBD module.  We don't use the Logger module.  We do use the Segger RTT print statements, but that code is ifdef'd out.

    Meaning the logger with RTT as backend? Is NRF_LOG_ENABLED = 1?

    Kraig said:
    Yes, we have quite a few samples showing this, but if we re-flash the entire chip, the problem goes away.  I haven't nailed down the procedure to make a sample start doing it.

    ok, so it's essentially the same as what the other user in this thread described. 

    Does a power-on reset affect the current consumption in any way? 

    regards

    Jared

     

  • Meaning the logger with RTT as backend? Is NRF_LOG_ENABLED = 1?

    No, NRF_LOG_ENABLED = 0 and NRF_LOG_BACKEND_RTT_ENABLED = 0.  Maybe I'll turn that on and see if it spits out any good info.  Thanks.

    Does a power-on reset affect the current consumption in any way? 

    Regardless of how it starts, if USB is connected and the USBD module starts, the power is lower than if it starts without USBD.  And it is that constant draw that appears to be the only change, which is why I think it is some pin configuration or some peripheral turned on.

    Thanks for the questions.

  • To be honest, it difficult to be sure whether this is a SW or a HW issue without knowing whether it's reproducible on a DK or not. Did you try to enable the log, did it say anything useful?

Related