EDMA Incomplete Transfer using QTMR on the RT-1050

[greg_nowak]

I have an LED light ring that I'm driving via Pwm setup using the QTMR timer DMA and the "EDMA" component on the RT-1050.

I am setting up the DMA using the EDMA component and the QTMR component shown below. 

I have the following situation:

99% of the time DMA transfers work successfully.  When the transfer is complete the lights are updated as expected and life goes on.

I have a rotary encoder that, based on position change, sends an event to this LED engine to update the LED display.

If I rotate the rotary encoder too quickly (i.e. too many of these events are sent to the Crank Story Board Engine) the "DMACompleteCallback" will come back with a "transferDone" set to false.

My question:

1.  What would cause the EDMA callback to come back with a transfer complete set to false?  We are not doing scatter/gather so it should 'always' be true.

2.  What do I do when this occurs?  I need the original transfer to "re-try" if there was an error.

3.  I have a second stage bootloader that is running the application.  I don't have issues when the bootloader is not present.  Is there something special I need to do with clock de-initialization before I can run an application that is expecting to run from reset?  

Observations: 

I have this project setup with a second stage bootloader that launches the application.  The application, when stand alone without the debugger, does not seem to have these DMA incomplete errors.  I'm also unable to get it to trip the incomplete transfer when connected with the debugger.  "occasionally" I can get it to hit the breakpoint, but rarely.  Without the debugger I can cause this situation without seconds.

Thanks,

[Sabina_Bruce]

Hello Gregory,

Hope you are doing well.

Based on your description this situation is very specific so it is difficult to pinpoint where the root of the problem is coming from. I recommend to attempt changing the logic on your callback. Instead of waiting for an incomplete transfer, please attempt to not continue with your application unless a complete transfer has been made properly. You may refer to examples provided in the SDK for both EDMA examples as well as QTMR using DMA which have this type of logic implemented. 

Please let me know if this results differently for you.

Best Regards,

Sabina

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

----------------------------------------------------------------------------------------------------------------------- 

[greg_nowak]

Sabina,

The original implementation did not continue unless the transfer completed successfully but it never would complete successfully, the program would "hang" and that "transferDone" would never be true unless I started the transfer over again.  

Right now I'm simply re-trying the LED animation again, but since the original transfer still failed the LEDs "blink" an incorrect state before correcting themselves with the retry. 

The heart of the complexity here is that this doesn't have a problem if I don't have my second stage bootloader jumping to the application.  I'm wondering if there is a clock initialization issue or something that I shouldn't be doing twice that I am when the bootloader is in the loop.  

It definitely seems timing related since it only seems to jam up when I move the encoder quickly (i.e. generating lots of update events).

Greg

[Sabina_Bruce]

Hello Gregory,

Hope you are doing well.

I don't think that it necessarily has to be a timing issue nor that a double clock initialization makes it trip up. Normally when there is a double initialization the older one gets ignored. When you move the encoder quickly as you mention it generates a lot of events, it is possible that in the middle of one callback you are restarting another one which would cause this to trip. In addition, since the behavior is only cause by fast movements in the encoder causing it not to complete successfully, I would reconsider using the original example and checking why it is not completing successfully as you mention.  It is possible that whatever is causing that to not successfully go through is where the root of the issue may be.

My question regarding that would be:

When using the original implementation, you mention "The original implementation did not continue unless the transfer completed successfully but it never would complete successfully"..

Was the behavior the same for both when you turn the encoder fast or slow?

Best Regards,

Sabina

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------