Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running deterministic from Flash #1

Open
Traumflug opened this issue Dec 28, 2016 · 1 comment
Open

Running deterministic from Flash #1

Traumflug opened this issue Dec 28, 2016 · 1 comment

Comments

@Traumflug
Copy link

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

@xobs
Copy link
Owner

xobs commented May 31, 2017

Hi! Thank you for your comment.

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.

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

No branches or pull requests

2 participants