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.
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.REG0FT is 1) as expected.
2. The corresponding interrupt is enabled (DMAMPCTRL.INT0ENA is 1. More exactly DMAMPCTRL = 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?
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.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Charles Tsai:
Thanks for following up this topic.
I have done the following on a 4357 device to activate a DMA transaction:
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?
In reply to Libo Luo:
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.
In CCS I can see the following registers:
GlbIntFlg is 0x00000001,
LFSIntFlg is 0x00000001,
BERIntFlg is 0x00000001
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,
Cache: I assume it is enabled. but haven't checked yet. Which bit indicates this?
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.
I created a testcase to mimic your setup to transfer 64bit from the DMA_GCTRL to the dst_data. 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.
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 = destination_data;
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?
I will run the test and get back to you.
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.
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 184.108.40.206, 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."
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.