*****

A DMA transfer takes a finite time; I haven't found a specification for how long it takes in the TRM/datasheet.

The entire second group (1-0-0) cycle seems to be stretched out. Are you using the DMA for anything else? What sort of bus activity is the CPU generating? (You seem to be running very close to the limit, so these things could matter.)

I am not using the DMA for anything else. All other DMA channels are inactive (unconfigured) in the syscfg.

If you mean external bus activity: There is only one external bus connected - the CAN bus: it is expected to receive around 15 Frames every 50ms.

For the internal bus activity: PD0 and PD1 peripheral buses see below.

For the pixel clock generation I use TIMA1.

Other configured peripherals are:

• TIMA0 Timer in PWM mode for the backlight – 500HZ
• Two General Timers : TIMG0 and TIMG6
• MCAN – in FD mode.
• ADC
• EVENT – 1 Event used to trigger the DMA
• CRC
• I2C – only used at start-up

See image with the configuration overview:

Hello Bruce,

thank you for checking it out!

I am also assuming that we are very close to the limit.

See answers to your points:
1. --> WFI/WFE would mean that during the DMA transfer we cannot do any computation. As we do not have a frame buffer, we use that time to compute the next row for the LCD.
2. --> It is not all the time the second triplet. It depends on how I configure the PWM for the pixel clock and on which event I trigger the DMA transfer. I saw that it happends also in the middle of the "1 0 0 data".
With 5 MHz it seems to to be working well. The pulse (from the 1 0 0 triplet) has constant high level - it is not stretched. Also, from my analysis there is no extra pixel clock.

3. Yes, the PCLK runs all the time, to respect also the porch timings. The DMA is started by:
DL_DMA_setTransferSize(DMA, DMA_LCD_CHAN_ID, transferLength);
DL_DMA_enableChannel(DMA, DMA_LCD_CHAN_ID);

Best regards,
Mihai

[I haven't been ignoring you, but I also don't have any good answers.]

Two notions ["suggestions" would be too strong a term]:

1) If we suppose that (a) what we're seeing is some kind of startup artifact with the DMA and (b) the DE signal is part of the data (the bit-vector being written to DOUT), there may be some value in prepending "dummy" bits with DE=0 to the actual data, to give whatever-this-is time to settle. 

2) Starting the DMA by Enabling the channel (with PCLK active), vs clearing/enabling the Event trigger (ICLR/IMASK), would mean that there is almost certainly a request already in the Event channel (MIS), with the result that the first DMA transfer would trigger immediately -- not synchronized with PCLK -- in which case the first bit would be short. But I don't see that in the scope trace, so I suppose I'm missing something.

Hello Bruce,

I am answering on behalf of Mihai, he could not post here anymore (getting an error).

Thank you for the clarification!

We already tried in repeat single DMA, but, as you said, we cannot handle the other timings.

We have now also the point one (1) implementation. The DE is part of the data, and we send a few DE = 0 dummys. But the risks are big that the PCLK "loss" doesn't happen at the beginning of the transfer. Especially that we also saw that it happens in the middle of the transfer.

For us it is clear that we are at the limit of the MCU, and we cannot find a robust solution for the control. It is important that we understood what is happening, and why is this issue happening.

Therefore, we are following two paths at this moment:

- clarifying with the LCD manufacturer to find ways to lower the PCLK, and control the display as stated here.

- hw design change, in order to control the display with more GPIOs from the same DOUT port, in parallel mode. This would let us then to lower the PCLK to 3-5MHz. First tests show that in this way the DMA transfer is working without any problems.

I think that at this point, we can close this issue here.

Best regards