I encountered this bug before but wasn't able to reproduce reliably until today.

The bug is that if you put a breakpoint in a place that is somehow special (not sure if it's because of inlining or macros), then after almost each pressing of "continue", there will appear the "Reflashing" window and will reflash numerous times the ELF.

Even if you press the "disconnect" (end session) button, it will first reflash MCU several times before disconnecting.

Example of such breakpoint can be seen on this attached screenshot - if you set it, it will trigger the above bug, once you remove it, Ozone will again work normally without the spurious reflashes:




OS: Ubuntu 20.04 LTS
JLink libraries: 7.64
Ozone: 3.26d
MCU: STM32F427VI

I was trying to find smallest example that triggers it, but could only find this one in Rust for Raspberry Pico: github.com/rp-rs/rp2040-project-template

Breakpoints put on some lines will also trigger the "reflash several times after continue or before disconnect", seems that breakpoints on "info!" lines will cause it as well on second attached screenshot:

OK, interesting idea, but it would make sense if a function is inline that it will set more than one breakpoint, but I will have to test that. Both of those ARMs ahve either 4 or 6 HW breakpoints.

Does "Type=Flash" or "Type=Mixed" mean it's setting the those flash breakpoints?

Thanks! You were right, I guess I didn't expect this behavior since GDB+openocd+other JTAG/SWD adapters will just slow your program by having to check for breakpoints after exhausting number of HW breakpoints, but it's implemented differently in GDB+openocd compared to Ozone/JLink libraries.

Though I have to ask, why does the reflash happen before disconnect as well? To restore the original program state?

Thought I caught it in action wihout exceeding the 4-6 HW breakpoints as shown here:



Thus after fimware reload, will somehow not correctly map the breakpoints (of which there were only 2), but starts using flash breakpoints.

Could we have a setting dialog like "do you want to reaload firmware now? yes,no,always, never." and make it "You are now setting flash breakpoints". ACK for future/ ask every time, do not, never". Last part is important. since it means that "yes keep resolved adresses as they were, but don't add any flash breakpoints.

Flash breakpoints are important if your firmware checks and hashes/verifies signatures of your code, which we do for Trezor T for example. It's because the code won't if the overall hash doesn't matchk, so you can't simply change assembly instructions.

Thus the flashpoint adding should have similar dialog "We are going to change instructions here, here and here". Do you acccept "Yes/No/Always/Never"

And ideally option to turn off flash points for a project at all in settings.