I really hope that race conditions scared the hell out of you! The greatest minds in computer science, such as Edsger Dijkstra, recognized very early on how dangerous race conditions can be. Unfortunately, many software developers vastly underestimate the problem and the true costs of preemption. In the later lessons of this course you will see methods to prevent race conditions upfront, *by design*, as opposed to removing them retroactively by applying mutual exclusion. Specifically, you might want to watch lessons 33 and 34 about "event-driven programming" for embedded systems. --MMS
Wow, very informative demonstration of how race conditions can arise when using the DATA register (with its necessary read-modify-write sequence) and how the DATA_Bits register eliminates this risk (with its atomic writes). Thank you again!
I knew how race conditions occur but looking at disassembly view gave a better perspective.. Sometimes its really hard to spot them or predict that the code will lead to race condition.. Cant really use locks and semaphore everywhere , so looking at disassembly is really a good idea..
That's precisely why I step down to the disassembly level. But the real lesson from this video should be to avoid *sharing* because sharing is at the root of all evil. And actually, the pure race conditions as shown here are just the tip of the iceberg. Even more common are various data races, where some complex data gets changed while preemption happens. After the preemption, the data is partially old and partially new (it's corrupted). Again, without sharing such a frequent problem wouldn't happen. --MMS
Quantum Leaps, LLC Thank you for your Tutorials. I am really looking forward to see the RTOS tutorials. Do you know already when you are going to upload the new Tutorials?
Is there any literature on this topic? Race conditions on bare metal microcontroller project, or how to design bare metal software to avoid them. Thank you
Yes, absolutely, there are many different approaches in hardware to alleviate the chance of race conditions. The Tiva GPIO is just one example, but there are others. In fact, the ARM Cortex-M core offers the unique feature called "bit-banding", which allows you to access each individual bit *atomically*. You might learn more about this feature by searching the web for the term "bit-banding".
very well explained..first strategy of mutual exclusion must be used with caution especially while using an RTOS, it should be made sure that the execution time of the critical section is less than the system tick. Another strategy would be, to use semaphores (binary in this case).
I just finished all these lessons. Will you be making lesson 21, 22 and so on or is this it for ARM. Good job on the lessons, they were pact with detail in every sentence you said. Can I apply all this if I was to move to the MSP430 launchpad. Yea probably the instruction set is different than arm but this approach you took with arm,.. can it also be applied with MSP430 or is that completely different. Thanks.
The general approach to look at the disassembly and understanding what the code is doing is applicable to any CPU. The details of instruction set and registers will be obviously different, but you should be much better prepared to work it out on your own. In fact, MSP430 is a much simpler machine than ARM and the MSP430 LaunchPad was used in this course in (lesson11 and lesson17).
HI Miro at the conclusion of this lesson you intended on discussing prioritizing interrups and other ways to disable interrups but your long absence shifted your focus. Can you direct me to text books that can be used along with your lessons please?
Yes, the subject of interrupt prioritization in ARM Cortex-M deserves more attention. Some of this will be discussed in the upcoming lesson 27 (RTOS part-6). For now, I recommend my ARM Community blog post community.arm.com/iot/embedded/b/embedded-blog/posts/cutting-through-the-confusion-with-arm-cortex-m-interrupt-priorities . --MMS
This is very interesting, but I have one question (perhaps dumb): in the while(1) loop in main, you are turning the green led on and then on the next line, turning it off. What is it that paces the loop - ie, why isn't the green led toggling so fast you can't see it? What am I missing?
You are right that in this particular example, the wile(1) loop in main() is apparently not delayed between turning the LED on and off. This means that the "blinks" of the LED occur many thousands of times per second and are perceivable to the human eye as a constant glow of the LED. I decided to remove the usual delay (used in all previous lessons) to increase the chance of a race condition, which is the main subject of this lesson. I hope this makes sense to you. --MMS
You still have a bug in the final code - you should put both lines withing CS as opposed each line separately! As the same race condition can still happen if right after enable inbetween the interrupt occurs!
I had a few questions regarding the race conditions, I understand why they are bad and how they can modify the shared the resources unexpectedly. I don't understand, why isn't the compiler/assembler smart enough to place a "push to stack" instruction after the interrupt is called and a "pop from stack" instruction before the interrupt service routine exits. I remember hearing this in previous videos, that the ARM CPU automatically places the PC, LR, R0 - R4, xPSR and some other registers to stack whenever an interrupt is triggered. (I also remember that the FPU can increase this context switch overhead by a huge extent). I don't understand why isn't the MCU automatically performing this operation, and if the compiler/assembler is aware of this, then why cannot it use a PUSH and POP instruction in the ISR?.
This is the whole point. The compiler *is* already saving and restoring all clobbered registers in the ISRs! But this is *not* enough. The compiler simply *cannot* prevent race conditions by itself. You have to additionally use mutual-exclusion mechanisms explained in this video. --MMS
Yes, bit-banding will cure this particular problem (it has been invented precisely for this purpose). Also, using the clever TivaC GPIO design (which I explained in lesson #7 ua-cam.com/video/pQs8vp7JOSk/v-deo.html ) will cure this particular problem. Both solutions work on the same principle of eliminating the *sharing* of the GPIO bits. But I intentionally used the shared version of the GPIO interface to make a larger point: sharing resources among concurrent code is *dangerous* . I hope you don't miss that important message. --MMS
I know the whole time we were using GCC for the projects. The tiva c examples are all done in a different compiler. If i wanted to use the LCD booster pack they have i would just get the graphics standalone library for the boosterpack LCD which should work in any of the compilers.. right.. and then just take the example they have written with their ti library and change the references from the GPIO perihperal library they used to how you did all the gpio setup in this course... right?
Miro - did lesson 21 recently go offline? "Lesson 21: Foreground Background Systems" Perhaps to make some updates based on newer tools? (I can delete this comment later)
No, lesson #21 is still in the works. The stuff at state-machine.com/quickstart is just a skeleton of the lesson (please disregard for now). This is there, so that I can show in the video how to download the projects and the QP/C framework, which will be needed for the next group of lessons. Hope this makes sense. --MMS
OK - thanks for responding. That makes perfect sense. Let me know if you want me to delete this comment. Perhaps somebody else will wonder about it too though.
one confusion: in example load -> modify -> store .... you made interrupt of systick. then all data of R0 to R3 and PC, LR should saved onto Stack, and after returning old stack should be retrieved. but instead you shown example of race condition where R2 used value which it saved from interrupt routine? ............................... in this case where stack gone ? why it did not store value to stack and get it back ?
The stack operations are fine. All registers are saved and then restored correctly. This is NOT the problem. The problem is that data in memory has been copied to registers and that these two copies diverged. Specifically, the SysTick interrupt was triggered after loading the registers from memory but before storing the changed values from registers to memory. Then the interrupt changed the data in memory, but the registers restored from the stack were still holding the old data. This is a rather fundamental problem. The hardware, the stack, the CPU all work correctly and as designed. The issue is that the operations are not atomic with respect to interrupts. --MMS
Doesn't volatile keyword also help prevent data races to some extent. Let's say a global flag variable ledState is shared between main function and ISR. If I understand correctly, declaring ledState as volatile would force the processor to get it's value from RAM everytime it's accessed and not use the cached value in register.
No, the 'volatile' keyword alone does NOT prevent race conditions, so please don't think that you are off the hook just because you declared a variable 'volatile'. Every variable shared between any concurrent contexts (e.g., ISR and the background loop, or between two ISRs at different priority levels) must be protected by a mutual exclusion mechanism, such as critical section. Please also watch lesson 28 (ua-cam.com/video/kcpVI3IjUUM/v-deo.html ), which expands on the problems caused by sharing resources and mutual exclusion mechanisms in the context of an RTOS. --MMS
Isn't the GPIO_ABH->DATA register declared volatile? Why then does the main code not read the updated value of the register before modifying it? What's the use of volatile keyword if this does not work then?
Hi Apoorva. The "volatile" keyword does NOT protect against race conditions. Here is a good article explaining the real role of "volatile": www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html
I'm sorry for the silence, but new lessons are coming (!) By popular demand, I will be talking about RTOS, concurrency and embedded software architecture. --MMS
Hi miro , can ı use STM32 F0912 NUCLEO in this course? (i saw you said we can use nucle c031c6 in course but i just gonna barrow it F0 from my friend) , best regards.
It does NOT seem possible to use any other STM32 NUCELO than the one explicitly supported. I just tried to plug in STM32 NUCLEO-F0912 and naively load to it project for the C031C6. The uVision debugger reports "Error while accessing a target resource". --MMS
Your videos are awesome! I have the MSP432 (red) launchpad which I have been trying to use to follow your videos with limited luck. I am struggling a bit with registry differences at the moment. www.ti.com/tool/msp-exp432p401r Can your startup files in Lesson 19/20 be converted without to much effort from the TIVA to the MSP432? I would like to use them as a starting point to learn CCS7. DB
I'm really afraid of race condition bugs
I really hope that race conditions scared the hell out of you! The greatest minds in computer science, such as Edsger Dijkstra, recognized very early on how dangerous race conditions can be. Unfortunately, many software developers vastly underestimate the problem and the true costs of preemption. In the later lessons of this course you will see methods to prevent race conditions upfront, *by design*, as opposed to removing them retroactively by applying mutual exclusion. Specifically, you might want to watch lessons 33 and 34 about "event-driven programming" for embedded systems. --MMS
Dr Samek, we are so excited to see you BACK on youtube!!!! Thank You for your time explaining such a complex art.
This is such a beautiful explanation! The shared resource and separate gpio bit thing makes a lot more sense now :)
Thank you so much for this video, it is the greatest lesson in ARM in the whole UA-cam.
These tutorials are a GEM. God bless you Sir.
Wow, very informative demonstration of how race conditions can arise when using the DATA register (with its necessary read-modify-write sequence) and how the DATA_Bits register eliminates this risk (with its atomic writes). Thank you again!
Hi Miro, very eagerly waiting for your next lesson...
can't wait for the next videos. Thank you !!
I knew how race conditions occur but looking at disassembly view gave a better perspective..
Sometimes its really hard to spot them or predict that the code will lead to race condition..
Cant really use locks and semaphore everywhere , so looking at disassembly is really a good idea..
That's precisely why I step down to the disassembly level. But the real lesson from this video should be to avoid *sharing* because sharing is at the root of all evil. And actually, the pure race conditions as shown here are just the tip of the iceberg. Even more common are various data races, where some complex data gets changed while preemption happens. After the preemption, the data is partially old and partially new (it's corrupted). Again, without sharing such a frequent problem wouldn't happen. --MMS
Quantum Leaps, LLC Thank you for your Tutorials. I am really looking forward to see the RTOS tutorials. Do you know already when you are going to upload the new Tutorials?
any chance for next lessons any time soon? Perhaps covering peripherials (uart, spi, timers etc)...?
Amazing video ! Thank you
Great series!!. Thanks for the effort.
Excellent Thank you very much Samek
excellent video! love your series!
Is there any literature on this topic? Race conditions on bare metal microcontroller project, or how to design bare metal software to avoid them. Thank you
waiting for more videos about ARM, what do u think bout Keil ?
Some processors offer set and reset registers to provide atomic gpio output modification.
Yes, absolutely, there are many different approaches in hardware to alleviate the chance of race conditions. The Tiva GPIO is just one example, but there are others. In fact, the ARM Cortex-M core offers the unique feature called "bit-banding", which allows you to access each individual bit *atomically*. You might learn more about this feature by searching the web for the term "bit-banding".
can you please make video about DMA ?
very well explained..first strategy of mutual exclusion must be used with caution especially while using an RTOS, it should be made sure that the execution time of the critical section is less than the system tick. Another strategy would be, to use semaphores (binary in this case).
I just finished all these lessons. Will you be making lesson 21, 22 and so on or is this it for ARM. Good job on the lessons, they were pact with detail in every sentence you said.
Can I apply all this if I was to move to the MSP430 launchpad. Yea probably the instruction set is different than arm but this approach you took with arm,.. can it also be applied with MSP430 or is that completely different. Thanks.
The general approach to look at the disassembly and understanding what the code is doing is applicable to any CPU. The details of instruction set and registers will be obviously different, but you should be much better prepared to work it out on your own. In fact, MSP430 is a much simpler machine than ARM and the MSP430 LaunchPad was used in this course in (lesson11 and lesson17).
Thanks a lot. I will get started with MSP430 as soon as I play around more with what you have taught me. Your knowledge is golden.
HI Miro at the conclusion of this lesson you intended on discussing prioritizing interrups and other ways to disable interrups but your long absence shifted your focus. Can you direct me to text books that can be used along with your lessons please?
Yes, the subject of interrupt prioritization in ARM Cortex-M deserves more attention. Some of this will be discussed in the upcoming lesson 27 (RTOS part-6). For now, I recommend my ARM Community blog post community.arm.com/iot/embedded/b/embedded-blog/posts/cutting-through-the-confusion-with-arm-cortex-m-interrupt-priorities . --MMS
very informative..
This is very interesting, but I have one question (perhaps dumb): in the while(1) loop in main, you are turning the green led on and then on the next line, turning it off. What is it that paces the loop - ie, why isn't the green led toggling so fast you can't see it? What am I missing?
You are right that in this particular example, the wile(1) loop in main() is apparently not delayed between turning the LED on and off. This means that the "blinks" of the LED occur many thousands of times per second and are perceivable to the human eye as a constant glow of the LED. I decided to remove the usual delay (used in all previous lessons) to increase the chance of a race condition, which is the main subject of this lesson. I hope this makes sense to you. --MMS
You still have a bug in the final code - you should put both lines withing CS as opposed each line separately! As the same race condition can still happen if right after enable inbetween the interrupt occurs!
Ho so? Please explain.
I had a few questions regarding the race conditions, I understand why they are bad and how they can modify the shared the resources unexpectedly. I don't understand, why isn't the compiler/assembler smart enough to place a "push to stack" instruction after the interrupt is called and a "pop from stack" instruction before the interrupt service routine exits. I remember hearing this in previous videos, that the ARM CPU automatically places the PC, LR, R0 - R4, xPSR and some other registers to stack whenever an interrupt is triggered. (I also remember that the FPU can increase this context switch overhead by a huge extent). I don't understand why isn't the MCU automatically performing this operation, and if the compiler/assembler is aware of this, then why cannot it use a PUSH and POP instruction in the ISR?.
This is the whole point. The compiler *is* already saving and restoring all clobbered registers in the ISRs! But this is *not* enough. The compiler simply *cannot* prevent race conditions by itself. You have to additionally use mutual-exclusion mechanisms explained in this video. --MMS
Bit-banding wouldn't eliminate this problem?
Yes, bit-banding will cure this particular problem (it has been invented precisely for this purpose). Also, using the clever TivaC GPIO design (which I explained in lesson #7 ua-cam.com/video/pQs8vp7JOSk/v-deo.html ) will cure this particular problem. Both solutions work on the same principle of eliminating the *sharing* of the GPIO bits. But I intentionally used the shared version of the GPIO interface to make a larger point: sharing resources among concurrent code is *dangerous* . I hope you don't miss that important message. --MMS
I know the whole time we were using GCC for the projects. The tiva c examples are all done in a different compiler. If i wanted to use the LCD booster pack they have i would just get the graphics standalone library for the boosterpack LCD which should work in any of the compilers.. right.. and then just take the example they have written with their ti library and change the references from the GPIO perihperal library they used to how you did all the gpio setup in this course... right?
very good vedio,thx!
Miro - did lesson 21 recently go offline? "Lesson 21: Foreground Background Systems" Perhaps to make some updates based on newer tools? (I can delete this comment later)
No, lesson #21 is still in the works. The stuff at state-machine.com/quickstart is just a skeleton of the lesson (please disregard for now). This is there, so that I can show in the video how to download the projects and the QP/C framework, which will be needed for the next group of lessons. Hope this makes sense. --MMS
OK - thanks for responding. That makes perfect sense. Let me know if you want me to delete this comment. Perhaps somebody else will wonder about it too though.
one confusion: in example load -> modify -> store .... you made interrupt of systick. then all data of R0 to R3 and PC, LR should saved onto Stack, and after returning old stack should be retrieved. but instead you shown example of race condition where R2 used value which it saved from interrupt routine? ............................... in this case where stack gone ? why it did not store value to stack and get it back ?
The stack operations are fine. All registers are saved and then restored correctly. This is NOT the problem. The problem is that data in memory has been copied to registers and that these two copies diverged. Specifically, the SysTick interrupt was triggered after loading the registers from memory but before storing the changed values from registers to memory. Then the interrupt changed the data in memory, but the registers restored from the stack were still holding the old data. This is a rather fundamental problem. The hardware, the stack, the CPU all work correctly and as designed. The issue is that the operations are not atomic with respect to interrupts.
--MMS
Excellent course, please please do not add music.
Doesn't volatile keyword also help prevent data races to some extent. Let's say a global flag variable ledState is shared between main function and ISR. If I understand correctly, declaring ledState as volatile would force the processor to get it's value from RAM everytime it's accessed and not use the cached value in register.
No, the 'volatile' keyword alone does NOT prevent race conditions, so please don't think that you are off the hook just because you declared a variable 'volatile'. Every variable shared between any concurrent contexts (e.g., ISR and the background loop, or between two ISRs at different priority levels) must be protected by a mutual exclusion mechanism, such as critical section. Please also watch lesson 28 (ua-cam.com/video/kcpVI3IjUUM/v-deo.html ), which expands on the problems caused by sharing resources and mutual exclusion mechanisms in the context of an RTOS. --MMS
Isn't the GPIO_ABH->DATA register declared volatile? Why then does the main code not read the updated value of the register before modifying it? What's the use of volatile keyword if this does not work then?
Hi Apoorva. The "volatile" keyword does NOT protect against race conditions. Here is a good article explaining the real role of "volatile": www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html
Lesson 21 please
I'm sorry for the silence, but new lessons are coming (!) By popular demand, I will be talking about RTOS, concurrency and embedded software architecture.
--MMS
With the background music, it is hard to concentrate
Miro, Next lesson please ..
The next lesson is forthcoming. Stay tuned...
--MMS
Hi miro , can ı use STM32 F0912 NUCLEO in this course? (i saw you said we can use nucle c031c6 in course but i just gonna barrow it F0 from my friend) , best regards.
It does NOT seem possible to use any other STM32 NUCELO than the one explicitly supported. I just tried to plug in STM32 NUCLEO-F0912 and naively load to it project for the C031C6. The uVision debugger reports "Error while accessing a target resource". --MMS
@@StateMachineCOM thank you for return
Excellent video but exceptionally irritating background music. Who studies with music?
Please remove music
Great Video. But can you please switch off that background music please?
Your videos are awesome!
I have the MSP432 (red) launchpad which I have been trying to use to follow your videos with limited luck. I am struggling a bit with registry differences at the moment.
www.ti.com/tool/msp-exp432p401r
Can your startup files in Lesson 19/20 be converted without to much effort from the TIVA to the MSP432? I would like to use them as a starting point to learn CCS7.
DB
all very nice but annoying music in the background .....
Read-modify-write ARM = non-ATOMIC.