Hey everyone, I’m trying to interface a CH32V003 J4M6 (SOP8 version) with an I2C touch sensor IC, and I need to send I2C commands to the sensor within 10-15 ms of power on to put the touch sensor into its configuration mode.
After some experimentation, I’ve found that it takes approximately 30 ms for the CH32 to start doing anything after power on. I thought maybe this could be due to slow runtime initialization code or long delays waiting for the PLL to lock, so I wrote a bare assembly program that immediately sets up RCC and GPIO registers so I can toggle a GPIO pin (using the 24MHz builtin RC oscillator), but I still see about 28 ms between between power to the IC and the GPIO actually toggling.
My test setup consists of nothing more than a CH32 chip with a 100 nF decoupling cap between power and ground and some header pins I can attach probes to. I’m using a Digilent Analog Discovery 2 in logic analyzer mode to take measurements.
Is this chip just slow to start up, or does anyone have any ideas how I could get it to start up faster?
From datasheet: Power-on reset is 17ms.
Which i2c sensor is that? Do you really have to initialize it within 15ms, blocking configuration otherwise?
What a curious i2c sensor that requires config within 15mS of power up.
Can you post a data sheet?
Yes, that is odd regarding the I2C device, and I suspect the OP is misreading its datasheet.
With that said, 17 ms of startup time is not too bad actually. Try that with an ESP32.
With that said, 17 ms of startup time is not too bad actually. Try that with an ESP32.
I expect you'll recall that Gigadevice's Arm and RISC-V GD32*F103 MCUs take about 130 ms to start up (or wake from the deepest sleep) as they copy in-package but separate die cheap slow flash into SRAM.
How long for ESP32? And which one?
With that said, 17 ms of startup time is not too bad actually. Try that with an ESP32.
I expect you'll recall that Gigadevice's Arm and RISC-V GD32*F103 MCUs take about 130 ms to start up (or wake from the deepest sleep) as they copy in-package but separate die cheap slow flash into SRAM.
How long for ESP32? And which one?
Depends on many factors including code size and version of ESP32, I've personally only worked with the -C3, but heard about similar startup times with the -S2/-S3.
It can be anything from about 100 ms to 300 ms+. Some have reported over 500 ms.
And since their "deep sleep" state requires a full "boot" at wake-up, this startup time can be a pretty significant issue for low-power applications.
If OP really does need to configure the sensor IC within 15 ms of power-on, then perhaps the best solution is to (if possible) control power to the sensor with the MCU. Switch it using a P-channel MOSFET, or similar.
Another solution could be, if the sensor has a reset line, to control that with the MCU. Hold it in reset until you're ready to configure it. Would need to use an external pull-up/down resistor as appropriate to hold it in reset during MCU power-up, until the MCU can override.
The touch sensor is an Azoteq IQS211B. When the chip first powers up, there is a brief window where you can access debug/programming settings through an I2C interface before it kicks over to whatever operating mode has been burned into its OTP memory. The chips that I have are unprogrammed and default to outputting touch detection and motion detection logic signals on the two IO pins if they aren't put into I2C mode right at the start.
I had no idea MCUs could take so long to start up.
Oh well, worst case, I can just burn an OTP configuration that enables the I2C interface full time or just control power to the touch sensor from my microcontroller.
Thank you for the responses!
As HwAoRrDk suggested, if you really need to access it within a certain time after it powers up, just control its power from the MCU with a power switch.
That touch sensor has low enough draw to be powered directly from a GPIO you don't even need an external PFET switch.
Can you post the code for this ?
- It would be helpful for Debugging & Analysis.
I would like to see the I2C code used here.