UCD3138: Background loop is not responding, but time interrupt is fine

Jack, this doesn't happen very often, but there is a fix for it in the PFC EVM code.

I'll give the fix first, and then explain the complex background

There are 3 abort handlers which handle different exceptions:

- undefined_instruction_exception

- abort_prefetch_exception

- abort_data_fetch_exception

The simplest thing to do is to add a software reset to each one like this:

void undefined_instruction_exception(void)
{
         SysRegs.SYSECR.bit.RESET = 2;
}

This should solve your issue. 

If you want to go further and make your noise caused reset more reliable, and even debug your code, you can look at how the PFC EVM handles this issue.  I describe that after the explanation below.

What is happening is that the background loop is getting lost.  Every time we have seen it, it is because of layout/noise issues causing the UCD to get lost.  

Theoretically it could also be caused by the program having a bug, but I don't think we've ever seen that.

If there is a single fault caused by noise or a bug, the ARM7 will generally detect an illegal memory access or illegal instruction fault.  When this happens, it will go to the fault handler, which will try to push things on the stack.  Most of our codes do not initialize these stack pointers, so generally they are pointing at an illegal address.  With 2 faults like that, the UCD seems to reset automatically. 

Specific UCD parts tend to have the same stack pointer come up every time, and a few will have a legal address.  These are the ones that will display this issue.

Also to have this issue, the noise and the individual part's sensitivity to it have to be just right so that the noise only causes one fault.  Most often, there are more faults, so again, instant reset.  

This is background to to explain why you don't see this very often.  

Next for an explanation of why this happens:

The ARM7 was originally designed for use in PCs.  The idea behind the illegal memory access and instruction aborts was that the operating system could chose to fix the issue and then return to the same location where the abort occurred.  So the exceptions return to the address at which the abort was found.  This means that they just keep returning to the instruction and getting another abort.  So the background loop just gets stuck.  

However, interrupts can occur when the abort returns to the background loop, so they keep running.  

The way to fix it is to make sure that the abort resets the processor.

If you also put in a valid stack pointer address for all the aborts.

This makes sure that an intermittent fault also resets the processor.  It's possible, even likely, that other things may be corrupted when an intermittent fault occurs.  Even if that specific fault goes away, it's a good idea to reset the processor to avoid damaging the power supply.  

For the stack pointer setting, you need to find load.asm.  In the older codes it is in the main source directory.  In the newer codes, which support multiple processors, there is a unique load.asm for each UCD part number.  It will be in Device/UCD3138/Source, for example.

You need to add ABT_STACK_TOP to the .equ statements at the top of the file:

SUP_STACK_TOP .equ 0x19ffc ;Supervisor mode (SWI stack) starts at top of memory
FIQ_STACK_TOP .equ 0x19e00 ;allocate 256 bytes to supervisor stack, then do FIQ stack
IRQ_STACK_TOP .equ 0x19d00 ;allocate 256 bytes to fiq stack, then start irq stack
ABT_STACK_TOP .equ 0x19b50 ;Allocate 432 bytes to irq stack
UND_STACK_TOP .equ 0x19b50 ;allocate 80 bytes to abt stack
USER_STACK_TOP .equ 0x19b00 ;allocate 80 bytes to und stack, regular stack gets rest, down to variables

then you need to add initializing the 2 abort stacks.  It's OK to have them all at the same address, since you will use only one at a time:

;*------------------------------------------------------
;* SET TO IRQ MODE, init IRQ stack
;*------------------------------------------------------
MRS r0, cpsr
BIC r0, r0, #0x1F ; CLEAR MODES
ORR r0, r0, #0x12 ; SET IRQ MODE
MSR cpsr_cf, r0

LDR R13, c_irq_stack_top ; initialize stack pointer

;*------------------------------------------------------
;* SET TO ABORT MODE, init ABORT stack
;*------------------------------------------------------
MRS r0, cpsr
BIC r0, r0, #0x1F ; CLEAR MODES
ORR r0, r0, #0x17 ; SET ABORT MODE
MSR cpsr_cf, r0

LDR R13, c_abt_stack_top ; initialize stack pointer
;*------------------------------------------------------
;* SET TO UNDEFINED MODE, init UNDEFINED stack
;*------------------------------------------------------
MRS r0, cpsr
BIC r0, r0, #0x1F ; CLEAR MODES
ORR r0, r0, #0x1B ; SET UNDEFINED MODE
MSR cpsr_cf, r0

LDR R13, c_und_stack_top ; initialize stack pointer

;*------------------------------------------------------
;* SET TO USER MODE, init user stack

You'll also need to add the commands to put the addresses into flash for the processor to read:

c_sup_stack_top .long SUP_STACK_TOP
c_abt_stack_top .long ABT_STACK_TOP
c_und_stack_top .long UND_STACK_TOP
c_user_stack_top .long USER_STACK_TOP

If you set up the stack pointers this way, you should get more reliable reset for all chips, not just the few who have stack pointers that come up in a legal address.