I have a general question about overrunning the fast thread, and potential problems that could result from this. I am asking this because I had 2 PRINTFs in some untested code that printed when the 400V incoming was shut off. This occurred while I was regulated 0 position. I am using UART1, and it looks like the PRINTF function uses the UART_WriteBlockTransfer() function. Therefore at 115200k my 2 PRINTFs would have took around 6ms to print to the console. My fast thread was running at 250us so I overran it by quite a bit.
3 times I ended up causing a DESAT on my IGBTs because of this. I have now removed the PRINTFs, but am trying to identify if this was the root cause of the problem.
I see that on initialization the current, speed, feedback, and encoder blocks all have time constants pulled from the system.h file. Therefore, when the fast thread was overran, all of the next calculations for these blocks would have been off? Could this in turn cause one of the phases to latch at a constant voltage or 100% PWM. This is what I am seeing my system do with the PRINTFs when 400V incoming AC is shut off. I do not see this with the PRINTF removed:
Blue = Differential Probe Between Phase A->B
Yellow = Incoming 400V AC
Purple = Differential Probe Between Phase B->C
Overrunning the fast isr is acceptable within reason. Provided that the overall average of isrs are called at the configured rate.
Printf on the KV31 is a blocking function. This means it waits until the transfer is complete before returning. For those 6ms the processor was only executing the printf function and the pwms were running with whatever the last duty cycle was. It absolutely caused the issue you described. As for the why it caused this issue, it is because you placed blocking functions into the isr.
I cannot advise you strongly enough to NOT put blocking functions in an isr. For real-time control applications you shouldn't be using blocking functions at all. If you need to transfer data out via a serial port, a better way to do this would be to use a buffer and an isr associated with uart1 in order to transfer out your data. Else I think Xiangjun's suggestion to use gpio was the right one.
Thanks for the reply. This PRINTF slipped in in some untested code. I actually did not need it in the code. I thought this issue had been the caused by the PRINTF. I have not been able to reproduce it without the PRINTF. I just wanted to be sure that overruning the PWM ISR with a blocking function could cause this issue. As far as I can tell it looks like the PRINTF caused this issue and I did a global search for PRINTFs and do not find anymore within any ISR calls. I searched for other blocking functions and did not find them in within the ISRs either.
Thanks for the help Adam and Xiangjun!
Thanks for the reply Xiangjun. I don't want to transfer a string in the PWM ISR, I have removed this PRINTF in the ISR.
I was more so wondering if the Feedback, Current, Encoder and Speed Block calculations which seem to have time constants pulled from the system.h file would be incorrect, and could they possibly over-correct for this calculation and possibly cause a sustained voltage to be output of the PWM controller?
I believe the PRINTF caused this, I am just trying to figure out why it caused this.
I suppose that the fast thread is an interrupt service routine of PWM, which must be serviced at fixed 250uS cycle, BTW, the UART module also uses interrupt to transfer string. If you want to transfer string in the fast thread(PWM ISR), the Kinetitis processor may be overloaded, if the Kinetis processor is overloaded, the PWM ISR can not be serviced as expected, if you change the duty cycle in the PWM ISR, the PWM duty cycle may not change because the PWM ISR is not serviced.
I do not suggest you print anyting in the ISR of PWM, you can toggle a GPIO so that you can know if the PWM ISR is serviced or not.
Hope it can help you