EZ-BLE modules manufactured starting in the first work week of 2017 come with the EZ-Serial firmware image flashed on them by default. In order to facilitate easy out-of-the-box testing and experimentation with this platform, the firmware begins rapidly advertising on boot and stays within "normal" (not deep) sleep while waiting for incoming UART communication for EZ-Serial API protocol commands. This operating mode consumes something on the order of 2 mA on average.
You know better than anyone which workaround/alternative options are most suitable for your application, but one thing you might do without increasing the BOM cost would be to insert a non-connected solder jumper in the VBAT trace. This way, the more complicated step of mounting the battery could happen at any time, and then you could electrically connect the battery with a 5-second soldering step whenever you are ready. It does take a bit of extra time, but perhaps less overall than other options.
Note that EZ-Serial can also be reconfigured using the UART interface (P1.4/P1.5 @ 115200 out of the box) and over the CYCommand GATT interface using a BLE client device (see the User Guide on the previously linked page). Your manufacturing process could include a step to connect, enable deep sleep, disable automatic advertisements, and disconnect right after the battery is connected, and this would drop the average consumption down to the single-digit uA range.
The EZ-Serial firmware also monitors its designated ATEN_SHDN pin (P3.4) and will remain in the Hibernate CPU state as long as it is driven low (or pulled by something stronger than about 5.6 kOhms). If you do not need P3.4 in your design, you could pull or tie it to GND on your PCB to prevent any activity whatsoever from EZ-Serial. Once you re-flash your own firmware on, the P3.4 connection would be irrelevant.
If you are considering any hardware changes to accommodate for EZ-Serial's power consumption, I strongly recommend downloading the actual EZ-Serial firmware image from the page linked above and flashing it with PSoC Programmer onto a test module so that you can verify the expected behavior in your custom design before going ahead with any mid- or high-volume production.
Thanks! A very helpful answer, I was not even aware of EZ-Serial and CyCommand. My device is a little too low powered to be able to leave it plugged in for more than a few minutes at 2 mA, and once I connect the serial port, I might as well just program the beastie. But maybe I can reconfigure 3.4 to be a pull down by swapping polarity of some line in an external device (but all my pins are thoroughly accounted for otherwise).
But from my perspective, it'd sure be preferable to ship the device in deep sleep, or have a SKU that comes that way.
However, this doesn't do quite what the documentation claims, as far as I can see.
Hibernation should be a sub-uA current draw state. I put my 214015 on a pioneer board with the EZ-serial firmware programmed, and I can see the command line stuff on my tty. I draw about 5-6 mA. Then I connect pin 3.4 to GND. The tty stops responding, but power only drops to 0.6 mA or so. Seems like deep sleep, not hibernation, and it's too much power for my purpose-- if someone soldered a battery in manufacturing on and left it overnight, the battery would be at death's door by morning.
I was measuring VDD power by puling off the VDD jumper and running it through an ammeter, so I think this power is all power really going to the MCU, right?
You need to set the pins to high-Z and disable the debug part. All components need to be powered down before you enter deep sleep mode.
I have no control over the firmware -- this is the ez-serial 214015 firmware hex file from Cypress. I'm assuming it would do the right thing, but have no source code to verify. Even if I could change it, that would do me no good, since the whole point is to control the behavior of an unprogrammed device, using Cypress' preprogrammed firmware.
also, this is supposed to be hibernate, or at least that's what I think I see in the ez-serial firmware guide, unless they were somehow using "hibernation" colloquially...
There are peripheral functions/operations that can run while the unit is in hibernate, deep sleep, and sleep modes. It could very well be that there are hardware peripherals running in hibernate mode that are drawing the extra current while it is "hibernating".
I investigated the behavior that Jim reported this morning and identified an issue in the way GPIOs are configured at the moment hibernation occurs within EZ-Serial. The CPU is entering the real "hibernate" state with sub-uA current and no active peripherals, but the ATEN_SHDN pin remains in a pull-up drive mode through approximately 5.6k. When this is connected to GND, the resulting leakage accounts for the current measured here. With a 3.3v supply, the current across 5.6k Ohm is roughly 600 uA. As a result, the ATEN_SHDN pin in the current release (v188.8.131.52) is only useful for shutting down all components (e.g. "airplane mode" to disable radio transmissions), but it does not provide the expected low power consumption.
Fortunately, the fix for this problem requires only changing the pin drive mode to Hi-Z digital input, as Bob noted. I have confirmed internally that this fix has been implemented. Unfortunately, this will only help in your case after the next firmware release is finished, tested, and released to manufacturing, which will not happen overnight. This solution will not be viable if you are actively prototyping and wanting to assemble boards now.
If the battery needs to be soldered to the board along with the module and there is a non-negligible time gap between assembly and firmware reprogramming, then the only option to avoid battery drain is to electrically disconnect the power supply from the module some other way (solder jumper for later connection, header pins with a jumper, physical switch, etc.).
There is one other alternative that I mentioned in reply #2 above, and that is to use CYCommand to remotely configure deep sleep mode and no automatic advertising on boot. I confirmed that this drops the power consumption down to the 1 uA range. Doing this requires the following steps:
- Scan for and connect to the new device, which will be automatically advertising as soon as it has power. The device name will be "EZ-Serial XX:XX:XX" where the last part is the last three bytes of the MAC address.
- Write [02:00] to handle 0x001C to enable CYCommand reconfiguration (subscribing to indications on handle 0x001B)
- Write [53:53:4c:50:24:2c:4c:3d:30:32:0d:0a] to handle 0x001B to send the "SSLP$,L=2\r\n" command to enable deep sleep in flash
- Write [2e:43:59:53:50:50:53:50:24:2c:45:3d:30:31:0d:0a] to handle 0x001B to send the ".CYSPPSP$,E=01" command to disable CYSPP auto-start in flash
As soon as you disconnect, the consumption will drop to the ~1uA level and will remain there indefinitely. Note that you will not be able to connect to the device anymore without external triggers, e.g. UART commands or GPIO-based factory reset or CYSPP pin assertion.
I understand that this method may require more access and/or customizability during manufacturing than you actually have, but I still wanted to provide specifics about how it could be done in case the option is useful in any way.
Thanks for investigating! That's really helpful, I had been puzzled about what was going wrong, but couldn't find anything on my end.
So, we haven't ordered our modules yet. Do you have an identifier we could use to determine if our first batch is shipping with the updated firmware?
The order code for modules has not changed, and will not as far as I know even when the EZ-Serial version is updated from v1.0.2 to the upcoming v1.1.0. However, there is a Data Matrix code (like a QR code) printed on each module's shield during manufacturing, and this contains a "YYWW" value indicating the year and work week of manufacture. Many free smartphone code scanner apps are capable of reading Data Matrix codes. EZ-Serial v1.0.2 began shipping on modules at the beginning of WW1701. Future updates will have a fixed switch-over date as well, announced via PCN and always available upon request for confirmation once it happens.
In case you aren't aware of this option, Cypress also sells a few programming jigs for bare modules which you could use to pre-flash your own firmware prior to PCB assembly. This one would work with your module:
As before, I understand that it might require altering the manufacturing process in a way that you can't right now, but it's another tool to consider.