Reading TIMx->DMAR from unrelated (channel/stream) DMA request

[tho]

Hello,

I was looking for datasheets or specs or any other information from knowledgable people about reading a timer's DMAR register from a DMA request triggered by *another* timer. I was wondering how much reliable this design is, and if I should think about possible unwanted side effects. This is with a STM32F767, but I guess all the F series would share more or less the same design.

Here is a summary of my sofware design:

* TIM3->CH{1,2,3,4} input capture mode, 'free running' (TIM3->ARR = 0xffff to avoid wrapping), capturing both edges of 4 unrelated signals. The idea is to reliably 'timestamp' the edges of the input to later decode the signal etc.

* TIM8 periodic update (e.g. 1MHz) triggering appropriate DMA2 stream/channel on update.

* DMA2 configured as Periph->Mem, imporant detail is PBURST=INCR4, reading four times through TIM3->DMAR. TIM3->DCR configured with DBL=3 (4 transfers), DBA reading through TIM3->CCR{1,2,3,4}.

I came up with this design to avoid TIM3 wrapping and getting ambigous capture events (I cannot use DMA TIM3_CHx events because of the lack of available DMA channels on this particular hardware, so I must use either TIM3_UP for the 4 channels or a DMA2 channel, hence TIM8).

This works well. The only issue is that the TIM8 DMA request is triggered only once when reading TIM3->DMAR (thus not recognized as a burst by TIM3 nor TIM8). So I configured PBURST=INCR4 that makes the magic work in combination with TIM3->DBL=3, that cycles well through the 4 tranfers.

[Luckily I need exactly a INCR4. I also though of running TIM8 4 times faster and thus triggering 4 more transfers without PBURST.]

I also noticed that 'regular' reads (from code) through TIM3->DMAR happens to work too, i.e. each read cycles through the next address and proprely wraps after the 4 tranfers. What is a bit confusing in RM0410 about DMAR is that it's only mentionned about 'dma'.

My question is basically "how much is mixing DMA requests from one TIM event to DMAR of another TIM specified by the STM32 design" ...

Cheers,

[waclawek.jan]

The DMAR/DCR mechanism has two aspects:

• each access (being it read or write) to TIM registers through TIMx_DMAR advances the internal "pointer" through which the individual registers are accessed, with wraparound determined by DCR
• each access except the wraparound sets a DMA request (to ensure the "burst"; my experiments appear to indicate that it sets DMA request on *all* currently enabled requests from given timer)

In your case, you are using only the first mechanism, and that's apparently OK.

The second mechanism won't engage as long as you don't use any DMA request from that given timer.

JW

PS. Note that the first point applies to accesses from debugger, too.

[tho]

Thanks for the reply (I tried to reply be e-mail but that does not seem to work).

So, if I understand correctly, my approach would break if I would also need DMA requests from TIM3, as they would be triggered by the simple fact of reading TIM3_DMAR from TIM8-triggered DMA request. Fortunately I don't need any DMA request from TIM3 for that application.

But bascially, what you seem to imply is that when reading/writing TIMx_DMAR, for any 'xDE' enabled bit in TIMx_DIER a DMA request is sent. Is that correct? Does that mean that if e.g. TIMx_CC1DE and TIMx_CC2DE are enabled and only one of the DMA streams reads DMAR, the other stream would be 'bursted' as well?

Are you by chance aware of any technical document that is more precise or detailed than the RM0410 about these aspects?

For instance with functional diagrams that would detail who is responsible for what.

[waclawek.jan]

> I tried to reply be e-mail

Try harder :)

> Are you by chance aware of any technical document that is more precise or detailed than the RM0410 about these aspects?

No. Much of this is found out by experimentation and may be incorrect (I may have incorrectly interpreted my findings, I have no access to the internal design details). I know of no good description of the DMAR/DMC mechanism. From that the "IMO" below.

> if I would also need DMA requests from TIM3, as they would be triggered

IMO, yes.

> Does that mean that if e.g. TIMx_CC1DE and TIMx_CC2DE are enabled and only one of the DMA streams reads DMAR, the other stream would be 'bursted' as well?

An interesting idea to try, IMO the answer is yes.

JW