Power-up issues in MKR Vidor 4000: how to recognise, how to fix

[mike_pscan]

Here's an issue I came across while working with the MKR Vidor 4000, and a fix I found for it.
The Vidor module was working OK with small example projects in the FPGA, but when I put in a design of my own that used more of the FPGA's logic capacity, I found that it wouldn't start up when I connected power. I found that the +3.3V pin was at 2 to 2.5V, and the module was drawing almost exactly 100mA from its 5V power source.
Studying the schematics, I found that when you power the module through either the USB port, the +5V pin, or the VIN pin, the power has to pass through a battery-management chip. (This is to support the option of powering the module with a Li-Po battery.) This battery-management chip (U12, a BQ24195LRGET) has the ability to detect what type of USB power source is connected, and limit the current it draws from that source. The first issue that occurred to me was that this isn't going to work when power is supplied through the +5V or VIN pins, and there is nothing connected to the USB port. But I found that it was no better when using a high-current USB charger, and there's a reason for that.

Fig.1 is a cutting from the schematic, where the USB signals connect to pins 2 and 3 of the battery charger IC, via the 0R links R59 and R60. Fig. 2 is a photo of that IC.
See the pair of tracks snaking below the IC? These are the USB signals, and you can see that between these tracks and the IC there are positions for two chip components which are not fitted: these are R59 and R60 on the schematic. So it doesn't matter what power source you used, the battery-management IC will always use its default current limit, and draw no more than 100mA from it.

Now you could try soldering some wires across the pads where R59 and R60 should be. But there may be some reason the manufacturer left these links off (perhaps it interfered with USB operation?) and anyway I didn't want to power from the USB connector, I wanted to use the +5V pin. My solution was to connect together pins 2 and 3 of the IC without making any connections to the USB signals, by adding a wire as shown in fig. 3.
This makes the battery-management IC think that the USB data lines ares shorted together, which signals that the power source is capable of supplying 1.5A. This has successfully fixed the issue for me.

I have since realised that there may be an alternative, software-only, solution to this problem. If 100mA is enough to power up the module to the point where the user application in the microcontroller is running, and it's only when the FPGA is configured that the power is insufficient, then you could try making the microcontroller write a register in the battery-management IC to tell it to set its current limit to 1.5A. This is a I2C write (write value 0x35 to register 0) that the micro would have to do before triggering the FPGA configuration process. I know that writing this register can change the current limit, but I've only done this from the FPGA, not the microcontroller, which is not so useful.
For reference, the I2C address of the IC is 0x6B, so you should just need to send the bytes 0x00, 0x35 to this address in a write transfer (fig. 4).

[mike_pscan]

So, the two thoughts going round my head of "I should try getting the micro to configure the BQ24195L current limit before configuring the FPGA" and "I wonder why nobody has encountered this problem before?" finally collided, and it occurred to me to see whether the bootloader that comes pre-programmed in the micro already does the BQ24195L configuration.

I put a logic analyser on the I2C pins, and lo and behold it is indeed doing that. For reference, these are the I2C transfers that it performs:

• value 0x8A written to register 5

• value 0x01 written to register 1

• value 0x37 written to register 0

• value 0x37 written to register 0

• value 0x00 written to register 2

• value 0x9A written to register 4

These are all to I2C address 0x6B, the address of the BQ24195L. The important thing for this topic is the write to register 0: this sets the input current limit to 3A, the highest it can be set to. The other register writes configure the way the battery is charged.

The upshot of this is that what I thought was a big issue is not a problem if you are using the Vidor 4000 in a "typical" way. It will only be a problem if you are putting your FPGA program at the start of the flash chip and providing a clock to it, so that it can start running before the bootloader in the SAMD micro gets a chance to configure the BQ24195L; or if you wire the I2C pins to something that stops the I2C comms from working.

Unimportant side note: the I2C transfers look odd on the logic analyser. Each transfer is attempted twice, first with separate transactions for the register address and data (which doesn't work), then with one transaction carrying the address and the data (correct). It seems like someone was uncertain how to use an I2C peripheral, tried two ways and left them both in the code.
I'd be interested to see the source code for the Vidor 4000 bootloader, if anyone knows where to find it.

[mike_pscan]

Actually, ignore that bit about the I2C transfers looking odd on the logic analyser: I was just misunderstanding what was happening. Each register in the BQ24195L is being read before being written. I put the bootloader binary in Ghidra and found the code that configures the BQ24195L, it goes like this.

  uVar1 = bmic_i2c_read(5);
  if (uVar1 != 0) {
    bmic_i2c_write(5,uVar1 & 0xce);
    uVar1 = bmic_i2c_read(1);
    bmic_i2c_write(1,uVar1 & 0xcf);
    uVar1 = bmic_i2c_read(0);
    bmic_i2c_write(0,uVar1 & 0x87 | 0x30);
    uVar1 = bmic_i2c_read(0);
    bmic_i2c_write(0,uVar1 & 0xff | 7);
    uVar1 = bmic_i2c_read(2);
    bmic_i2c_write(2,uVar1 & 1);
    uVar1 = bmic_i2c_read(4);
    bmic_i2c_write(4,uVar1 & 3 | 0x98);

[Elbjornbjorn]

Thanks for the info, this might be useful for me. I have an issue where a sketch works fine when the mkr vidor is connected to my computer via the USB port, but has issues when left unconnected. In all cases the mkr vidor is powered with 5V on the VIN pin, and the sketch works as long as the USB is connected during boot, i can disconnect it later without issues.

Anyways, i'll look into this, thanks for the heads-up!

Edit:
Thinking some more about this, i've come to the conclusion that it's probably a problem with the battery charging IC ( I've used the I2C pins for other things in my design, so the registers probably arent written to properly during bootup). From the datasheet, it seems like the current limit is set to 100 mA if ID = 0, ie without USB plugged into a master. I'll test hooking ID to 5v to see if this solves the issue.

Further edit:
I didn't put 5V on ID fortunetely, that probably would've fried something. ID is pulled up to 3v3, and stays 3v3 when the USB cable is plugged in, so it qouldnt have worked anyways.