When the power supply is disconnected from an ME2.0, it should run from the super-capacitor for 0.1 - 10 seconds, so that we can cleanly shutdown, and stop writing to the microSD and internal flash storage, before power runs out.
The objective is to stop corruption of the file systems on the flash memory and microSD card/USB memory stick when power is lost. This is a concern, because we expect that many Mesh Extenders may be run from solar panels alone, or batteries that are insufficient in capacity to prevent the unit losing power.
The loss of power is sensed as a falling edge on GPIO24.
When this occurs, we should trigger some shutdown script that shuts everything down cleanly, or in the very least, stops things writing to bulk storage, so that no flash transactions are in progress when the unit powers-down.
A related problem is that if there is a transient loss of power, and GPIO24 goes high again after having gone low, that we need to get everything running again. We could make servald and lbard aware of GPIO24, however sqlite transactions inside servald might take longer to complete than the super-capacitor can power, which is a problem, since such Rhizome writes are quite probable. Using external blobs for storing files would reduce that problem, and may be sufficient.
On the rev2 protoype PCBs, the Super Capacitor is unable to power the ME2.0. The 20 Ohm resistor in-line with the super-cap causes too large a voltage drop. Testing bridging this with 0 Ohms after it has charged improves the situation a little, in that u-boot can be seen for a few seconds while running from the super-capacitor, it fails whenever it attempts to use the DDR RAM, which may be why the board stops responding immediately on the loss of primary power, because the DDR RAM is unable to be powered from the super-capacitor.
Thus there are two sub-issues here, one for the software side, and the other for the hardware side.
When the power supply is disconnected from an ME2.0, it should run from the super-capacitor for 0.1 - 10 seconds, so that we can cleanly shutdown, and stop writing to the microSD and internal flash storage, before power runs out.
The objective is to stop corruption of the file systems on the flash memory and microSD card/USB memory stick when power is lost. This is a concern, because we expect that many Mesh Extenders may be run from solar panels alone, or batteries that are insufficient in capacity to prevent the unit losing power.
The loss of power is sensed as a falling edge on GPIO24.
When this occurs, we should trigger some shutdown script that shuts everything down cleanly, or in the very least, stops things writing to bulk storage, so that no flash transactions are in progress when the unit powers-down.
A related problem is that if there is a transient loss of power, and GPIO24 goes high again after having gone low, that we need to get everything running again. We could make servald and lbard aware of GPIO24, however sqlite transactions inside servald might take longer to complete than the super-capacitor can power, which is a problem, since such Rhizome writes are quite probable. Using external blobs for storing files would reduce that problem, and may be sufficient.
On the rev2 protoype PCBs, the Super Capacitor is unable to power the ME2.0. The 20 Ohm resistor in-line with the super-cap causes too large a voltage drop. Testing bridging this with 0 Ohms after it has charged improves the situation a little, in that u-boot can be seen for a few seconds while running from the super-capacitor, it fails whenever it attempts to use the DDR RAM, which may be why the board stops responding immediately on the loss of primary power, because the DDR RAM is unable to be powered from the super-capacitor.
Thus there are two sub-issues here, one for the software side, and the other for the hardware side.