0
\$\begingroup\$

I have two related questions regarding using DMA with an STM32 chip. I'm using STM32F031C6, but the answer should apply to other models.

  1. I setup the USART to issue a character match interrupt. I'm using DMA to read the characters from the USART. I've noticed in practice that the matched character has already been copied to memory by the time the character match interrupt occurs. Is this behaviour something that is reliable or is it a potential race condition? I didn't see this addressed in the reference manual.

  2. I setup the A2D to read a sequence of channels and issue an end-of-sequence EOSEQ interrupt upon completion. I'm using DMA to read the values into memory. Is there any guarantee that the value will have already been copied to memory at the point the EOSEQ happens? I didn't see this addressed in the reference manual.

\$\endgroup\$
6
  • \$\begingroup\$ I could imagine the answer coming from interrupt priorities, but that depends on the inner workings of the UART and ADC peripherals -- They could for example, set the end-of-sequence/character-match flags and then later do the DMA, or it could all happen in one clock-cycle, or... \$\endgroup\$
    – Dan Sandberg
    Sep 11, 2020 at 10:17
  • \$\begingroup\$ 1.) Isn't that trivial? How could a device trigger an interrupt before (or while) receiving the character? 2) it's unclear to me what you are asking for, \$\endgroup\$
    – Marko Buršič
    Sep 11, 2020 at 10:18
  • \$\begingroup\$ The time when the interrupt is triggered is is different from the time your interrupt handler code starts executing. If no other interrupts are involved, it is about 15 clock cycle apart. By that time, the data has certainly been written to memory. What is your specific issue anyway? Why is this relevant? \$\endgroup\$
    – Codo
    Sep 11, 2020 at 10:39
  • \$\begingroup\$ @MarkoBuršič The issue is that there's two different interrupts at work -- one comes from DMA (transmission complete) and the other comes from the UART or ADC. The issue is the sequencing of these interrupts. \$\endgroup\$
    – Dan Sandberg
    Sep 12, 2020 at 19:40
  • \$\begingroup\$ @Codo Yes, good point about the 15 clock cycle interrupt latency. But I don't know how long a DMA takes -- how is it guaranteed it would happen in 15 cycles? Is this assuming there is no bus contention? \$\endgroup\$
    – Dan Sandberg
    Sep 12, 2020 at 19:41

1 Answer 1

Reset to default
0
\$\begingroup\$

There is no enforcing mechanism to ensure it on the hardware level. These devices you use don't have DMA FIFOs, so the latency between the interrupt occurance and actual code test point will keep the working stable. But when working with FIFO or just to conceptually ensure it, this is the duty of the software, by examining or activating some triggers on the DMA registers.

\$\endgroup\$
2
  • \$\begingroup\$ Not sure I understand -- how does the interrupt latency ensure the DMA will be finished in time? Do I understand right that you're saying that if I wanted to ensure it I could check the DMA "transfers remaining" register? \$\endgroup\$
    – Dan Sandberg
    Sep 12, 2020 at 19:44
  • \$\begingroup\$ It doesn't ensure. As there is no FIFO on your device, it is just 1 memory operation need to be handled concurrent with the interrupt occurance. There are tens of cycles between occurance and routine entry, probably much more until the test point. So, pratically expected to work. To ensure it, you may check the transfers remaining register, or something like transfer end flag. @DanSandberg \$\endgroup\$
    – Ayhan
    Sep 13, 2020 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.