How to disable the write buffer(ACTLR ,DISDEFWBUF)

[shetty_siddharth]

Posted on June 27, 2012 at 13:16

Basically my application goes into the hard fault handler(where the IMPRECISERR bit is set) and I have read up about this on some forums and found out that I cannot find out the exact instruction causing this fault However somebody suggested that I disable the write buffer(which is in the ACTLR register). I do not know how to disable this, could you please help? I am writing the code in C, do I need to write some kind of assembly code to assess these registers? Thanks in advance.

[shetty_siddharth]

Posted on June 27, 2012 at 13:35In short i mean how can i write to DISDEFWBUF bit(write to 1) in the ACTLR register

[Tesla DeLorean]

Posted on June 27, 2012 at 13:59

Presumably in C you could use something like

uint32t *ACTLR = (uint32_t *)0xE000E008; *ACTLR |= 2; Though even with a imprecise fault you should be able to walk back a couple of instructions in the disassembly view and get a clue about which one (the store) that failed.

[shetty_siddharth]

Posted on June 27, 2012 at 14:10Thanks for this clive. However it gets into the hard fault error again :( Any other suggestions?

[shetty_siddharth]

Posted on June 27, 2012 at 14:22

Infact now it tells me that the PRECISERR bit is set, and on looking at the PC and finding out the instruction which cause this i find the instruction to be 

0x0000E7FC FFFFFFFF  DCD      0xFFFFFFFF   ; ? Undefined

[Tesla DeLorean]

Posted on June 27, 2012 at 16:46

Without knowing much about your context, ie the code and the conditions under which it faults, I'm going to guess you might have a stack that is too small, or you have something corrupting the stack or LR register.

Check the stack size in startup_stm32fxxx.s, or your linker script. Compare that to the size of local/automatic variables in your call tree to the point where the failure occurs. Marking the stack with a pattern may assist you in determining a maximum depth currently being used. Check that you're not out-of-bounding a local/automatic variable, running beyond the end of an array, copying a string that's too long. This may corrupt return addresses for other functions as the call tree unwinds. Is the fault occurring predictably, under the same/similar conditions? Do you have an interrupt without a service routine?