Open chrissbarr opened 5 months ago
Wonderful work! I once tried to use a more updated CMSIS but it caused the bootloader to be bigger. When I increased the optimization, it behaved exactly as you described. Really good to know 👍
@Serasidis any suggestions?
In the F4 bootloader, I think the variable
new_data_is_received
should be marked as volatile.I noticed that if I change the optimisation level from
-Og
to-Os
or-O2
etc., the bootloader starts misbehaving for me. When the HID-Flash tool starts an upload, it freezes on the first. 1024 Bytes
message, like so:Connecting with a debugger, I can see that the code is stuck in the loop waiting for an incoming command to process. Despite
new_data_is_received
having been set to1
by the USB HIDCUSTOM_HID_OutEvent_FS
callback/ISR, the below loop inmain.c
appears to be optimised as ifnew_data_is_received
never changes (presumably because it is never changed anywhere inmain.c
).Marking
new_data_is_received
as volatile fixed this behaviour, and the bootloader started working for me at all optimisation levels.I believe this is a reasonable change.
new_data_is_received
is changed in an ISR, which seems reason enough to mark it volatile. Even if it wasn't an ISR, given the code that sets it is outside the scope ofmain.c
, and therefore not in the translation unit whenmain.c
is compiled, it should probably be marked volatile for that reason anyway.I am unsure if the same consideration should be extended to the other variables shared between main.c and the ISR, such as
USB_RX_Buffer
. Given that the buffer is read/written non-atomically, it's plausible the USB ISR could fire whileUSB_RX_Buffer
is mid-read bymain.c
and change the values. I think this would only happen if consecutive USB HID ISRs were received beforemain.c
could process the buffer (which seems unlikely / I haven't had it happen). It's more complicated thannew_data_is_received
, though, so I'm hesitant to suggest anything here.