You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Latch is opening its public-preview phase around one question: when your embedded device reboots after a failure, what evidence do you wish had survived?
Share the failure mode you deal with, along with the board/MCU, RTOS or bare-metal environment, compiler, reset path, and storage constraints. Brownouts, watchdog loops, corrupt stacks, field-only faults, retained-RAM surprises, and interrupted Flash writes are especially useful context.
Good places to begin:
Try the host capture-and-decode demo in PR #10 while the public-launch baseline is under review.
Browse help wanted if you can test FreeRTOS, Zephyr, or real hardware.
Use Q&A for integration help and Ideas for protocol or architecture proposals.
Please remove device identifiers, production keys, proprietary firmware, endpoints, and captured customer memory. Security-sensitive findings belong in private vulnerability reporting, not a public discussion.
The most helpful early feedback is concrete: what failed, what disappeared at reset, what storage survives, and what a useful post-reboot envelope would need to contain.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Latch is opening its public-preview phase around one question: when your embedded device reboots after a failure, what evidence do you wish had survived?
Share the failure mode you deal with, along with the board/MCU, RTOS or bare-metal environment, compiler, reset path, and storage constraints. Brownouts, watchdog loops, corrupt stacks, field-only faults, retained-RAM surprises, and interrupted Flash writes are especially useful context.
Good places to begin:
good first issue.help wantedif you can test FreeRTOS, Zephyr, or real hardware.Please remove device identifiers, production keys, proprietary firmware, endpoints, and captured customer memory. Security-sensitive findings belong in private vulnerability reporting, not a public discussion.
The most helpful early feedback is concrete: what failed, what disappeared at reset, what storage survives, and what a useful post-reboot envelope would need to contain.
All reactions