Interrupt for DMA MPU violation of TMS5702135 device

Hi Libo,

  Could you tell what the transfer size the DMA is configured to transfer? Is it 64bit or less than 64bit? Could you try to change to different transfer sizes and let me know if there is any differences. Sorry that I need to ask you to run these experiments because I don't have the setup to run them at home. The last two days of the week are major US holiday. The DMA in the LC4357 is a enhanced version from LS31x or the likes. So it is possible to see some subtle differences. Another comment is that the PMU is irrelevant here as the MPU fault is detected by the DMA itself, not the CPU.

Hello Charles,

 Thanks for following up this topic.

 I have done the following on a 4357 device to activate a DMA transaction: 

1. Define local variable test_data[2] (unsigned int), initialized to 0xFFFFFFFF, 0xFFFFFFFF.
2. Reset DMA (DMA_GCTRL = 0x1)
3. Release DMA (DMA_GCTRL = 0x0)
4. Configure channel 0 as reading from port B and writing to with port A: DMA_PAR0 = 0x44444444 (channel 1 – 7 are not used, but also configured here). (I also tested with the value 0x0, it makes no difference).
5. Channel 0 config: initial source address is &DM_GCTRL (the first DMA config register).
6. Channel 0 config: initial destination address is &test_data (the first 2 DMA config registers shall be copied to test_data).
7. Channel 0 config: set transfer count register ITCOUNT to 0x10001 (1 frame per block, 1 element per frame)
8. Channel 0 config: set channel control register CHCTRL to 0x1F000 (read element size is 64 bit, write element size is 64 bit, read and write address mode both are constant.
9. DMA MPU is disabled.
10. PCR1 master ID filtering is disabled.
11. Enable DMA: DMA_GCTRL is set to 0x00010300.
12. Enable channel 0: DMA_SWCHENAS is set to 0x1 (channel 1 is enabled by software).
13. Check the value of test_data. It is not changed.

 With the same setting, I can copy the first two DMA config registers to test_data on a TMS5703137 device.

 It seems that the channel 0 is not enabled. If I configure PCR1 master ID filtering at step 10 so that DMA is not allowed to read from DMA register PPS4MSTID_L = 0x1 (only CPU is allowed to access DMA registers), no data abort is triggered. This implies that DMA channel 0 doesn’t read from the DMA register.

 I have changed the combination of the element size, frame size, etc. to transfer either only 4 bytes or 8 bytes, it makes no difference.

 I suppose I have forgotten to set some register for the 4357 device.

 Do you have any idea, why the ESM1.2 flag is not set in my previous post?

 Thank you!

 Best regards,

 Libo

HI Libo,

  I can't find any issue with your setup and can't really pinpoint where the problem is yet for LC4357.  Sorry I have to ask you more questions to burden your time.

  1. Could you please tell me the various interrupt status flags, i.e. the BTC, LFS and etc. Since the transfer count is 1 frame and 1 element I will expect the flags to be set. The flags will give me more clues on the DMA's status. You provided a good hint that if masterID filtering is enabled, there is no abort. This means the read never happened in the first place.

  2. Please also check the PEND register. Is it clear or is it still set for channel 0? 

  3. By any chance any one of the NMPUs is enabled that blocks the transfer to the L2SRAM?

  4. Do you have the cache enabled? 

  5. Do you see any ESM flags other than GP1.2?

  6. When you said the dest is not changed, is it by looking at the CCS memory window or your code is actually reading the test_data to verify against the expected value?

  As for the LS3137, I was actually suggesting to try different transfer sizes to see if it makes a difference in setting the ESM1.2 or not. The LC4357 and LS3137 are two different problems you are seeing. We will  need to root cause them separately. 

Hi Charles,

In CCS I can see the following registers:

ChnPnd: 0x00000000

GlbIntFlg is 0x00000001,

LFSIntFlg is 0x00000001,

BERIntFlg is 0x00000001

PrtAChnSrcAddr 0xFFFFF000

PrtAChnDstAddr 0x0806E3C0

PrtAChnTrCnt 0x00010000  (Element counter is 0, I am not sure if this is OK).

All NMPUs are disabled.

All ESM flags are 0 (group 1, 2, 3, 4, 7).

I checked the destination date in debugger.

Thank you and best regards,

Libo

Cache: I assume it is enabled. but haven't checked yet. Which bit indicates this?

Hi Libo,

  Somehow there is a bus error detected as you indicated the BERIntFlg is 0x00000001. I will try to create a testcase to see if I can reproduce your observation and get back to you later.

Hi Libo,

  I created a testcase to mimic your setup to transfer 64bit from the DMA_GCTRL to the dst_data[2]. The dst_data is an array of two 32-bit and the array is initialized to 0xFFFFFFFF. After the DMA transfer, I see the dst_data changes to proper value in the expression window. I don't have MPU enabled. Please take a look at the project and perhaps compare with your project. You can also send me your project so i can take a look.

8032.LC4357_DMA_64bit.zip

Hi Charles,

thanks for the test project.

I have found out the data was transferred by DMA to the destination. Because cache is enabled, in debugger I still see the old value. Even if the destination is read in code, the old value is returned. I mean, I tried the following code after the DMA SW channel is enabled:

check_data[0] = destination_data[0];

If I disable the Cache in debugger, the destination_data is updated at once and I can see the correct value.

Now I face another issue.

Keep the same DMA transaction configuration, if I set PCR1_MSTIDENA = 0xA, and  PCR1_PPS4MSTID_L = 0x00000201 (only DAP and CPU may access DMA register),  and then enable Channel 0 to trigger the transaction. I expect that a data abort shall be triggered since DMA port B is not allowed to access DMA registers.

But no data abort is triggered. Could you please check if you can reproduce the behavior?

Thank you and best regards,

Libo

Hi Libo,

  I will run the test and get back to you.

Hi Charles,

thanks for the double check and the good explanation.

In my test, I see that DMAPST1 register can only be written in privileged mode. If it is written in user mode, a data abort will be triggered, please confirm this. In TRM it  both register DMAPST1 and DMAPST2 are described as "R/WC-0" register. I assume it should be "R/WPC-0" register.

I also see that the write access to ESMSR1 register in user mode is ignored, no data abort is triggered.

 In TRM 2.3.2.5, it reads

"Some modules also enforce register updates to only be allowed when the CPU is in a privileged mode of operation. If the CPU writes to these registers in user mode, the writes are ignored."

I think the description here can be more precise by stating something like "the writes are always ignored. For some registers a data abort is triggered."

Thank you!

Best regards,

Libo

Hi Charles,

thanks for the confirmation. I can close the thread now. Thank you very much for the excellent support!

Best regards,

Libo