Battery:
Specification for Lithium-ion cell: 65 mAh, 3.7 V.
Specification for Lithium-ion cell: 65 mAh, 3.7 V.
Failed device issue:
We currently have two pilot customers, each with approximately 20 devices.
We currently have two pilot customers, each with approximately 20 devices.
- Scenario 1: The first customer has already deployed the devices on birds. Within three days, about ten devices exhibited anomalies one after another, followed by occasional additional failures in the subsequent days. The failures occurred too rapidly to identify any clear pattern.
- Scenario 2: According to feedback, the second customer has not yet deployed the devices on birds (they may still be in storage). On a certain day between 4:55 and 7:26, nine devices rebooted. Afterward, they began rebooting every few hours. After some time, the reboots became irregular again.
- Scenario 3: We conducted our own test with devices placed on a balcony, and two units showed anomalies, named test1 and test2:
- test1: Tested by colleague J. Confirmed as an internal reset with stable 3.3 V power. A new firmware version with added RCC status logging was reflashed, and the issue did not reoccur within three days—still under monitoring.
- test2: Tested by colleague K. Also confirmed as an internal reset with stable 3.3 V power. I will now read the MCU’s internal status via J-Link.
All lab-test-related information I’ve shared with you so far is based on testing results from test1 and test2.
In all three scenarios, when anomalies occurred, our platform reported battery voltages between 4.0 V and 4.2 V.
Device configuration:
The device currently collects data once per hour and uploads data via the 4G module every 8 hours.
The device currently collects data once per hour and uploads data via the 4G module every 8 hours.
Device workflow:
Under normal operation:
Power-on / Reboot → Log reboot event → Collect data once → Upload all historical data to the platform → Enter 1-hour sleep → Upload all historical data → Collect data → Sleep 1 hour (repeat this cycle 8 times) → At the 8-hour mark, upload all historical data → Collect data → Sleep 1 hour (repeat this cycle again) → LOOP.
Under normal operation:
Power-on / Reboot → Log reboot event → Collect data once → Upload all historical data to the platform → Enter 1-hour sleep → Upload all historical data → Collect data → Sleep 1 hour (repeat this cycle 8 times) → At the 8-hour mark, upload all historical data → Collect data → Sleep 1 hour (repeat this cycle again) → LOOP.
The “1-hour sleep” is implemented via the device_enter_lowpower function, which internally splits the hour into six 10-minute intervals. The relevant code has already been shared previously.
At the time of reboot, logs from both test1 and test2 indicate that the reset occurred inside the device_enter_lowpower function. Similarly, for Scenario 1 and Scenario 2, reboots observed on the platform also follow this pattern—i.e., the interval between reboots and logged events is always a multiple of 10 minutes.
At the time of reboot, logs from both test1 and test2 indicate that the reset occurred inside the device_enter_lowpower function. Similarly, for Scenario 1 and Scenario 2, reboots observed on the platform also follow this pattern—i.e., the interval between reboots and logged events is always a multiple of 10 minutes.
scope plots -->
PLL? This is an unexpected possibility: the PLL derived from HSI, and the repeated switching between PLL and MSI when entering and exiting Stop mode—could this cause a reset?
I only saw in the reference manual that MSI may exhibit overshoot during clock switching, and that it needs to stabilize before being used. In practice, however, I started using it without waiting for it to stabilize.
Everyone, latest update:
- When using J-Link with STM32CubeProgrammer or J-Flash to read a normal device, communication works fine and Flash can be read successfully.
- However, when attempting to read a faulty device with the same setup, various errors occur.
Additionally, STM32CubeProgrammer occasionally crashes when connecting to the faulty device.
Regarding the issue where STM32CubeProgrammer cannot read the Flash, I came across a forum post mentioning that the problem is often due to the chip not being correctly selected. However, in my case, the chip has already been properly recognized.
https://community.st.com/t5/stm32cubeprogrammer-mcus/missing-database-files/td-p/81261
SWD communication should be fine.
And the device has already been correctly identified.
