# Lappy v0.1.2 — clean startup and boot wordmark

The owner observed snow/noise when pressing PWR from the off state, including short presses that do not complete startup. The previous application enabled saved brightness immediately after LCD initialization, before LVGL had drawn its first frame. That is a confirmed ordering issue capable of exposing undefined display memory. It is not proof of the entire physical short-press symptom; no cold-power trace was available.

## Startup and shutdown changes

- Drive the active-low backlight GPIO HIGH as the first application action, before NVS work. Board initialization repeats this safe state before other peripherals.
- Keep PWM at off duty and EXIO1 / BL_EN disabled during setup. Allocate and zero the frame/rotation buffers.
- Render a full 640×172 LAPPY wordmark frame, wait for all ten DMA chunks to complete, then enable BL_EN and restore saved brightness. A serial message records this point for the physical check.
- Show the centered amber wordmark on black for at least 600 ms while platform, storage and BLE tasks initialize; then enter the existing instrument UI. Normal brightness steps remain 40/60/80/100%.
- After a successful manual shutdown save, blank PWM, disable BL_EN and request LCD display-off before releasing SYS_EN. A display-off command failure is logged, while the saved shutdown still completes.
- The native simulator briefly previews the shared wordmark on app launch. Existing instrument pages, mode controls, quality policy, Drag/Track calculations, raw capture, SD data and pairing/settings formats are unchanged.

The selected boot artwork is the centered amber LAPPY wordmark on black. Its isolated source is `main/boot_logo.hpp`; the exact shared LVGL preview is `design/screenshots/v0.1.2/boot-logo.png`. There is no SD custom-logo loader or Settings control in this patch.

The pinned AXS15231B 1.0.1 driver's `disp_on_off` callback uses the opposite boolean meaning from ESP-IDF 5.4.2 and discards its transport result. Shutdown therefore sends controller DOFF (`0x28`) directly with the same QSPI command encoding the driver uses. The managed dependency is not edited.

## Physical limits and required check

Firmware can display a logo only after the CPU and display initialize. It cannot replace a transient that happens during ROM/bootloader execution or a short power pulse that never reaches application code. Early GPIO blanking and safe shutdown improve the sequences under application control; they do not certify removal of every cold-power flash. The owner reports noise on battery-powered startup and at the instant of USB insertion, but not from PWR presses once USB is connected. That pattern makes initial power application the main suspect; its exact electrical timing remains unmeasured.

Both board profiles compile and existing host/native suites pass. All 126 previous LVGL screens are compared with v0.1.1: 125 are identical, with only Settings' version string changed. The additional boot-logo render makes 127 screens. The patch was subsequently flashed to the owner's V2; first-frame events, retained settings, SD recording, five-course catalog, continuing display/touch polling and saved shutdown/restart passed the [limited bench check](HARDWARE_BENCH_v0.1.2.md). The owner visually confirmed the logo followed by the normal UI. Battery cold startup still shows a glitch before application blanking and the logo; short taps still show the glitch without completing startup. **v0.1.2 does not eliminate that initial cold-power glitch.**

Physical acceptance: compare battery-only cold start and USB-powered restart; try a short PWR tap and a held startup; confirm a dark interval followed by the logo and normal page at the saved brightness; verify the serial first-frame message, continuing display/touch counters and manual save/shutdown. The very earliest pulse may remain a hardware/bootloader limitation.

References: [Waveshare's V2 schematic](https://github.com/waveshareteam/ESP32-S3-Touch-LCD-3.49-V2/blob/main/schematic/ESP32-S3-Touch-LCD-3.49%20V2.pdf), the pinned Waveshare examples under `.cache/reference/waveshare-v2`, and [AXS15231B controller states/power sequencing, sections 4.11 and 6](https://files.waveshare.com/wiki/common/AXS15231B_Datasheet_V0.5.pdf). The noise diagnosis is an inference from the observed symptom and application ordering, not a measured vendor defect.