Hard Fault while DMA is running

[ericjulien9]

Posted on January 20, 2011 at 15:23

Hard Fault while DMA is running

[Tesla DeLorean]

Posted on May 17, 2011 at 14:22

What is your interrupt code doing? Is it conceivable that it is faulting, corrupting something, or that you are not servicing it resulting in a hard fault?

Fill your stack completely with a clear pattern (0x6B for example), park one of your JTAG memory view windows over the entire stack, or at least a large portion of the end of it (expand the view window to an appropriate size), and run the code. I'd be combing over the assembler code generated by the compiler, rather than trying to make sense of it at the source level. Also check the errata for the part.

[ericjulien9]

Posted on May 17, 2011 at 14:22

Thanks for your reply.

I've tried your suggestion to fill my stack. I've removed the problematic push and pop and I've made sure that the stack remained clean. It did stay clean.

There is indeed an interrupt routine associated with the SD transaction, but I don't think it's relevant, since it doesn't run during the period where my DMA runs. I've confirmed that with trace. What I'm doing in it is checking SDIO's status register and end of data flags.

I've included a trace showing assembly level execution from the point where I start the SDIO transaction (''STM32_REG_SDIO_DCTRL |= STM32_BIT_SDIO_DCTRL_DTEN;'') to the exception that occurs on the push {r3-r7} instruction. Note that in EWARM, There is one additional line showing ''Exception Entry 19'' at the end of the trace. Also, unless I'm mistaken and trace doesn't show everything, it confirms the ISR is not executed. 

I've had a look yesterday at the errata for the device but couldn't find anything relevant. I'll give it another look today, as I might have missed something.

Thanks for you help,

Eric

[Tesla DeLorean]

Posted on May 17, 2011 at 14:22

The problem with trace is that it doesn't store all the details and has to recreate flow from what should be in memory. It also can't see outside the core.

Have you tried dumping the registers at the fault? Have you checked the flash and wait state settings? Have you checked the APB1 & 2 clock settings. Have you checked the DMA buffer, is the data as you expect it to be, does it stop 100 words short, are there gaps, etc. Can you duplicate this on multiple parts/boards? Does this occur if you run from internal RAM?

[aqueisser]

Posted on May 17, 2011 at 14:22

Does a single push have the same effect as pushing multiple registers? Also, does the fault happen immediately or does the push instruction get part of the way?

Andrew

[damh]

Posted on May 17, 2011 at 14:22

Put a breakpoint on that ''push'' line and give all register values.

Make a single step and give all register values again. (Are you in hardfault now even with single step?) A disassembly of that critical area would be helpful 😉 (one of your code - and one of the nonfaulting code (push/pop behind last loop)) My worst hardfaults: - forgotten hardware breakpoint inside a command (breakpointaddress set to 16 bits behind start of a 32 bit command) -> in your case possible - wrong asm commands (ARM commands outside of ST's subset of ARM commands) -> possible, but inprobable

[kasper]

Posted on May 17, 2011 at 14:22

Hello,

I think i have some of the same problems maybe, i am using the keil RTX regarding to the thread in the bottom. I wonder, does your error happend all the time? mine seems to work after some compiles and not after antoher... i just cam in mind if the buffers for dma are not word alligned, if that could give any problems Kasper[DEAD LINK /public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/ARM CortexM3 STM32/STM32F2xx Keil RTX&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000626BE2B829C32145B9EB5739142DC17E&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%2520CortexM3%2520STM32/AllItems.aspx?Paged%3DTRUE%26p_DiscussionLastUpdated%3D20110107%252009%253a04%253a54%26p_ID%3D5105%26View%3D%257bEC839CCD%252d94F1%252d432B%252dBB98%252d7CB1618F3827%257d%26FolderCTID%3D0x012001%26PageFirstRow%3D81&currentviews=302]https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fARM%20CortexM3%20STM32%2fSTM32F2xx%20%20Keil%20RTX&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000626BE2B829C32145B9EB5739142DC17E&TopicsView=https%3A%2F%2Fmy%2Est%2Ecom%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FARM%2520CortexM3%2520STM32%2FAllItems%2Easpx%3FPaged%3DTRUE%26p%5FDiscussionLastUpdated%3D20110107%252009%253a04%253a54%26p%5FID%3D5105%26View%3D%257bEC839CCD%252d94F1%252d432B%252dBB98%252d7CB1618F3827%257d%26FolderCTID%3D0x012001%26PageFirstRow%3D81&currentviews=302

[ericjulien9]

Posted on May 17, 2011 at 14:22

Hi,

I want to let you know I've received a new STM3210E-EVAL board with a stm32f103zgt6 and it does not fault now. The same code would instead give me a SDIO underrun interrupt which I fixed by using hardware flow control.

 I understand it might not be a hardware problem, but I don't have a lot of time to dedicate to the issue now. I'd like to take a look at the flash, wait states, clock settings, etc as clive1 has suggested.

damh, I did try breaking on the push line. I can single-step without it faulting if I do that. You can see a disassembly of the area where it occured by looking at the trace output attached to my previous message.

Andrew, I  did try to change the ''push multiple'' into a few ''push singles''. In that case, I got a hard fault, but this time it was a Precice Bus Error fault. The address indicated by BFAR was indeed the address of the new SP. 

kasper, I had the error all the time. I made sure the buffers were 4 Bytes aligned.

Thanks a lot,

Eric