S32K322 DMA Configuration - Bus Error on Source Read

[andrew_smith]

Dear all,

I'm trying to port some code which has worked for years on MPC57xx and S32K1xx devices to the S32K322. I am setting up 2 consecutive DMA channels to play ping-pong with each other.

The problem is the first channel's initial source read is causing the SBE bit to be set, and I can't work out why.

I have set a breakpoint at the instruction which will cause the START bit of the first channel to request service, and a second breakpoint at the next sw instruction. The two pictures show the DMA configuration for the two channels in the before and after condition.

The intention of the first channel (TCD0) is to read 4 bytes of memory from RAM (at 0x2000A248), and put the contents of that memory in the second channel's source address (see TCD0's DADDR is 0x40214020, which is the address of SADDR for TCD1).

I would therefore expect the content of the TCD1 SADDR to become the contents of the memory at 0x2000A248.

As you can see, CITER is being decremented, but the transfer is not taking place; TCD1 SADDR is not altered and the CH0_ES bits become set.

D-cache is turned off, so the RAM is not being cached. And the DMA mux for channels 0 and 1 has the ENBL bit set (Addresses 0x40280002 and 0x40280003 are 0x80).

Does anyone have any thoughts on what I might be missing?

This is a bare-metal project, no RTD or anything else at play.

Thanks and Regards,

Andrew

[danielmartynek]

Hi @andrew_smith,

Can you share the code so that I can test it?

[andrew_smith]

Hello Daniel,

Can't give you the code as it is....I'll have to graft it into a 'vanilla' NXP project and post it to you - do you have a direct address?

Just one thought I have had - it used to be the case that you had to give DMA access to RAM via the AIPS....there are no AIPS registers on the K3 as far as I know so I assume access is immediately possible. I have not enabled the XRDC either (which I'm sure would intercept a bus request and stop it). But are there any other barriers to the DMA having access to RAM (XBIC?).

Thanks for responding

Andrew

[danielmartynek]

Hello Andrew, 

If you prefer not to share the code publicly, feel free to send me a private message here.

That said, I generally recommend creating a support ticket for better tracking and follow-up.

You're correct, XRDC is designed for this purpose, but it is disabled by default.

XBIC does provide integrity checking and is enabled by default; however, it typically should not cause this issue.

Unpredictable behavior can often be linked to incorrect system clock settings. The MCU operates reliably only when the clock ratios align with the options specified in the Reference Manual, for example, Table 157 outlines Option A for High Performance mode (CORE_CLK @ 160 MHz).

This is important because modules like eDMA, SRAM, and XBIC must operate at specific, defined clock frequencies to function correctly.

Regards,

Daniel  

[andrew_smith]

Dear Daniel,

I have created a bare-bones project which includes our exact clock setup and DMA configuration.

Interestingly, it does *not* show the symptoms in my original post (in that it does not throw the SBE bit on the first attempt to make a transfer) - however, the 'ping-pong' being played between the two linked channels yields data which is not correct in the output buffer (though the result is consistent).

Bearing in mind your comments with regard to clocking, I'm going to take a close look at that before sending you this project (FYI, core speed should be 160MHz, everything else is at either 80MHz or 40MHz). 

Thanks for your help; I'll be in touch if I send you the project.

Kind Regards,

Andrew

[andrew_smith · Accepted solution]

OK - I have managed to reproduce and solve the problem.

When the initial source pointer read is from an address in RAM - there is no problem - the DMA access works exactly as I would expect and I can get a correct stream of data of my choosing.

However, where the initial access is to the DTCM, there is a problem. SBE is immediately set on the first source read.

This is because the eDMA must use the backdoor address when accessing DTCM, not the real address of the variable of interest - so looks like I need to offset the address by 0x1000000 when it's in DTCM, but not when it's in RAM.

Look closely at examples 5, 6 and 7 in AN13388 and the Memory map attached to the Reference Manual.

Hopefully this might help someone else with a similar problem.

Thanks Daniel for getting back to me, and making me think about it some more.