stabilizer
stabilizer copied to clipboard
quartiq
Store device identifier and broker in non-volatile memory
Currently, stabilizer generates an identifier using the binary name and MAC address. We should allow this default to be overridden by the user and the value should persist to non-volatile memory.
Using the unused flash bank for storage should be sufficient.
This is a follow-on to #276
We also would want to store application-specific settings as well, e.g. for driver, as noted by @nkrackow
This will likely also necessitate the addition of a serial terminal to stabilizer to facilitate configuration of the initial network parameters. We may want to leverage some of the serial code on Booster for this
We should look into using https://crates.io/crates/sequential-storage to do this, as this is what the crate was designed for. Should eliminate excessive wear on the flash, but we may need to update the various linkers/flashing tools to not erase the storage part of flash during firmware updates.
~~@jordens I was looking in to this and I realized that Stabilizer doesn't expose a USB port on the front to use for communications. As such, I guess I'm not entirely sure how we'd expect the user to bootstrap some of these configurations, as right now the only communication interface is via Ethernet + MQTT.~~
~~However, the goal here is to provide some initial interface to allow users to set up that interface.~~
~~There's a UART debug header, but that seems like an error-prone way to ask users to configure things and doesn't necessarily feel like an improvement.~~
~~Did you have any ideas here as to how the user would update information like the MQTT broker or ID?~~
Scratch that, I missed the USB page of the schematic and didn't see the USB port because it was hidden underneath the RJ45 jack.
One difficulty I'm noticing here is that the sector size of flash on our device is 128KB. That means we're going to need to be able to buffer 128KB of data in RAM during an erase cycle. We have plenty of RAM (there's 1MB available), but I don't think the linker is set up to use it all. I'll look at how we can leverage it all. Specifically, using the sequential-storage crate, we'll need to allocate the 128KB on the stack.
I think what may make the most sense is to link the stack into a separate RAM section from the rest of memory, since the H7 segments the available RAM into a number of different contiguous sections.
The sequential storage crate requires a buffer of a flash sector in case it needs to do an element modification I believe. I'll have to look at why it requires this, it seems like an odd requirement.
Ah. I guess that it supports writes until it has to compactify the storage.
It looks like it's because, when erasing a flash block after wrap-around, there could be elements in the block that don't exist anywhere else. Thus, it buffers the block and then writes-back elements that only existed in that block to prevent accidental erasure.
I suspect we could update it to accept a user-provided buffer and change the algorithm for single-element detection somehow to ease the stack usage here. I don't think it was intended that 128KB would be allocated on the stack.
Isn't that what I said? Let's just not use sequential storage. Flash endurance will be fine for our application.
I'm actually working with Dion to resolve it, it sounds like a fix would be trivial (i.e. remove the stack allocation and just reserve a single flash block for write-ahead in the future).