XVF3800 - Unable to boot via SPI on custom board

[AnkhInnovationsLLC]

Hello,

We've been developing around the XVF3800 & ESP32, and after many attempts and hardware changes have been unable to boot via SPI.

In a development scenario using an ESP32-Pico-DevKit and an SQ66, the XVF3800 boots fine using the same software.

I'm not too sure where the problem is...

1. The checksum of the firmware matches CRC32 -> 2150107238
2. Supplies 0.9v, 1.8v and 3.3v measure OK and are brought online at nearly the same time
3. We followed the design specifications and tried to match the SQ66 design files as closely as possible
4. RST_N is held low for a second or so, then released
5. Clock in the firmware via SPI_CS, SPI_CLK, SPI_MOSI
4. Tried at various clock rates 5 / 10 / 15 / 20 / 25 Mhz

Notes:
1. The XVF3800 wants to power up (pulls more than 1A) from other pins (including I2C and I2S), so we installed level translators on them to keep them isolated.
2. Serial # V16A0 VF3 GT2313P2 1FCA 18.00, pretty sure this is the correct chip for the pre-packed software
3. Because it's the same software as on a bare ESP32 and the SQ66, this rules out the block transfer num, wrong firmware, etc...

Any ideas?


Schematic

[Joe]

The power switch you you for the 0V9 supply (U15) has a minimum VIN of 1.1V so suspect this is the issue. Its RDSon at 1.2V is 141mohm and will be even higher at 0.9V if it even works at all. This will mean there will be large voltage deviations on the 0V9 rail and it will likely go out of spec. I would check the 0V9-DSP rail with a high speed oscilloscope to check the deviation.

Cheers,
Joe

[AnkhInnovationsLLC]

@Joe, thanks for the prompt reply.

We will remove U19 and jump 0.9v directly from the supply rail in this case (for testing) then replace the TCK229's with TCK207AN's.

I just want to confirm with you, that as long as we hold RST_N low then release it when the all 3 power supplies are online, the supply ordering doesn't matter. On our board the 3.3v and 1.8v rails are already active, just not going to the XVF until AUDIO_ON is high. The 0.9v on the other hand is brought online only for the XVF and thus there is some delay as that rail energizes while the other 2 are already being passed in. We wait about 100 ms then release RST_N from low and let it float high.

[Joe]

No problem bringing up the 0V9 supply last.

Your schematic has a pulldown on reset so you must drive the reset line high rather than let it float. Unless your pulldown isn't fitted?

Another small note: All IOs on the xmos device have diode clamps to the the relevant pins VDDIO supply. This is why you see the supplies starting up before you have enabled them as they are being back powered through the IO clamp diodes from driven signals. All the X.. IOs have clamps to the VDDIOT/L/R supply in your case 3.3V. So I would be careful e.g. with your VOICE-ON signal being directly connected to the IO. When this signal is driven high it will back power 3.3V for example. Over time, with large currents, this could potentially lead to shorter device lifespan so is best avoided.

[AnkhInnovationsLLC]

Yes, you're correct in that the resistor R39 is no longer fitted. We made a mistake and realized that RST_N is in the 1.8v power domain, so it's been removed and we let the trace float high when we want to begin the flashing process.

As for the diode clamps that makes sense... A bit odd because if I remember correctly X0D05 didn't exhibit any current draw.

Here is our power up sequence:

• 1. 1.8v and 3.3v are already energized, but yet to flow into the XVF/XU316
  2. Hold RST_N low
  3. All at the same time: bring 0.9v online, enable 3.3v (already online) and 1.8v (already online) into the chip
  4. Wait approximately 100ms
  5. Release RST_N to float high
  6. Clock in the image @ 5 Mhz
  7. Wait 1,000ms
  8. Attempt to communicate over i2c

[AnkhInnovationsLLC]

So it was indeed U15 on the 0.9v rail, thanks @Joe. We'll replace the part with a lower voltage spec for the next run.

Now another question, we only seem to be able to communicate with it over i2c at 20 kHz... The SQ66 development board is the same. Is the bus speed hard coded as such?