cancel
Showing results for 
Search instead for 
Did you mean: 

How to disable the write buffer(ACTLR ,DISDEFWBUF)

shetty_siddharth
Associate II
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.

5 REPLIES 5
shetty_siddharth
Associate II
Posted on June 27, 2012 at 13:35

In short i mean how can i write to DISDEFWBUF bit(write to 1) in the ACTLR register

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.
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
shetty_siddharth
Associate II
Posted on June 27, 2012 at 14:10

Thanks for this clive. However it gets into the hard fault error again :( Any other suggestions?

shetty_siddharth
Associate II
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

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?
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..