Topic: SCL3710 USB dongle config-based SHORT-CIRCUIT found

When exploring the SCM SCL3710 dongle (bearing the PN531 controller with a direct USB connection to the host) under libnfc 1.3.4 and Ubuntu 9.04 (kernel 2.6.28-19-generic), I have noted the following observations:

i) the sam_switch_en flag (reg. 0x6106, bit 4) is set to zero (basically, it keeps its reset state), while
ii) the SVDD (pin #25) is physically interconnected with other 3V3 VDDs on the PCB (rev 0.2).

According to the datasheet of PN531, the first condition implies that: “…the SVDD switch is disabled and the SVDD output power is discharge to the ground.” Together with the second condition, we should get a kind of short-circuit, since the other VDDs are powered on (to approx. 3.3V).

To verify this hypothesis, I have switched SVDD on while measuring the total direct current consumed by the dongle from the USB host. In particular, to switch the SVDD on, I have used the following instruction code over the libnfc platform:

pn53x_set_reg(pnd, 0x6106, 0x58, 0x50);

where pnd is the particular device handle.

Doing that modification, the current consumption has fallen down suddenly by approx. 31.7 mA (from 67.7 mA to 26 mA)! Therefore, I regard the short-circuit hypothesis true and recommend to use the aforementioned configuration whenever working with SCL3710. By the way, the whole dongle gets much cooler than, especially when working as a target. This is not surprising, since the power dissipation caused by this short-circuit is nearly 160 mW…

Kind regards,
Tom

Re: SCL3710 USB dongle config-based SHORT-CIRCUIT found

Hello,

Excellent work !

Do you think that we should put some code in driver intialization (pn531_usb) in order to switch SVDD on ?
Could switching SVDD on as default configuration produce some side effects on others devices (which may be wired differently) ?

Romuald Conty

Re: SCL3710 USB dongle config-based SHORT-CIRCUIT found

Hello Romuald,
thank you for being interested in this topic.

Regarding patching the code of libnfc – well I still hesitate a bit whether a general patch is applicable for a particular flaw of a particular device. The problem is, of course, that I am not aware of any reasonable way on how to reliably detect we are working with SCL3710 instead of possibly other dongle bearing the PN531 controller.

On the other hand, I am neither aware of any reasonable HW design where turning SVDD on (say accidentally) should produce some harm. I do believe that no designer would ever tie SVDD directly to the ground, etc. :-)

Even if there is a SAM already installed, then its (accidental) on-powering without changing the internal serial data switch of PN531 should not produce any problem. Furthermore, there is a current limiter that allows us to detect an eventual SVDD overload. The documentation is, unfortunately, inconsistent in the precise value of the current breakpoint (in one place they say 30 mA, somewhere else is 100 mA), but I would simply assume it is designed to protect the chip anyway.

So, finally, I would vote for updating libnfc to turn SVDD on during PN531_usb driver initialization, as you have suggested.

The idea of using the SVDD overload detection is illustrated in the following simple code:

/* turn SVDD on */
pn53x_set_reg(pnd, 0x6106, 0x58, 0x50);
/* test for SVDD overload with eventual fall-back to SVDD-off state */
if (pn53x_get_reg(pnd, 0x6106) & 0x20) pn53x_set_reg(pnd, 0x6106, 0x58, 0x40);

Of course, you will probably use a bit different “wording”. This is just an illustration… (however, I have tested this code is already working).

You may also want to add some delay (say dozen of ms) to allow the current to stabilize before testing the overload indicator. The USB framing in the full-speed mode, on the other hand, implicitly delays for several ms, so this may be sufficient provided that you do not want to introduce another operating system dependent code for timing…

Kind regards,
Tomas Rosa