Interrupts on Cortex M - NVIC (demonstrated on STM32) | VIDEO 34 

I agree with you, thank you for pointing it out.

@ keep them coming I'm viewing your videos because I was laid off and need to brush up my concepts :D

The gpu while recording was not in idle because usual idle power draw is 40W and 38C, but here it was almost 90W, so maybe 58C is not that off. Plus I only have one back fan for my case(old workstation). Now I use fedora for work related reasons. Drivers should be more up to date and stable.

@ Ah, it's a desktop? The problem afaik is only present on laptops with two gpus (ie. intel + nvidia).

That's true. The stack would be used in case of larger arguments or in case you pass a lot. I guess the explanation was a bit simplified and in a way inspired by academic explanations.

Thank you. I have other topics in line that would go well with peripheral topics more. I'll keep it in mind.

Yes. In the use case for the demo, an interrupt for SPI should not block for that long and since the peripherals used inside of the ISR are not used anywhere else in the code, there should be no problem with race register access. It's an isolated case, but not a rare one. I've had a system designed without an RTOS and we used RTC ISR to trigger "precisely" spaced interrupts for sampling SPI ADCs for example. As my work colleague would say: "If you don't measure it, don't poke it". In that case, SPI is quite fast (10Mhz) and it only transfers 16 bits from each sensor, so the whole ISR was quite short and plenty fast for the sampling rate. Context matters and can ease the design.

First just declare the interrupt function fron hal empty. It should work as that. Then try adding back your code and find out where it gets stuck. Also make sure that your priorities are configured. In CubeMX NVIC panel make sure that your interrupt is enabled

Let me summarize your problem so that I can confirm if I understand it correctly. You have a signal, like an external digital signal, that triggers an interrupt. That interrupt starts a signal generation, which happens in main. I assume that you have a variable for the communication between interrupt and main. Main program will wait a set delay amount before signal is generated. In case, another interrupt arrives, which would create another request to start a signal generation from main, you are worried, that it might be corrupted? I think I understand your situation or at least I have a few similar scenarios in my head similar to your problem. Can you confirm that? If so, one answer is that you need to specify the behaviour of the signal generation trigger. You can use another variable, which is written to by main and read by interrupt, which specifies if the main loop is still processing/generating signal. If that's the case, interrupt service routine should just exit, thus ignore the trigger signal. You can also use the trigger variable as a busy signal. If not set, ISR will set it, maybe do something else. When main reads it, it starts signal generation. If the ISR implementation is so simple, it can just keep setting the trigger signal "to 1" and main won't do anything, since it's still processing the first signal generation. When main is done, it can set the shared signal variable "to 0". In the case, that you DO do something in the ISR, such as start a timer or any other peripheral, I would strongly suggest adding more status and/or synchronization mechanism either to the interrupt or the main, depending where the most time consuming part is beeing held, like the delay. You can also implement delay as a "state" in the signal generation state machine. With frequent polling you can check the state of the machine.

@ I really appreciate your help, thank you! I'm not sure if I explained the problem as I should. I have a signal (S1) which is coming from an external hall sensor and has the form of a square signal with a frequency of max. 25 Hz. I want to detect the falling edges of this signal a send out another signal (S2) through a DO after a specific delay after every falling edge. So the square signal simply triggers the signal I want to send out. The delay value is going to adjusted through a Potentiometer. The code that specifies the form of S2 is written in the main program. Everything works perfect besides when sending out S2 by the main interferes with a new falling edge of S1 which is detected by the ISR. When this happens the S2 starts behaving like it's triggered by the falling edge anymore. The Problem is that I'm not allowed to ignore any of the falling edges. So if put a variable that checks if the main is still sending out S2 and just exit the ISR when it's the case I assure that new falling edge will be "ignored".

@@ezz6928 I understand your issue more clearly now. You have an external signal (S1) triggering an interrupt to generate another signal (S2) with a specific delay, and you can't ignore any of the falling edges of S1. When the main program generates S2, it interferes with a new falling edge of S1, causing unexpected behavior in S2. To address this issue, you can implement a more robust synchronization mechanism between the main program and the interrupt service routine (ISR). Here's a possible approach: Shared Variable: Create a shared variable, let's call it s2GenerationInProgress, which will be used to indicate whether the main program is currently generating S2. Main Program: Before starting the S2 generation process, check the s2GenerationInProgress variable. If it's set (meaning S2 generation is in progress), wait until it's cleared before proceeding. Once it's cleared, set s2GenerationInProgress to indicate that the main program is now generating S2. Generate S2 as planned. ISR: When the falling edge of S1 is detected, check the s2GenerationInProgress variable. If it's set (meaning S2 generation is in progress), just exit the ISR without generating S2 again. If it's not set, proceed with S2 generation and set s2GenerationInProgress to indicate that S2 generation is in progress. Completion of S2 Generation: After the main program completes S2 generation, it should clear the s2GenerationInProgress variable to signal that it's done. This approach ensures that the main program and ISR are properly synchronized, and the falling edges of S1 won't interfere with the S2 generation process. If a falling edge of S1 occurs while S2 generation is in progress, the ISR will simply exit without generating another S2. By implementing this synchronization mechanism, you can maintain the integrity of your signal generation process without ignoring any falling edges of S1. -chatgtp

That's the way the script for the video was written, as intended.

Toooooo short attention span !!!!!!!!!!

@ excellent video, thank you Matej 🙏