IIS3DWB10IS — ISPU has no NVM: recommended approach for a power-gated battery node?

[kusek]

We are evaluating the IIS3DWB10IS for a battery-powered vibration condition-monitoring node (STM32WLE5 + LoRaWAN, ~5 minute duty cycle, multi-year target on a primary cell). Our current IIS3DWB design measures 1.5 µA for the whole node by cutting the sensor's supply rail between wakes.

Two things in DS14585 Rev 1 / AN6497 Rev 1 (DM01264337) pull against each other:

- IddPD = 26 µA typ makes a load switch effectively mandatory against a 1.5 µA budget.
- The ISPU has no non-volatile memory (AN6497 §1), so cutting that rail also erases the program — every wake has to reload it over SPI before it can do anything.

My arithmetic says reloading is much the cheaper of the two: at a 300 s cycle, roughly 0.07–0.29 mA·s per wake to reload (4–32 KB program) against 7.8 mA·s to leave the part in power-down. Power-gating wins by 25–100×, and only loses if the node wakes more often than every ~5–11 seconds.

But two inputs to that calculation are not in the documentation:

1. What is the ISPU's supply current — while running, and while the program is being loaded? The datasheet gives accelerometer figures (4.1 mA 3-axis, 1.9 mA 1-axis) but nothing ISPU-specific, and this dominates the result.
2. What is the ISPU boot time after BOOT_END is set, and does it scale with program size? AN6497 shows ~2 ms with the supplied templates — is that representative, and is there a documented maximum?
3. Is there a supported way to verify a loaded image (CRC, or a readback recommendation)? With no NVM, every wake is a fresh opportunity for a partial load, and an unattended node has no way to notice.
4. Is a variant with non-volatile ISPU program storage planned?

[Raz]

1. Not in the note anywhere, you are right. You can measure it though. Put the interrupt pin in pulsed mode and toggle it around the part you want to time.
2. The 2 ms is just what ST's own examples take. It is not a limit and there is no maximum given. Your boot time is whatever your boot code does.
3. Yes. AN6497 page 33 shows how to read the RAM back, same steps as writing but you set READ_RAM and the bytes come back out of ISPU_MEM_DATA_1, so you can CRC what actually landed. Easier still, BOOT_END is not set by the chip. Your own ISPU code sets it once your boot code has run, so if the load was bad your code never runs and the bit never goes high. Wait for it with a timeout and reload if it does not come.
4. One for ST.

Raz, Parter (AI supply chain platform)