2008-12-27 03:40 AM
DMA Causes Hardware Fault
2011-05-17 03:57 AM
Hi chuck,
Please read my post here : . Our Silicon Errata will be updated soon on web. Let let me know if it is your case and if you can implement the workaround for example using software semaphores to not have concurrent accesses to FSMC Areas. If it is not your case, DMA sends out an error only if the memories source/destination in a transfer is not on a valid memory range, Therefore you have to check your boundaries on that areas. Cheers, STOne-32. [ This message was edited by: STOne-32 on 21-12-2008 02:35 ]2011-05-17 03:57 AM
Board: STM3210E
When we external SRAM (0x68000000) as our memory source the DMA transfer does not complete and causes an Hardware Fault. When we use internal SRAM (0x20000000)the DMA completes with the TC interrupt and no exceptions are generated. The DMA/DAC setup follow the OneChannelDMA_Escalator example. The external SRAM setup follows the SRAM_DataMemory, the external memory is configured as BSS section. Is it possible that the DMA requires different wait state setup then normal program access? The application access the BSS memory correctly and the problem only occurs during DMA. -chuck2011-05-17 03:57 AM
Support,
I'm still a little confused. The referenced link refers to addresss 0x80000000-0xAFFFFFFF. The external SRAM we access is at 0x68000000 which seems to be out of the effected address range. Let me ask a simple question> Can we use the external SRAM on the EVAL board as BSS memory, which the appliction uses continuously, and DMA/DAC either out of internal or external SRAM? Can DMA2/DAC and DMA1/DAC run simultaneously? -chuck2011-05-17 03:57 AM
Hi chuck,
Sorry, it was a typo I mean starting from 0x6000_0000 {All FSMC memory range}, I have updated by previous post as well. Thank you for pointing it out.Quote:
Let me ask a simple question> Can we use the external SRAM on the EVAL board as BSS memory, which the appliction uses continuously, and DMA/DAC either out of internal or external SRAM? Can DMA2/DAC and DMA1/DAC run simultaneously?
Yes, You can, but You should ensure that Neither DMA1 , DMA2 & CPU are accessing an FSMC memory area (your External SRAM) at the same time. Hope this is helpful for you. Cheers, STOne-32. PS: I'm not Support :) , I'm just the STM32 Forum Moderator, If you would like to contact our support services , please refer to this linkhttp://www.st.com/stonline/domains/support/contact_mcu_support.htm
then click at ''For General Purpose MCUs''.2011-05-17 03:57 AM
I think I understand what this discussion implies for a possible STM32 application. I (may soon) have external h/w connected via FSMC. I am tempted to use DMA to xfer data between the FSMC area and main system RAM.
What I read here makes it sound as if as long as I don’t make concurrent CPU and DMA access to the FSMC area that I will be okay. My future h/w is a communications interface with variable length messages. For sending I interrupt on DMA done and set a GPIO bit signaling the h/w to ship the message. To receive the h/w sets a GPIO bit triggering an ISR. I read the length byte (and possibly check a destination address) then (if it’s my data) DMA the data to main system RAM. Timing protocols and high priority interrupts prevent collisions. STOne, Given the discussion in this thread do you see any STM32 problems?2011-05-17 03:57 AM
I moved my DMA buffer to internal SRAM while still using the external SRAM, 0x68000000, as program BSS memory. The DMA buffer is sized to be larger than my DMA write. The application runs flawlessly until I start the DMA/DAC transfer and then a Hardware Fault is generated. I think (I may be wrong) that in this case there is only one access to this FSMC area (the CPU). I'm I still missing something?
Is this a major flaw in the Cortex-M3 processor or a design feature? Will future revisions of the processor have this problem/feature? -chuck2011-05-17 03:57 AM
Hi Chuck,
You should ensure that your BSS area is not accessed by CPU while DMA is performing accesses to FSMC (External RAM) at the same time. This is a design limitation that would be in our erratas anytime, but since it is a vacations period, It would be on web In January 2009; This will be fixed in all future revisions of devices having FSMC feature of course. Be assured ! Cheers, STOne-32.