Changes

These reside in mcu-module .rodata, are uploaded to MCU register 0x05 and are usually size 0x4003 bytes. (0x4000 bytes with 3 byte magic "jhl"?)

These reside in mcu-module .rodata, are uploaded to MCU register 0x05 and are usually size 0x4003 bytes. (0x4000 bytes with 3 byte magic "jhl"?)

There exists an alternate code path where uploading is done using register 0x3B (decided by making some nonsense conclusions about registers 0x0F and 0x10). This may be a "hack" around early versions of MCU? Register 0x3B is RTC-related on recent versions of MCU, and the "nonsense" condition is not met even on factory MCU firmware.

There exists an alternate code path where uploading is done using register 0x3B (if register 0x0F is zero meaning all peripherals are turned off, and 0x10 must be 1 (power button pressed/held)). This may be a "hack" around early versions of MCU? Register 0x3B is part of the RTC alarm registers on recent versions of MCU. Before the upload could commence, WiFi is turned off via GPIO (could be done via <code>mcu::NWM</code> command 0x00050040), then after the upload completed, the sysmodule waits exactly one second, then turns WiFi back on via <code>gpio:MCU</code> command 0x00020080(0x40000, 0x40000).

On dev-units, the user-facing representation of this firmware version is displayed by first subtracting 0x10 from the major field (raw register 0x00). It is these user-facing versions that are displayed in the table below. It is unknown what bit4 (0x10) actually represents, but it is seemingly always set.

On dev-units, the user-facing representation of this firmware version is displayed by first subtracting 0x10 from the major field (raw register 0x00). It is these user-facing versions that are displayed in the table below. It is unknown what bit4 (0x10) actually represents, but it is seemingly always set.