Too long delay time from HAL_DAC_Start() to wave output in STM32F429I

[diverger]

Posted on September 04, 2016 at 10:31

I'm trying output a sine wave on STM32F429I, the HCLK is 168MHz. I want my sine wave start just as I detect a rising edge on one GPIO. So, I use software trigger, call HAL_DAC_Start() in the ISR of a rising edge event (IRQ5_9). But when I probe it, I find the delay between the output and the rising edge sometimes is 5ms!!!!!!!! Is it normal? The delay is too long!

#dac #dac

[mark239955_stm1]

Posted on September 04, 2016 at 13:40

I'm guessing that this is a follow-up to [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/Using%20STM32F4%27s%20DAC%20with%20DMA&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=11]this thread?

I'm going to make the point that if you want firmware to do what you expect, rather than what someone else thinks is appropriate, you need to write it yourself.  In order to do that, you need to be willing to spend the time to learn how the peripherals work, instead of wasting your time trying to understand how ST's awful HAL works. Setting up a timer as a timebase for one or both DAC's, setting up the DAC's themselves, and setting up DMA to feed the DAC's really isn't that difficult using register hacking.  The reference manual even tells you exactly how to do it, if you look.  Once it's set up, there are several ways that you can start it running; the most intuitive is probably to have the DAC's and DMA already running, but the timer stopped so it's not generating TRGO events.  Then all you should need to do in the EXTI9 interrupt handler is start the timer (set the CEN flag in TIMx->CR1) and fire an update event (set the UG flag in TIMx->EGR).  The DAC will immediately begin synthesizing your sine wave.

[diverger]

Posted on September 04, 2016 at 14:19

Thanks for your suggestions.

But, I've tried your method, event tried more than you suggested. I've tried three methods:1>. Use a timer + DMA + DAC.2> Use a exti9 + DMA + DAC, exti9 as the trigger source of DAC3> Use software trigger + DACAll works well without synch to a edge event. The problem is if we put the start functions (start functions with or without _DMA suffix) in an ISR of edge event (exti6), the first DAC output sometimes delayed too long than the edge. We've made sure before the edge the DAC and DMA is not running, we have scope it, and if the DAC running before the edge, we can probe it!!! I don't think it's the problem of the HAL library, but suspect it's the problem of DAC hardware. Maybe the first conversion is delayed after the DAC setup?My and my colleagues have spend 3 days on this. So, I want someone who have used STM32's DAC do something similar to me to give me some help.''The DAC will immediately begin synthesizing your sine wave.''  Can you make sure that? If you make sure that it will ''immediately'' begin after I enable it. We'll stick to our solutions and try harder to find the reason, otherwise we may give up the current solutions.

[mark239955_stm1]

Posted on September 04, 2016 at 15:15

It's the HAL.  The TIM-DMA-DAC combination works perfectly.  I've done this before, I think I've even posted responses here to other people's questions about how to do it.  You're on the right track with your first option (TIM-DMA-DAC), but you're trusting the HAL to perform when you need it to and that is a bad mistake because it is not written for performance.

When I say ''immediately'', I mean it.  If you leave the timer configured but disabled, then as soon as you enable it and set the UG flag the timer will generate it's TRGO signal, which causes the DAC to request the next value from the DMA.  It will be up and running in a few clock cycles - the single longest component of the wait is probably the interrupt latency for EXTI9.  Once the timer is started it will continue to generate TRGO signals and DAC updates at whatever frequency you have configured. Out of interest, what frequency are you running the timer at?

[Tesla DeLorean]

Posted on September 04, 2016 at 15:18

Me and my colleagues have spend 3 days on this. So, I want someone who have used STM32's DAC do something similar to me to give me some help. .. Can you make sure that?

Sounds expensive, I'm pretty confident that a DAC capable of MSps output isn't the cause of milli-seconds of delay. What's the hourly rate?

[diverger]

Posted on September 06, 2016 at 18:53

@Mark, thanks for your help.

I carefully reviewed my colleague's code, and finally find the reason. There is a error in the EXTI interrupt flag clearing function. That is before we enable the GPIO edge event IRQ, we actually didn't clear the old interrupt flags. So when we enable the IRQ, the 'fake' IRQs may come in!!!!!