Hi,
I’ve just received my first Particle mesh devices and checked the circuitry.
Is it correct that there is no external crystal?
At the moment, I see over 1mA during sleep and the missing crystal could have an impact on current consumption (according to Nordic several hundred uA)
Edit: Oooops, I’ve found the schematic and it seems there actually IS an external crystal. Sorry!
Sleep modes are not yet implemented as of 0.8.0-rc.25. Even though you can call System.sleep(), it doesn’t actually do anything, so it’s not representative of the actual current consumption in sleep mode.
I’m using Zephyr, but ssshhhh 
@rickkas7 is it supported or at least tolerated to run the Mesh devices with other firmwares (like Zephyr)?
I’m trying to port the Boron 2G/3G and run into issues regarding the modem.
@derchris, 3rd party Zephyr firmware would ONLY be supported by that 3rd party. Particle would not guarantee their hardware to run anything but their own firmware.
well, Zephyr is an open-source OS and I guess it is a strategic decision Particle has to make
@derchris, Zephyr is pay-for-play for commercial use. It wouldn’t make much sense for Particle to support 3rd party firmware since they have their own ecosystem. Particle’s firmware is also open-source.
@rickkas7, any thoughts to add here?
I agree that it‘s not an easy decision.
FYI, we‘re currently working with our custom hardware which actually is pretty close to the Mesh devices (nRF52840 + BQ24295) which costs us 25$ in 100s units.
So if we could buy Xenons or Borons instead for 15$ (in case of Xenon) and were able to skip all the certification stuff it was great.
And I‘m not asking Particle to do my work. I‘ll happily port the HAL myself, but it would be great to get some support. At the moment, I can already completely use the Xenon, but I can’t get the modem UART up and running with Boron although VINT is high and logic translator is enabled - and it‘s hard to debug without testpoints obviously
@peekay123 are we talking about the very same Zephyr project with Apache 2 license and free commercial usage?
HAHAHAHA! I thought you were talking about Zephyr, the Micropython platform!!!
I am not sure about certification with different firmware but @rickkas7 or @bko might help. As for the modem, you may want to look at the open-source firmware. Not sure if it’s released yet.
I did some tuning and now I see 35uA idle for Xenon… just to let you know that low current consumptions are possible
edit: Most of the current I see is the quiescent current of XC9258
By the way, there are a few trace jumpers you can cut on the Xenon to disconnect the XC9258 voltage regulator. Then you can apply power to 3V3, such as from a Lithium coin cell battery. There are a bunch of caveats, but it should be possible to do that for really low-power use cases.
I also see about 35.5 uA in Zephyr sleep with no peripherals enabled when powered from LiPo. When powered from 3V3 directly connected to an external 3.06 V source with the XC9258 disconnected it drops to 33.0 uA. (With EN floating I see 224.4 uA, so the disconnect is definitely necessary.)
I suspect the bulk of what’s left is the 25 uA standby current of the MX25L flash. According to the data sheet its draw could drop to 5 uA if programmed into deep power-down mode.
I’m coming from BLE400s which are around 118 uA with an nRF51 and no flash so I’m happy.
@pabigot that (the flash) was one of my guesses, too, so I held CS high w/o significant impact
@derchris The chip comes up in normal standby mode, which is 25 uA; deasserting CS# has the same effect of putting it into standby. You have to explicitly send a command to put it into deep power down mode which is nominally 5 uA. See command description section 12 (command byte 0xB9) and figure 22 in the datasheet.
My analysis above that 35.5 uA could be reduced significantly was based on the mistaken belief the CFI chip was the MX25L1606E, which has standby current (ISB1) of 25 uA with a deep-power-down current (ISB2) of 5 uA.
In fact the Xenon was updated to the GD25Q32C which claims a standby current (I_CC1) typically 1 uA, max 5 uA, which are the same values as the documented deep power-down current (I_CC2).
In practice, when I put the Xenon flash into deep-power-down mode the idle power current drops from 32.7 uA to 23.1 uA (9.6 uA decrease) when powered directly from 3V3 (XC9258 disconnected), and about the same (35.2 to 26.9 = 8.3 uA decrease) when powered by LiPo (XC9258 connected).
So I suspect the GD25Q32C data sheet lies when claiming I_CC1 and I_CC2 are the same at 1 uA typical, but going to deep power down mode is likely to only reduce current by about 8-9 uA. More reduction might be possible by tuning the GPIO configuration.
Update 2019-02-13: Checking the device JEDEC ID and the contents of the SFDP register, the replacement SPI NOR device is not the GD25Q32C but rather the Macronix MX25L3233F, which documents ISB1 (standby) as typically 10 uA and ISB2 (deep power-down) as typically 3 uA. Much closer to the observed 8-9 uA difference.
I was asked to provide code, which is difficult as I haven’t got my real framework in releasable state yet and it’s C++17 but it looks like this:
uint8_t cmd{0xB9};
csn.clear();
rc = spi.tx_rx(&cmd, sizeof(cmd), 0, nullptr);
csn.set();
All you need to do is send the single-byte DP command, which is 0xB9. To wake it up you have to send the RDP command (0xAB).
See sections 10-21 and 10-22 of the MX25L3233F datasheet. (Also see xenon hardware issue #2 for why I’m referencing this flash chip.)
I’ve also been curious about reducing the sleep power as low as possible.
When running from the battery, I think the R21 pull-up resistor is wasting about 5uA of power:
4.2V / (806KOhm * 1000) * 10^6 ~= 5uA
Then if you try to disable the voltage regulator by pulling the enable pin low, I think R18 wastes 21uA.
4.2V / (200kOhm * 1000) * 10^6 = 21uA
It looks like the solder bridges could be changed to connect the microcontroller to the VBAT instead of the 3.3V output from the regulator. However, the XC9258 voltage regulator would still be on and wasting 15 to 25uA.
Possibly you could disconnect solder bridges S1 and S5 to disconnect the microcontroller from the voltage regulator, then connect the battery directly to half of S4 (by passing the lipo connector), and connecting S3 to turn on the microcontroller’s built in regulator. However, I can’t see getting a very reliable solder joint between a wire and half of a solder bridge.
The R21, R18, and XC9258 are all under the RF shield. So there’s no easy way to desolder them.
Possibly with a high enough voltage between the EN pin and the LI+ pin (positive here), one could burn out R18 or the XC9258. I don’t have a spare particle xenon to try that now.
