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
Just saw your awesome talk on 33C3. There you claim running from Flash isn't clock cycle deterministic, because there's a prefetcher and one would never know when this kicks in.
When implementing an interruptible delay loop for Teacup Firmware I ran into a similar problem. Depending on where the compiler placed the code, the loop would take a longer or shorter execution time. The solution I found is to align code to a 16 byte boundary. This removes the prefetcher from the picture or at least makes it deterministic. Gcc/binutils even features an instruction to enforce such alignment, .balign.
My experiences with "non-deterministic flash" consisted of the MCU spending a variable number of cycles in the main loop -- anywhere from 24 to 28 cycles per loop. That is, I managed to eliminate four instructions, and it would work sometimes but not others.
I suspect it has to do with bit stuffing, where the codepath is not constant, and instead depends on the data streams.
Just saw your awesome talk on 33C3. There you claim running from Flash isn't clock cycle deterministic, because there's a prefetcher and one would never know when this kicks in.
When implementing an interruptible delay loop for Teacup Firmware I ran into a similar problem. Depending on where the compiler placed the code, the loop would take a longer or shorter execution time. The solution I found is to align code to a 16 byte boundary. This removes the prefetcher from the picture or at least makes it deterministic. Gcc/binutils even features an instruction to enforce such alignment, .balign.
The implementation taking advantage of .balign can be found here: https://github.com/Traumflug/Teacup_Firmware/blob/master/delay-arm.c
The text was updated successfully, but these errors were encountered: