ChibiOS Free Embedded RTOS

I'm using DMA to a DAC on an F07 MCU, which is working well, at least for a constant update interval. I want to use it for generating an AFSK signal, and I was hoping that I could change the frequency by simple updating the interval, but that doesn't seem to be working correctly.

In order to accomplish this, I'm simply calling gptChangeInterval at a fixed interval, currently just ping-ponging between two intervals and looking at the output on a scope. I first tried using a GPT + thread (signaled from the GPT) to change the interval, then, to simplify it, I just started calling gptChangeInterval from within a loop in the main thread. Both methods have the same effect.

What appears to be happening is when the interval is changed, the output either flatlines, or, I think it might actually still be changing, but at a much slower pace, so it looks pretty much like it's flatlining. It also appears to be "flatligning" across multiple interval changes, at least at higher rates of update. For example, if I'm updating at 1ms intervals, I see a bit of sine wave, then a "flatline" that's much longer in duration. If I slow it down to e.g. 1sec updates, it clearly changes frequency, but there are still "flatlines" in between.

Is what I'm trying to do reasonable? I could also skip DMA and use a GPT to output the entire signal manually, but that would be less efficient and more coding.

Is it possible, since I'm setting the interval to a smaller interval half of the time, the TIM couunter is already past that value and it ends up counting until the counter wraps around? That's the only theory that I can come up with.

Hi,

The interval is changed in next cycle, not the current one, could this be the problem?

This should also prevent the counter going past the comparator value.

Giovanni

By "cycle" I assume you mean that when it starts at the beginning of the buffer again? If that's true, then I don't think it will work for what I'm trying to do. I need it to take effect sometime around when the next sample would go out.

In any case, I don't think that's the problem. The "flat-lining" extends for much more than a single buffer.

You could use the SPI driver, put a pattern in memory then DMA it out using SPI.

Giovanni

I could also have two data buffers (one for each frequency) and do one-shot DMAs for just the duration that I need for outputting a single bit. The only problems are that I have to track the phase so I don't have phase discontinuity, and re-starting the DMA would have to be low enough latency (< 10uS or so) so there wouldn't be a gap in the signal.

After a bit more research and thinking about this, I'm not sure I fully understand your comment: "The interval is changed in next cycle, not the current one".

My understanding is that the GPT is just being used as a clock for the DAC DMA, so it knows nothing about the DMA buffer. So, the GPT "cycle" time is simply the interval * the base clock period, so if the GPT frequency is set to 1MHz (1uS period), and the interval is set to 4, then the GPT cycle time is 4uS. If I change the interval, then I would expect that change to take effect in <= 4uS, right?

If that's true, then I'm back to wondering why it's not working.

I wonder if I can just use a callback on the GPT and trigger the DAC from within that callback. Then I could change the interval in that callback, which might be safer.

Hi,

You should read the STM32 manual, the TIM chapter, the GPT driver uses the counter and the ARR comparator. Changes to the comparator happen when the counter is reloaded with zero on compare event.

Understanding the behavior of TIM HW would also explain what you are seeing.

Giovanni

I found the problem. It turns out that the ARPE flag is only set for TIMs used for PWM, so (as I suspected) the problem likely was that it was updating the AAR register with a value that was less than where the current counter was at, so it had to wrap the counter before it updated again.

I fixed it by adding STM32_TIM_CR1_ARPE to the initialization of the CR1 register in gpt_lld_start_timer. Is there a way to set that externally? If not, I think it should default with that flag set.

I would classify this as a bug, moving this topic in the appropriate forum.

Giovanni

Bump.