Open alevy opened 7 years ago
Finding: the I2C lines are screwed up while the nRF is power-gated because they are not isolated
Following the steps above on your branch (commit: efd845) with:
PB[06].configure(Some(A));
--dtr 0
!NRF_PWR_EN
netRunning miniterm.py with --rts 1
and --rts 0
both result in the sensors app printing data correctly. I have checked that RTS actually changes values. I have tried non-high-current USB ports. Running off of a power supply I see that the board draws 13 mA (without USB attached). The !NRF_PWR_EN
net is 3.3 V and the VCC_NRF_3V3
net is 2.8 V. The results are the same on both Imix boards at Michigan.
I cannot directly replicate your results with this setup. I find the RTS line to have no impact on the sensors app.
In these tests, Imix is powered through USB (from a high-current USB port) and !NRF_POWER_EN
is tied to different voltages.
Running the low power app on the nRF51822:
VCC_NRF_3V3
= 3.3 VVCC_NRF_3V3
= 2.8 VVCC_NRF_3V3
= 0 VRunning the tock-nrf51822-serialization-sdk11-s130-uart-conn app on the nRF51822:
VCC_NRF_3V3
= 3.3 VVCC_NRF_3V3
= 2.6 VVCC_NRF_3V3
= 2.6 VNoting that 2.6-2.8 volts is probably enough for the nRF to be running. I tried directly tying the VCC_NRF_3V3
net to ground. In this case, without the USB connected, power draw increases from 16 mA (running the tock-nrf51822-really-long-name-uart-conn app) to 24 mA. Moreover, while tied low, the sensors app does not function. Letting go starts it again.
Adding a "Starting" message to the start of the app shows that the app is not restarting. Rather, the SAM4L is hanging and then continuing the application. Inspection shows that the I2C bus connecting the SAM4L, nRF51822, and Sensors falls to 0.3 volts when the VCC_NRF_3V3
is zero. This causes the bus to hang.
The problem is that the I2C bus is pulled up to VCC_SENSE_3V3
but is connected to the SAM4L on VCC_MCU_3V3
and the nRF51822 on VCC_NRF_3V3
. If you actually intend for the voltage domains to be separate and gate-able, the connections to the I2C bus must be isolated.
1) The transistors for power-gating components are not working. They are not capable of cutting off power from the nRF51822 2) The TWI2 bus is connected to three different voltage domains and isolated from none of them.
We had to deal with both of these problems on the Signpost platform. Taking a look at the backplane hardware rev B (which works except for USB USB works fine tyvm -Pat) should be pretty informative in general.
1) We used the SIP32401A load switch to handle power gating modules 2) We used the FXMA2102 voltage translator/buffer/repeater/isolator designed for I2C applications
The SIP32401A has a really tiny package that's a little hard to get right by hand. If you expect to hand-solder boards you might want to find another part.
Also, both of these parts were selected to fit the low current draw requirements of the Signpost platform. There might be easier to use / less expensive versions that have a higher current draw.
Quick follow-up on those parts, the I2C isolator is actually the more challenging package. I had maybe a 75% success rate on hand-soldering those on first try, 90% on the power switch. That said, they're easy (ish) to validate install with a quick electrical test and usually one reflow was good enough to get them working so not the worst by any means.
Following up with @brghena's post, I believe the NRF is getting back-powered through the IO lines from the SAM4L. @kwantam's explanation for this behavior:
For most i/o pins on CMOS chips the circuit that drives the pin (i.e., that drives it high or low when the pin is in output mode) is just an inverter. The p-channel device in that inverter has drain-body and source-body diodes, and most of the time the source and body are shorted to VDD. This means that the drain-body diode goes from the pin to VDD ( pin -|>|- vdd). Normally VDD is no less than the pin's voltage, so the diode is reverse biased. But if VDD is at ground and the pin is at 3.3 volts, the body diode forward biases and charges VDD up to about 2.7-2.8 volts, which is just what you're seeing.
I think this is essentially what you're also getting at with the I2C lines not being isolated, correct? This issue affects some of the other subsystems that we're trying to power gate, so I'm going to open a new issue ticket for it.
The current proposed fix for this issue is to use analog switches acting as pass transistors. I need to isolate the RF233 SPI (4 pins) and two I2C domains (4 pins), so two of the 74LVC4066 should work (thanks @kwantam). If I use the SIP32401 to solve #12, then I can use the same enable signals to activate the switches. Using an analog switch might actually also provide a fix to #13 if we can selectively connect/disconnect the FTDI DTR line.
This solution assumes that we are OK with manually pulling all relevant GPIO lines to ground when a module is not in use (eg the RF233 RESET/IRQ/SLP pins, etc).
/cc @brghena
There are some un-diagnosed, rather serious interactions between RTS3 and the sensor power rail.
To replicate the problem, first install the Tock kernel from
master
or thebugs/imix-power
branch of Tock:The, install the imix sensors app:
Finally, print the output from the app by running miniterm with
DTR
inactive (HIGH, attached to SAM4L reset) andRTS
active (LOW, default):You should get output resembling the following every second or so:
However, if RTS is forced inactive (HIGH), there is no output:
Note that the console turns off hardware flow control entirely.
Finally, attaching a patch-wire between NRF_EN and GND (to force the NRF51 on) results in output all of a sudden.
More symptoms
Under mainline kernel, with PB[06] assigned to RTS3, the voltage on NRF_EN and SENSOR_EN are never quite 0V or 3.3V. Instead they are closer to 0.06V and 2.2V, respectively. Removing the assignment of PB[06] to RTS3 (by either leaving it disabled or enabling it as an input, e.g.) results in either 0.04V or 3.2V (which seems reasonable?). The overall problem is not fixed, though, and in fact, it makes
--rts 1
stop working and the only way to get any output is to explicitly enable the NRF as well.