STM32F429 Timer triggered USART DMA transfer issue.

[kostix]

Hello! 

This is my first post at this forum.
I am developing a MIDI sequencer device based on a STM32F429DISCOVERY board running at stock 180MHz. In order to send midi messages the USART1 is configured for 31250 bauds and the appropriate DMA is configured to transfer a 3 byte array stored in ram to the USART. I was doing tests of even timing of sending of midi messages, by configuring the Timer 4 update interrupt, within the service routine of which I am enabling the memory-to-peripheralUSART1 DMA operation. This gives me a periodic sending of a 3 byte message over the USART1 peripheral. 

Everything works great and with correct frequency and correct data, but i have a small issue which i have been researching for few days now and have not been able to correct. To make things clearer, within the timer interrupt routine I set a led on the discovery (RG13) to momentarily blink and connected 1 channel of an oscilloscope to the led pin. The second channel of the oscilloscope is connected to the USART TX pin. Now, when the code is executed, i can see the led pulse on the oscilloscope's CH1,  followed by the USART serial data on the CH2. But for some reason the time between the led pulse and the beginning of the serial data transfer fluctuates with every sending of the data. It increments with every sending, going from around 1uS to around 30uS, and then jumps back to 1.
I noticed that if i slightly change the USART baudrate, the time fluctuation between the pulse and the data sending changes in pattern, going faster or slower and with longer or shorter range.
I have tried resetting all the apropriate flags from USART as well as DMA, have tried to disable/enable the timer, played with interrupt priorities, but nothing has worked to get rid of the time fluctuation.
As you can imagine, the stability of this is crucial for a MIDI sequencer hardware application as it bases the timing of the musical events, which must be rock solid.
I have also tried using the USART by itself without DMA, manually sending every byte,  basically same results. Interrupt driven USART TX exhibited likewise results.
The only thing which seemed to work to get rid of the time fluctuation of USART TX response is, before every sending operation to deinitialize USART and the DMA modules and reinitialize them again. This seemed to give a stable operation but inserts a long delay between the timer interrupt and the actual sending of the data over the USART, which is unacceptable.

If anyone has any thoughts on this or have done anything similar, I need an advice on where to look at.

Thanks a lot in advance!

Best regards, 
Konstantin

[kpete]

I don't know why your are so concerned about this 32us shift.  I don't know why this is happening but 32us is 1 bit of the 30 bit (3 byte) Midi message which would take almost 1ms (0.96ms) for the entire message.  A human can't tell the difference between 15ms from the time the key is pressed and the sound is generated.  How do you expect a 32us delay to be a problem?  What happens when you start using Midi over USB?  The data might come faster as a buffered group but there is still a delay from the time the application starts sending it and the receiving device even sees it.

 

It sounds like you are not using any of the Midibox software for your testing.  Midibox uses a multi task operating system and I would think that if you tested it in this way it would not meet your expectations either. 

 

Respectfully Pete.

[kostix]

Hello! Thank you for your reply!

 

I am indeed not using any of the midibox here, rather than asking this as an advice. I have built several PIC based midiboxes few years ago, but now developing my own system and application. 

I can see what you mean. What I do not understand then is that why, when I connect this midi output to a trusty Roland audio interface midi input and then using asio drivers with low latency within an audio sequencer prog, say FL Studio, I then record the played notes, and export the audio at highest possible precision and PPQ setting, and at the end measure the time between the audio events, the time is uneven.

 

Any ideas appreciated!

[TK.]

31250 baud = 32 uS per bit.

 

So, the observed jitter is matching with the baudrate quantisation; it doesn't surprise me that it happens.

 

The same quantisation takes place at the receiver side again, which means that the worst case jitter is around 64 uS + system based latency & jitter of the receiving MIDI device (which might be several mS)

 

Best Regards, Thorsten.