2018-08-24 03:17 AM
If I set up the DMA2D for a memory to memory transfer using AHB memory (SRAM1, 2 or 3), the transfer error (TEIF) flag gets set. The same setup addressing AXI SRAM works. The table in AN4891 page 13 suggests that the DMA2D can access SRAM1,2,3 so why does it not work?
2018-08-24 09:31 AM
Would agree diagramming suggests it is viable, not sure any special settings required.
Make sure SRAM1,2,3 Clocks are Enabled.
2018-08-31 01:53 AM
Can access the SRAM1,2,3 from the CPU, but DMA2D throws a TEIF :unamused_face:
2019-03-05 03:53 AM
Hi @Gid Rid - did you find a solution to this? Did you really make sure that your linker placed the data in D2 region? Most linker scripts seem to put it into DTCM ram - also the default AC6 linker script.
This solved it for me:
....
RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K
....
.vbuf :
{
. = ALIGN(4);
} >RAM_D2
-------------
__attribute__((section(".vbuf"))) uint16_t vbuf1[SSD1327HEIGHT][SSD1327WIDTH/2];
2019-03-05 04:03 AM
Hi @Max Rest , no solution found, could only use AXI SRAM with the DMA2D.
[Edit] I used a custom linker script to place the allocations, and checked in the map file and with the debugger. The TEIF may have been related to using AHB ram for both source and destination.
2019-03-05 10:14 AM
For completeness I will link to this thread about the clocks.
2019-04-08 04:58 AM
Hi,
Just wanted to chime in, I've been battling with these issues on my current project right now. Still trying to figure out what is going on with JPEG and the DMA2D itself, but I did manage to get the DMA2D transfer working with both source and destination being buffers in SRAM3.
Currently my allocations for vars and such are in DTCM ram, the JPEG module did not seem to work if it's working buffers were in AXI SRAM.
It's funny when you look at the flash.icf files in their project examples, you can see certain ones that clearly use only AXI RAM, but most of them use DTCM.
But for the DMA2D transfers, currently I'm using the interrupt method (shown in their examples), as I was having issues with the polling. But currently I am able to get a JPEG buffer copied from my addresses as shown:
(SRAM3)
src: 0x68200000
dst: 0x68000000
2019-04-08 07:35 AM
Hi Mike,
That also chimes with another problem I had with the DCMI with the jpeg bit set. On the F7 I had to poll the DMA->NDTR to prevent it overrunning the buffer, but the same trick did not work in the H7 because the CPU peripheral register access has to compete on the same bus with the DMA traffic. The F7 appears to have a dedicated side-channel bus for the CPU to access peripheral registers, while the H7 does not. I suspect this is a factor in other issues too.
Another gripe is that the H7' memory blocks are not contiguous in the memory space, whereas they are in the F7.
On paper the H7 specifications look good (more memory, faster processor, lower power) but the reality is that the F7 is a much better thought out design. The H7 seems to be a new processor and memory (good), with some of the F7 peripheral subsystem hastily glued on (bad).
2019-04-08 08:19 AM
I think the real problem was that the peripherals were designed to be managed by an IO processor. The H7 is more complex because things have gotten partitioned and you need to be more aware about localizing memory/bus traffic.
2019-04-12 06:47 AM
Hi,
Just wanted to update, I finally did get both JPEG and the DMA2D both working properly, both in polling mode, I was able to remove having to use interrupts for them.
entire flow was reading a JPG file from a microsd on my board, decoding it via polling to SRAM buffer, then DMA2D to pixel translation and output to FRAME BUFFER.
My sram buffers are:
0x6800:0000 (FRAME BUFFER)
0x6820:0000 (JPEG BUFFER)
Although, I was only having good lucking using RGB565 for the output format, even though I was setting up LCD, DMA2D properly for other formats, was trying ARGB8888, RGB888, but only had actual success with RGB565.
If you are still trying to get this to work, I can post some code if you need it, just let me know..