Using Li battery with VBUS on nRF52840 Dongle

[SmallerPond]

This is just a verification, but in the nRF52840 Dongle schematic, it looks like VBUS is is connected to VDDH (by way of VBUS_nRF, which isn't an actual pad or pin, but just VBUS after it has passed through a low-pass filter).  This being the case, is it okay to connect VBUS to a lithium (max 4.2V) battery to power the device?  I can't imagine why it wouldn't be, but it isn't specifically called out in the datasheet so I just wanted to double check.  Thanks!

[Andreas]

Hi,

 

What exactly do you want to do, please elaborate. Generally though this is not possible, the valid range for supplying VBUS is 4.35V - 5.5V.

 

If you just want to use the nRF52840-Dongle with a lithium battery, no USB or anything, then this should work. But the USB circuitry will be outside it's operating area, so it will be hard to say how that will behave.

If you also plan on using the USB connection, then this might not work. The USB circuitry might not detect the USB connection, and the 5V bus rail will be connected directly to your battery. You'll at least have to remove the battery when using the USB.

In any case, whichever of the two it is and possibly third or fourth alternative, please remember that this is outside of specified operating conditions. Though I doubt it, we can not guarantee that the device will not take damage from this. Your use-case is generally more suited for use with a nRF52840-DK as that has battery connector, switches to change voltage modes split between USB and battery supply. It also has an onboard debugger.

Also when using nRF52840-Dongle you should be aware of this: https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial 

 

Best regards,
Andreas

[SmallerPond]

I can't seem to edit my previous reply, but I guess what I should have asked more specifically, is that any voltage present at the VBUS pin on the nRF52840 causes issues with the other power connections?  Or maybe, VBUS has higher priority than VDDH somehow?  Is that why this scenario might present a problem?

[Andreas]

Hi,

 

SmallerPond said:

All of this is to say that the battery is almost directly connected to VDDH (only an inductor in between) in the exact same way that you might connect a battery to VDDH as in the reference circuit on page 603 of the nRF52840 datasheet.

Not quite, this has VDDH disconnected from VBUS, the dongle resembles config 1 on page 597.

 

As for what you describe, this should be fine for VDDH. The unknown here is the USB circuitry, and how that will behave when powered in parallel with no data line activity, especially when the battery voltage drops outside the operating range for VBUS, even though it is still inside the operating range for VDDH. One key suspicion is that this could cause increased current consumption.

You might want to cut the VBUS_nRF trace so that it does not reach the VBUS pin, two suggestions:

This will prevent the USB-circuitry from working also when the dongle is used as a dongle, but if you cut this carefully you will be able to re-solder it back together later to restore the USB functionality.

 

Best regards,
Andreas

[SmallerPond]

This will work fine for us, thanks! We can just use SB1/2 to use external power to program, and it was easy to scrape off the solder mask and cut the trace.  It would be cool if on future Dongles you considered adding a 0Ohm or SB for this functionality since it seems like testing with small Li batteries wouldn't be terribly unusual.

While I'm asking for things - also a PTR clear task register (on SPIM for instance) so that I can implement a ring buffer purely in hardware :-P  But seriously, the more I use your products, the more I appreciate them - keep up the great work!

[Andreas]

Hi,

 

I can forward your request, but I am not sure if or when any future revisions or designs of the Dongle is planned. Note also that a dongle is as the name implies intended for use plugged into a USB port, for battery operated applications we have other reference designs. Of course we can not have a reference design for every possible application, very specific use cases might require a custom board.

As for the PTR clear task register, that is an IC fix and thus a larger fix. I will forward, but this will likely not be addressed before any future products.

 

Best regards,
Andreas

[Andreas]

Hi again,

 

Could you elaborate a bit on what you intend to do with the PTR clear task registerand why you need this, if possible by an example? We would need this to evaluate the feasibility and be confident we are addressing what you are actually missing.

 

Best regards,
Andreas

[SmallerPond]

Well, I was just sort of wishing out loud, hoping you might be a genie of some sort, but if you are serious, here is the setup:

I have a sensor that sends an interrupt when its FIFO is full. I then read the FIFO via SPIM as fast as I can (EasyDMA in List mode), then send that data via BLE to central.  Sometimes there is plenty of time to send the data via BLE before I get another interrupt, sometimes I get the interrupt while the buffer still contains data.  To me, the easiest way to solve this is to use a ring (circular) buffer, which is what I have now.  I have an array of ArrayLists (call it fifo_buff) that can hold FIFO buffer size * 4.  PPI connects TIMER0 and TIMER1 TASKS_COUNTs to SPIM EVENTS_END, and SPIM TASKS_STOP to TIMER0 EVENTS_COMPARE (TIMER0 COMPARE = FIFO buffer size and TIMER1 COMPARE = fifo_buff size).

In a perfect world, I would have PPI also connect TIMER1 EVENTS_COMPARE to a register that reset SPIM->RXD.PTR to point to fifo_buff[0].  Instead I have to enter the TIMER1 interrupt to clear this pointer, possibly getting preempted by the SoftDevice.  If it was all in hardware, I would never have to worry about missing a read from the FIFO.

Incidentally, this is not the first time I have had this scenario occur.  Could just be that I make devices that are too similar :-P

[Andreas]

Hi,

 

Thanks, this should be understandable. I will forward it internally.

 

Best regards,
Andreas