We originally set the threshold to 10% to enter shipping mode but got a lot of push back that there was a considerable amount of charge left. We finally came to 2% to give several hours, if fully powered, to perform what is necessary to alert the cloud. The 2% margin also accounts for possible drops in temperature that would decrease the apparent capacity.
1 Like
@johannes.nuwiel Our team here in the US and Europe tried to replicate the shipping mode you had but can't replicate it. I noticed that there is a missing "batt_low" publish that should have gone out right before entering shipping mode and I've filed a bug for that.
The only thing that I can think that could interrupt entering shipping mode would be parasitic current powering the Tracker One. We have FETs that essentially decouple the M8 IO from the MCU and is controlled with the CAN 5V enable signal. The CAN 5V signal is disabled when going into shipping mode to decouple the IO.
Hi @eberseth,
thanks for having a look and finally replicating the issue. I know it's buried deep.
Regarding the CAN 5V Enable, on startup of my Tracker I am executing this piece of code which (if it does what it says) keeps the CAN 5V powered on even in sleep mode:
TrackerConfiguration enableIoCanPowerConf;
enableIoCanPowerConf.enableIoCanPower(true).enableIoCanPowerSleep(false);
Tracker::instance().init(enableIoCanPowerConf);
It would be great if this closes the assumption that you made. Otherwise please state what the function enableIoCanPowerSleep(bool) does.
Cheers!
For context, I'll refer to the lower right part of sheet 1 of the schematics. The CAN 5V signal gates the three IO with U4. We had to add this circuit to prevent a small leakage current from parasitically powering the MCU if entering shipping mode. The Tracker One will appear on with a white LED if the leakage current is present. Shipping mode is entered when the low battery state is detected. The bug I could see is the missing publish of the event but the device still entered shipping mode in the end, code.
The truth table for TrackerConfiguration and your settings for enableIoCanPowerSleep(false) instruct the 5V control to avoid automatic shut off during sleep cycles and keeps it powered perpetually in combination with enableIoCanPower(true).
Inside of TrackerShipping::shutdown(), code, there is a call to _ioCallback() to prepare the Tracker One for shipping mode which includes calls to turn off LEDs, watchdogs, and disable the 5V control, code. Your initial symptoms suggested that something was holding the MCU out of shipping mode and the obvious thing I can think of is the 5V control for the leakage current mitigation circuit.
Could you measure the voltage on the 5V output when encountering the problem?
Hey!
I have the same problem that after the tracker has runned out of battery, it's get stuck on boot (with the white led pulsing) when we start charging the tracker.
The infite loop is in file deviceOS/5.3.2/system/src/system_power_manager.cpp art line 942 is called from TrackerFuelGauge::instance().init(); in void Tracker::initBatteryMonitor() at src/tracker.cpp line 361, but I'm wondering how it can be stuck there since it is suround by a watchdog? Would it be better to switch to the hardware watchdog from the nrf instead of the one of the pmic?
// To initialize the fuel gauge so that it provides semi-accurate readings we
// want to ensure that the charging circuit is off when providing the
// fuel gauge quick start command.
// In order to disable charging safely we want to enable the PMIC watchdog so that
// if anything happens during the procedure that the circuit can return to
// normal operation in the event the MCU doesn't complete.
PMIC pmic(true);
FuelGauge fuelGauge;
pmic.setWatchdog(0x1); // 40 seconds
pmic.disableCharging();
// Delay so that the bulk capacitance and battery can equalize
delay(_commonCfgData.postChargeSettleTime);
// ************ stuck here **********************
TrackerFuelGauge::instance().init();
fuelGauge.quickStart();
// Must delay at least 175ms after quickstart, before calling
// getSoC(), or reading will not have updated yet.
delay(200);
_forceDisableCharging = _deviceConfig.disableCharging();
if (_batterySafeToCharge && !_forceDisableCharging) {
pmic.enableCharging();
}
pmic.disableWatchdog();
Hi Cedric,
Could you please test this using the latest develop branch of Tracker Edge? We recently fixed a deadlock condition around the PMIC and Fuel Gauge that could be the root of your issue.
Let me know if this helps.
2 Likes
Hey Morduno,
I incorporated the changes of commit b311265 in my code and now it does not get stuck anymore.
Thank you 
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.