Thingy 53 + nRF7002eb supply anomaly

[aamoros@INVOLI]

Hello,

I am evaluating the Thingy 53 + nRF7002 EB for Wifi and Bluetooth scanning. 

But depending on which power source I plug the devkit, the wifi interface doesn't set up. For instance, on the same PC, one USB port can deliver enough power, and another one (with the same hardware characteristics) does not.

I assume it's related to the nPM1100 power management IC, because USB port detection can limit VBUS current on the board. Nevertheless, I tried to set the GPIO ISET high to have a limit of 500mA instead of 100mA but nothing changed.

I run on  the sample app called wifi scan the board and connect it with a 3.0 USB cable.

Please, can anyone give a clue on this issue ?

[Amanda Hsieh]

Hi, 

It needs to build for the nRF7002 EB with Thingy:53 and program the image to make nRF7002 EB get power and work, for example:

west build -b thingy53_nrf5340_cpuapp -- -DSHIELD=nrf7002eb

See Getting started with nRF7002 EB doc.

Regards,
Amanda H.

[aamoros@INVOLI]

Thanks for replying.

I have done this in the build configuration tool of nRF connect sdk extension for VS code, following this instruction:

To build with the nRF Connect for VS Code extension, specify -DSHIELD=nrf7002eb in the Extra Cmake arguments field.

Would it change something ?

[Amanda Hsieh]

aamoros@INVOLI said:

For example, it works when I plug the thingy 53 in my personal laptop but not in my professional laptop...

Do you install the related firmware on another laptop such nRF Command link tool? When installing JLink on a completely new system, the default behavior is not to install the USB driver(s)! You should enable it.  

[aamoros@INVOLI]

Thanks Amanda, we installed the driver correctly on every computer used for testing. 

Nevertheless, the issue is still there...

These are new pieces of information: 

- The USB port where the Thingy is supplied properly has "USB charge capability" and the others do not

- If we plug the Thingy directly into our USB C port the expansion board is not powered ("Interface not up") but if we plug the Thingy into a USB hub connected to this same USB C port it works!

I hope this will help you to find a clue about this issue. In our opinion, it is related to USB negotiation by the  nPM1100 power management IC.

[Amanda Hsieh]

Hi, 

Could you power the Thingy:53 from USB only, i.e. without the battery connected? If the USB port is limited to max 100mA, then the nPM1100 should be able to supply the system with its DPPM feature,https://docs.nordicsemi.com/bundle/ps_npm1100/page/chapters/charger.html#ariaid-title10, i.e. for any load above 100mA it will draw that from the battery to ensure that the system gets sufficient power. 

-Amanda H.

[aamoros@INVOLI]

Sorry I didn't give you the information, but all my tests were already without the battery.

[Amanda Hsieh]

Could you do a logic trace of the D+ and D- lines on the Thingy:53 when its connected to the USB port of the PC?  That would help us identify if its the nPM1100 that fails to conduct the CDP/DCP port detection or if the PC indicates that its a SDP.  The nPM1100 HW does not do any negotiation in the case of a SDP port, this needs to be done by the application on the Thingy:53. This is not implemented in the Wi-Fi samples as far as as I know so eventough the ISET pin is set High, it doesn't necessarily mean that the PC will allow the Thingy:53 to draw more than 100mA until a proper negotiation has been performed. 

[aamoros@INVOLI]

First packet

Second packet 

Third packet 

Time difference between 2 packets 

I could only capture the first 3 packets on the line, I hope it's enough to understand the negotiation behaviour. 1ms is separating them.

[Sigurd]

Hi! 

Amanda is out of office, so I'm replying instead.

Just to be 100% sure here, what is the D- and D+ signal in your plots? Is the yellow D- or D+ ?