topic Re: Can not exit Bus Fault Handler in Kinetis Microcontrollers

Can not exit Bus Fault Handler

ralf1694 — Mon, 23 May 2016 13:05:36 GMT

Hi. I have the problem, that I can not exit the Bus Fault Handler.

Here is my code:

startup:

BusFault_Handler\

PROC

EXPORT BusFault_Handler [WEAK]

IMPORT BusFault_ISR_Handler

LDR R0, =BusFault_ISR_Handler

BX R0

ENDP

main(){

...

//Enalbe Bus Fault exception

SCB->SHCSR |= SCB_SHCSR_BUSFAULTENA_Msk;

...

}

void BusFault_ISR_Handler(void){

int test = 1;

}

Re: Can not exit Bus Fault Handler

jeremyzhou — Tue, 24 May 2016 01:31:30 GMT

Hi Oliver,

Thank you for your interest in NXP Semiconductor product and

I was wondering if you can tell what the exactly chip you use, and it will help me to investigate the issue.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Can not exit Bus Fault Handler

ralf1694 — Fri, 27 May 2016 13:31:59 GMT

Hi. I use the MK22FX512VLH12.

I write 2 times the same Flash address to provoke an bus error.

When I am reading this address, I jump in the Bus Fault ISR but can not leave them.

Re: Can not exit Bus Fault Handler

egoodii — Fri, 27 May 2016 14:19:05 GMT

Bus Faults generally point out fatal firmware flaws. A 'return' to re-execute the offending code will cause the fault to recur. In what context do you see a 'return from bus fault' being a useful concept?

Re: Can not exit Bus Fault Handler

ralf1694 — Sun, 29 May 2016 14:02:08 GMT

I use the fault to find corruption on flash memory.

Re: Can not exit Bus Fault Handler

egoodii — Sun, 29 May 2016 15:21:02 GMT

I don't understand what that statement means. Most of us find 'corruption' in Flash memory contents by running a CRC over it as part of BIST.

But if you are still going to pursue this concept:

The ARM 'fault process' pushes a special frame onto the stack, a 'coded value' into LX, and some extra 'fault info' in core control registers.

You say you 'cannot exit' the handler, and let me speculate the cause: 'Imprecise error' is SET, and this means the core-control registers contain 'limited useful content', and the LX code-value may be one the hardware recognizes as 'non viable' return info. This means the fault occurred NOT as a 'direct result' of the 'current' instruction. The 'most particular' cause of such is a 'write fault', because this ARM architecture has 'write buffers' to improve performance by allowing code to proceed while the actual write-op works thru arbs and busses to completion. So the detection that said 'write' is 'bad' is 'many cycles removed' from the causing-instruction, and thus the 'capture' by hardware of processor-state at THAT instant is 'way-late' and non-informative -- the faulting instruction CANNOT be found and re-started. To make write-faults PRECISE you must turn off the write-buffering capability in THAT system-control register. Only in THAT mode COULD you look at the offending information, run a 'corrective action' (like enabling a peripheral clock, or paging-in a block of memory...) and return to let the instruction re-run.

Re: Can not exit Bus Fault Handler

ralf1694 — Sun, 29 May 2016 21:22:37 GMT

My problem is that corrupted flash causes a fault exception to be generated when read. So I can not check the data with a CRC because I can not read the data from flash.

Thanks I check this as soon as possible.

Re: Can not exit Bus Fault Handler

egoodii — Sun, 29 May 2016 21:49:15 GMT

I have never heard of 'bus fault' from ANY flash-read operation, UNLESS said flash-bank is 'busy' doing a write-op, where of course THAT type of operation needs proper full interlock. Still sounds like a 'fatal firmware flaw' that you need to track down, but I still don't see how 'return from fault' comes into your normal code suite.

What kind of process do you believe is CAUSING this 'corruption'??? I guess I have heard of issues where users try to re-write 'parts of a flash phrase' WITHOUT a prior erase, and this 'forbidden over-write' process CAN cause read trouble as the ECC associated with that phrase CANNOT be properly 'added to'. Now that I re-read your prior statement in this light, it looks like you have done EXACTLY this to provoke this exact error condition. So IS this a fault you are 'trying to handle' in the 'final product' as part of said bootloader-BIST (presumably due to some kind of actual uncorrectable FLASH memory alteration by comsic rays)? In that case, then occurrence of such a fault sounds 'sufficient' to declare the FLASH contents 'bad' and invoke the process to attempt application-image recovery. I STILL don't see any reason to attempt to RETURN from the bus fault (to the CRC-loop).

Re: Can not exit Bus Fault Handler

ralf1694 — Mon, 30 May 2016 06:03:36 GMT

I save my data on flash, when a powerfail is detcted. The problem is that I can not dissable the Interrupts when I am doing the write command, because I need the Interrupts. So I think an interrupt occurse when I try to write my flash. When I read the flash address, I get a bus fault.

Re: Can not exit Bus Fault Handler

egoodii — Mon, 30 May 2016 13:37:26 GMT

As long as your vector-table and handlers are in a different flash-bank from that which you are 'writing' you shouldn't have any DIRECT problems as a result of interrupts-during-write. BUT if this is 'powerfail' logic you might need to double-check your supply holdup time to insure you have valid power long enough to complete the flash-erase/write cycle!

If the potential for 'power loss while writing' is unavoidable, such that the phrase-write CANNOT be guaranteed, it sounds like your bus-fault handler could 'look into' the stacked fault frame, 'recognize' the pointed-to instruction as being your 'valid read' loop, and MODIFY the index-registers-in-use to SKIP the 'current' phrase entirely (and supply some kind of 'dummy' data?) and THEN you should be able to 'return' from the handler back to that code and it could continue.