This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

  • Resolved

Interrupt for DMA MPU violation of TMS5702135 device

Intellectual 900 points

Replies: 12

Views: 1573

Hello forum team,

I have implemented a DMA MPU self test to check if the MPU works as expected.

I defined a 64 bit word as destination region (MPU region 0), and the first two DMA configuration registers as source region (MPU region 1). Source region is read only. If I configure destination region as read/write, the two DMA configuration registers are copied by DMA to the destination region.

Now I changed the destination region to "no access". I expect that ESM1.2 flag should be set. But it isn't. I see the following settings:

0. The destination region is not written as expected.

1. The fault flag in destination region status register DMAMPST is set (DMAMPS[0].REG0FT is 1) as expected.

2. The corresponding interrupt is enabled (DMAMPCTRL[0].INT0ENA is 1. More exactly DMAMPCTRL[0] = 0x0000030F).

3. The CP15 performance monitor register is 9x41141810. ie. event bus is enabled with bit 4 in this register.

4. The corresponding IRQ in ESM register ESMIESR1 is 1 (ESMIESR1 = 0x140000AC, ESM group 1, channel 2 is enabled).

I wonder why ESM1.2 is not set. Maybe I have forgotten to set some register?

I have used the same DMA setting in a device TMS570LS4357, if the destination is writable, no byte is written. Is there any difference between TMS570LS2135 and TMS570LS4357 which I shall take into consideration?

Thank you!

Best regards,

Libo

 

 

 

 

 

  • 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.

    regards,

    Charles

     

  • In reply to Charles Tsai:

    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

  • In reply to Libo Luo:

    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. 

    regards,

    Charles

     

  • In reply to Charles Tsai:

    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?

     

  • In reply to Libo Luo:

    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.

    regards,

    Charles

     

  • In reply to Charles Tsai:

    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

    regards,

    Charles

     

  • In reply to Charles Tsai:

    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

  • In reply to Libo Luo:

    Hi Libo,

      I will run the test and get back to you.

    regards,

    Charles

     

  • In reply to Charles Tsai:

    Hi Libo,

      I ran the test and the behavior is proper. When I use the masterID to block the DMA, I will not see the transfer happen from the DMA register to the L2SRAM. However, there is no abort. This is expected. Please note that the DMA is not a CPU and it can not take the abort but instead it will set the BER (Bus Error) flag in the DMA module. You can enable the BER interrupt to notify the CPU. I have also tried to use the CPU to read from the DMA register with the masterID enabled to block the CPU access and in this case I do see the CPU trapping in the dabort routine.

      Please let me know if you have further questions.

    regards,

    Charles

     

  • In reply to Charles Tsai:

    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

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.