Skip to content

Add dev bootloader chip erase#1999

Open
NickeZ wants to merge 1 commit into
BitBoxSwiss:masterfrom
NickeZ:nickez/dev-chip-erase
Open

Add dev bootloader chip erase#1999
NickeZ wants to merge 1 commit into
BitBoxSwiss:masterfrom
NickeZ:nickez/dev-chip-erase

Conversation

@NickeZ

@NickeZ NickeZ commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

Add a development-only bootloader command that requests a chip erase after the USB response has been sent.

Expose the command through the Python bootloader client and defer execution until outgoing transport writes are idle.


It was useful to restore debug access during experiments with bootloader.

@NickeZ NickeZ requested a review from benma June 23, 2026 10:37
Add a development-only bootloader command that requests a chip erase
after the USB response has been sent.

Expose the command through the Python bootloader client and defer
execution until outgoing transport writes are idle.
@NickeZ NickeZ force-pushed the nickez/dev-chip-erase branch from f11f7de to 17899b0 Compare June 23, 2026 12:59
// Reset and halt the device
r

// Temporarily disable bootloader protection before flashing.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? Doesn't the chip erase bootprot too?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the user row is not reset by chip erase.

Comment thread src/bootloader/startup.c
da14531_handler(frame, uart_write_queue);
}
if (!hww_data && rust_bytequeue_num(uart_write_queue) == 0) {
bootloader_process_pending_action();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why all the effort to wait until the response is done and not do it right away when handling OP_CHIP_ERASE? We do it too for the hww reset and reboot API calls in the firmware - the client simply knows to not expect a response in these cases.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, we are pretty unique in having a request/reponse protocol and allow some requests to not have responses, so I totally forgot about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants