Using AtomicBool on Teensy 3.5 crashes

[nils-van-zuijlen]

Hello

I'm discovering embedded programming in Rust and I'm trying to follow Exploring Rust on Teensy | Walking through building a rust-based project on a Teensy. From project setup through building safe abstractions for the underlying hardware. tutorial to get it working on my Teensy 3.5.

I managed to get parts 1 and 2 of the tutorial working, but I see myself unable to use AtomicBools that are required in part 3 of the tutorial.

My code is hosted on github at GitHub - nils-van-zuijlen/teensy.rs

The code compiles, flashes correctly on the Teensy, but it does not light up the LED.

Thank you for any help

[Voultapher]

pjrc . com/teensy/ says it uses a Cortex-M4F

https://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARMv7-M_ARM.pdf is the architecture manual, the section on Memory Model Feature registers might be helpful.

Another thing you could try is to run a simple C program like this one Compiler Explorer and see if truly the atomics implementation either in Rust or hardware is faulty or something else is happening. Tipp also disassemble your actual produced binary, and see if the instructions show up as expected.

Something else I noticed taking a quick glace at the repo, is the use of Relaxed ordering, which more or less says, yeah reads and writes are visible at some point, might be 2 seconds from now, it hardly gives you any guarantees other than all your reads and writes will be visible at some point, no ordering guarantees whatsoever. An experienced developer I know once put it that way, if you open a PR with non sequentially consistent atomics in it, he'll demand a formal proof your algorithm is correct. While that might seem a little excessive, using non default memory orders correctly is ludicrous tricky, and many have tried at gotten it wrong. So maybe the synchronization hoped for by using atomics here is voided by the Relaxed memory order. Try SeqCst and see if that helps.

[nils-van-zuijlen]

@Voultapher

Another thing you could try is to run a simple C program like this one Compiler Explorer and see if truly the atomics implementation either in Rust or hardware is faulty or something else is happening.

I tried using Teensyduino atomic variables, and they work, so the problem is in my code, and I assume Branan had his Teensy working with the part 3 code.

@Voultapher

Tipp also disassemble your actual produced binary, and see if the instructions show up as expected.

Actually, I don't know what to expect, I never worked with Atomics in Assembly.

@Voultapher

Something else I noticed taking a quick glace at the repo, is the use of Relaxed ordering, which more or less says, yeah reads and writes are visible at some point, might be 2 seconds from now, it hardly gives you any guarantees other than all your reads and writes will be visible at some point, no ordering guarantees whatsoever.

I'm quite new to the ordering concepts, I used Relaxed because that's what is in the tutorial I followed, but I don't know what it means. I tried using SeqCst, but it's not the cause of the problem (or not the only one). Additionally, the current program only has a single path of execution, they will only be used if I add interrupts and such.

[bjorn3]

@nils-van-zuijlen

I'm quite new to the ordering concepts, I used Relaxed because that's what is in the tutorial I followed, but I don't know what it means.

In case of doubt always use SeqCst. All other memory orderings allow the compiler to reorder atomic operations of different locations across each other in some way or another. This can lead to quite unexpected results. You should only consider using memory orderings other than SeqCst if speed is an issue and you know how memory orderings work. Preferably also with a (semi)formal proof of the correctness of memory orderings other than SeqCst.

[Voultapher]

@nils-van-zuijlen

Actually, I don't know what to expect, I never worked with Atomics in Assembly.

One strategy you could try is to reduce your current program down to a minimal failure case. And then try to replicate that same logic in C and diff relevant assembly areas. Also I'd hope there is some mechanism for debugging crashing applications like yours that might give you more information about why it doesn't run and or crashes.