SPI + DMA is not working with variables placed inside RETRAM

[JMein.1]

Hello,

actually, our processor STM32MP153 (dual core) is completely full with the "normal" memory regions regarding the MCUs (M4) code and data. So now, we decided to add the RETRAM_data form

• ORIGIN = 0x00001000, LENGTH = 0x0000F000 /*60k*/

The linker works as expected but if I start a DMA transfer with variables placed inside this area, the DMA stucks directly with a transfer error. The same code but placed in the RAM1_data

• ORIGIN = 0x10030000, LENGTH = 0x00010000 /* 64K*/

works fine.

I know this problem only if the area is not accessible by the DMA as on the H7 but if I have a look at the memory layout and master/slave bus matrix, both DMA should be able to send data from the RetRAM.

Any ideas what could lead to this problem? I checked also to place the segment at 0x38000000 but this leads to a linux boot stuck.

My actual workaround is to place variables not used by the DMA into the RetRAM section .bss1 with the

__attribute__((section (".bss1")))

command. This works but, this is my next smaller question, this variable does not appear in gcc *.map file. Also somewhat curious.

The first question is the most important one.

Best regards,

Jan-Otto Meints

[JMein.1]

Hello all,

is it possible, that anyone from ST can have a look at this problem? We have actually no explanation on this but also got no feedback up til now.

Please have a look at this specific problem and provide us some help.

Thanks.

Best regards,

Jan-Otto

[PatrickF]

Hi @JMein.1​ 

I confirm that RETRAM must be accessed by all masters using 0x38000000 base address.

Only Cortex-M4 could access RETRAM at either 0x00000000 (I-Bus or D-Bus) or 0x38000000 (S-Bus).

I agree Reference manual is not clear about that, we will enhance that in future revision.

Anyway, as I'm not expert in this area, I cannot explain why you experiment Linux Boot stuck when you define Cortex-M4 local data segment in 0x38000000.

If it is related to OpenAMP/RpMsg buffers, maybe they are not expected to be in RETRAM in our ecosystem deliveries, so might need to dig more into some other settings to allow this (might be complex).

Sharing more information (console log, devie tree, etc...) could help to better understanding the issue scope.

Regards.

[JMein.1]

Hello Patrick,

so, the Linux part was only a small check for us but lead to no result.

The major problem is the access of the RETRAM by the M4 in combination with the DMA.

As you stated, the line in the linker

• RETRAM_data (xrw) : ORIGIN = 0x00001000, LENGTH = 0x0000F000 /* Length := 60K*/

to define a DMA accessible area should be therefore work fine. But, with a DMA usage and let DMA access variables in this area leads directly to an error.

The same variable defined e.g. static and with initialized values in

• RAM1_data (xrw) : ORIGIN = 0x10030000, LENGTH = 0x00010000 /* Length := 64K*/

works without any problems. Can you please check why this might be a problem on the STM32MP1?

We are running out of memory and need here an explanation for this behavior.

What further information do you need to reproduce out problem? I guess this is isolated from the Linux device tree because this is exclusively on the M4...

Best regads,

Jan-Otto

[PatrickF]

Hi,

DMA1/DMA2 can access SRAMx at either 0x10000000-0x1004FFFF or 0x30020000-0x3004FFFF.

This explain that your RAM1_data definition is working.

RETRAM is slightly different as you have seen.

For RETRAM, DMA1/DMA2 (and other bus masters like Cortex-A7) could only use 0x38000000-0x3800FFFF

Only Cortex-M4 could access RETRAM at either 0x00000000-0x0000FFFF (recommended for code and data access to get best performances) or 0x38000000-0x3800FFFF

For sure, in your linker, you could define both area (e.g. RETRAM_data and RETRAM_data_shadow), but as those are pointing to same physical memory, you should manage potential overlap area assignment by the linker (linker is maybe able to manage by itself with some specific keywords in liker file, but I'm not expert).

This RETRAM behavior is implementation choice inside the MLAHB bus matrix together with native Cortex-M4 access bus split Vs addresses.

Regards.

[JMein.1]

Hello Patrick,

if I got you right

"Only Cortex-M4 could access RETRAM at either 0x00000000-0x0000FFFF (recommended for code and data access to get best performances) or 0x38000000-0x3800FFFF".

the Cortex M4 with DMA can access the specified area and the variables placed inside.

But this fails.

So, if we have no overlapping with other areas, our linker lines are correct and if I go it right not overlapping (not phyically nor logically):

• RETRAM_data (xrw) : ORIGIN = 0x00001000, LENGTH = 0x0000F000 /* Length := 60K*/
• RAM1_data (xrw) : ORIGIN = 0x10030000, LENGTH = 0x00010000 /* Length := 64K*/

So, to be honest, the explanation (if the above linker lines are correct) why M4 DMA access to the RAM1_data memory location works and to the RAM1_data don't is still not clear to me :( Maybe you can explain in more detail?

Shall I attach the complete linker file or prepare a special isolated part of program that you can check/investigate on your own?

Best regards,

Jan-Otto

[PatrickF · Accepted solution]

Hi,

I think you misunderstand my wordings.

"the Cortex M4 with DMA can access the specified area and the variables placed inside. "

No, Cortex-M4 is the core and could execute code or do LDR/STR in RETRAM using 0x00000000-0x0000FFFF (recommended for code and data access to get best performances) or 0x38000000-0x3800FFFF

DMA1/DMA1 must use only 0x38000000-0x3800FFFF to access RETRAM

So, keeping your linker definition for RETRAM_data (startting at 0x00000000), when programming the DMA1 you must add (e.g. in your DMA start function call) the value 0x38000000 to the buffer address.

Regards

[JMein.1]

Hello Patrick,

yes I misunderstood you.

So, if I want to use the DMA1/2 with access to the RETRAM, I have to add to the DMA access the adress 0x38000000.

An automatic way would be finer (by the linker and placemend). So, we'll give it a second try with the defintion of the 0x38000000-0x3800FFFF and double check, why Linux then stucks.

If we still have trouble with this, I will attach the device tree and logs to come nearer to the problem.

Thanks for your patience.

Best regards,

Jan-Otto