> It seems strange to me that data-logging flash wouldn't be a dedicated FRU module, instead of being in the same chip(s) as the actual firmware. I see how this

> It seems strange to me that data-logging flash wouldn't be a dedicated FRU module, instead of being in the same chip(s) as the actual firmware. I see how this could easily happen as a BOM-reducing or size-reducing measure for something like a cloud thermostat, but for a luxury car? It is strange no one performed back of the envelope calculations on flash life vs logging size. I've worked in embedded, we had a time series based rolling log. Flash life calculation was done at regular intervals. IIRC with what we shipped, the flash chip would outlive the battery by 3x or 4x. And that was without wear leveling! We were smart enough to continue the rolling log at the last point on flash we uploaded from, avoiding the mistake I've seen some products do of starting over from the very "beginning" after every log sync. Do that and you end up with 10% of your flash worn down to nothing and 90% of your flash going unused. Also, unless needed, please stop using JSON. Use a binary format instead. Protobufs is trivial to get up and running almost anywhere. Other binary encoding formats may serve a product's needs better. JSON is fine if everything is low bandwidth web services talking now and then, or low friction HTTP APIs, but for other use cases... use something else. Worst I ever saw was XML being used to RPC invoke every single function call, even local ones. All params got packed up in XML, sent over to the destination, who'd then unpack the XML, execute, and package up the return value. A double digit % of the CPU was being used on XML serialization and de-serialization. (If your choice is that or JSON... probably go with JSON!) Logging flash being same as storage flash is super weird though. Though if their MCU only supports hanging a single flash chip off of it, I could see it happening.