RM48L952: Testing ESM Error Handler

7. nError will be driven low in every case of an ESM error and remain low until the EKR register is cleared. I have captured this behavior successfully for channels 1,7,11,15,18,19,26,10,6,35 but for those other channels that I have questioned above I am not able to show that nError is held low.

QJW> Any error from the channels of ESM group 2 and ESM group 3 will pull the ERROR pin LOW. The Group1 errors have a configurable ERROR pin behavior.

BTW, what is FEE in #5 and #6?

In the screenshot below you can see my typical halcogen configuration of required group 1 channels:

Taking the MIBADC2 as an example you can see in the screenshot below what activity I see when running a build with adc2ParityCheck called prior to my application loop. as expected my debug output shows the correct channel of ESM registered as the fault and the nError pin remains low upon detection. 

Now, if I run a similar build but this time call checkFlashECC the correct channel is logged as generating the ESM error but for some reason the nError pin does not remain low. All logic in my application is the same other than I am calling the checkFlashECC in place of adc2ParityCheck. So why does nError go high? It is important for me to understand this as production intent builds are all assuming that any ESM error that I have configured will result in nError driven and held low until the application decides it is OK to release it by clearing the EKR register. 

One thing I thought might be causing this would be a pre-load on the ESM EKR register but I can't see anything in the self test routine that does that.

Hello, can anyone tell me why nError does not remain low when I run these selftest routines. here is an example running the checkRAMEcc() function. My ESM handler correctly catches the channel 26 fault but nError does not remain low:

I really need to see data that verifies, at least once, each of the diagnostics i'm expecting to be enabled running. With the appropriate nError activity. Halcogen is always configured the same way, I cannot see why some would allow nError to return to the high state. Appreciate some input on this, so I can close out the verification.

Hello Sunil,

Yes I have nError set to be driven low for every group 3 channel as listed above. My expectation was for every fault to deliver the same activity on nError but some of them are not holding nError low. I can be more specific tomorrow when back in the office, but earlier in this post I listed all group 3 faults that I need to establish at least one test for.

Thanks

Jamie

Hello sunil,

My post on Sep 25, 2018 12:04 AM: showed how nError behaves differently depending on the self-test routines I execute even though I have ESM group 1s all configured the same way with a low interrupt and nError driven low. I suspect some of the routines are simply pre-loading the EKR register but have not been able to confirm this. In some cases I am perhaps using the wrong self test routine to inject fault, feedback on what I should be doing would be appreciated.

To recap, I have selected the following group 1 errors as relevant to my application and need, at least once, to verify on bench that I can catch them and act upon them as intended. The main problems are

1. nError does not remain low on channel 6, 26, what is clearing it?

2. have not identified the best way to test channels 27, 31, 37, please advise what I can use or direct me to a test method

3. EEPROM single and double bit errors, once injected, prohibit my application from running as before, all outputs are de-energized due to the nError pin state but I cannot read my input button that would normally clear the fault status after subsquent powerups. Is this because I have no recovery on the EEPROM so the MCU remains stuck in a fault state?

Thank you for this information, I am working through it.

My approach to IOMM was to make an illegal write to the IOMM registers while in USER mode. This successfully delivered the expected ESM response and nError activity.

But it has thrown up something else. The activity of nError seems to be somehow related to whether or not I am in USER mode. I will try to explain but this is a really confusing behavior!

My application sequence is as follows:

1. initialize ESM record from FEE

2. if no ESM faults recorded last power cycle then inject the fault (e.g. ADC2Parity)

2a. ESM handler will run from interrupt

2b. ESM handler writes the channel ID to ESM record in FEE (as read in step 1.), nError is driven low and no action is taken by the application to clear the EKR register so it should remain low

5. If ESM record shows error adopt FAULT state

5a. permit clearing of ESM record in FEE if nError is "HIGH" i.e. no ESM error this power cycle, otherwise we remain in the FAULT state

Step 2 is a local function call, within that call I move the core to USER mode after injecting the error and before entering my main loop. I do this in the understanding that I should really have my application running in USER mode unless I have good reason not to. When I make the transition to USER mode in this local function the nError activity is as I expected, remaining low when we inject the fault.

If I move the instruction to adopt USER mode to after the local function call, but before entering my main  for loop & state machine the nError activity is not correct. It goes high again after the low time counter expires. It is as if the location of the instruction to enter USER mode somehow impacts nError clearing or remaining low. I cannot find any reference to USER mode having an impact on the EKR register that would result in the nError being driven high again. I certainly don't understand why moving the instruction to enter USER mode from within the local function to the immediate statement after it changes the behavior so significantly. Could it be something to do with interrupt sequencing, is there something else with the command to enter USER mode that could adversely impact the EKR register status and thus release the nError pin?

For reference, I use the simple asm( " CPS 30x10"); instruction to get in to USER mode.

I thought there was something strange around my interfacing with the FEE driver. I now see that my FEE writes to reset my record of ESM work when I don't have the module in USER mode but they are incomplete/unsuccessful when I run them with it in USER mode.  Here is one such function that writes successfully when not in USER mode but is incomplete/unsuccessful when I have the application moved to USER mode.

void uni_cfg_esm_upd(void)
{
    if(uni_cfg_esm_write && (IDLE == TI_Fee_GetStatus(0)))
    {
        uni_cfg_packdata(uni_cfg_blk2_params, UNI_CFG_NUMPARAMS_BLK2);
        TI_Fee_WriteSync(2,fee_databuffer);
        uni_cfg_esm_write = FALSE;
    }
}/* end uni_cfg_esm_upd_l */

At 1 second intervals I read back the block, when in USER mode the reads are not indicating success i.e. the value I tried to write is coming back wrong. If not in USER mode it is always successful. So something interrupts or prevents a successful read/write when in USER mode. 

Should I be doing something specific when interfacing with the Ti_FEE_Read/Write library functions to first move to a Privileged state? 

Definitely closing in on a root cause here. 

So moving to USER mode earlier, when I initialize all global configuration data from EEPROM it is clear that the FEE reads fail. If I enter USER mode before the intialization routine I basically get garbage out of EEPROM, if I move to USER mode after the initilization from EEPROM my congfiguration data is accurate. Could it be that RTI interrupts, in conjunction with being in the USER mode are screwing up my reads ? Each block is initialized with a construct similar to this:

TI_FeeModuleStatusType Status_l;

    TI_Fee_Read(5,0,(uint8*)fee_databuffer,UNI_CFG_SIZE_BLK5);
    do
    {
        TI_Fee_MainFunction();
        delay();
        Status_l=TI_Fee_GetStatus(0);
    }
    while(Status_l!=IDLE);
    uni_cfg_unpackdata(uni_cfg_blk5_params, UNI_CFG_NUMPARAMS_BLK5);

The unpack function is as follows:

void uni_cfg_unpackdata(struct fee_data_block* dbp, uint8 numparams)
{
    char *p;

    p = &fee_databuffer[0];
    /* For each parameter in the data block */
    for(uint8 i=0;i< numparams; i++)
    {
        //write each byte and move databuffer pointer */
        for(uint8 j=0;j < dbp[i].size;j++)
        {
            *(dbp[i].address + j) = *p;
            p++;
        }
    }
}/* end uni_cfg_unpackdata */

I think the unpack routine is OK as it works fine when I run the reads in privileged mode. So I am reaching the conclusion that Ti_FEE_Read and probably Ti_FEE_Write etc should

1. only be ran in privileged mode

2. may be interrupted or return bad data if RTI interrupts or similar interrupts can occur during the FEE activity

3. that the FEE library functions are not inherently safe with regard to changing between USER mode to priviged modes or against interrupts

Any direction or examples on the safe / correct usage of the Ti_FEE library while in USER mode would be appreciated.

Hello QJ,

So this morning I took the examples from SPNA218 and integrated a mode switcher from USER to SYSTEM mode via the SVC handler examples provided. As I am only using SVC to move between the modes when working with FEE I have the following assembler function:

;-------------------------------------------------------------------------------
; SWI wrapper
        .global     _svc
        .text
        .arm
        .armfunc    _svc

   .align 4
_svc:
        .asmfunc
        ; Preserver A1 and A2 these may hold parameters to the function which are needed in C level handler
        ; Note: This handler doesn't preserve callee saved (Save-on-call) registers, A1 to A4 and V9.
        ;       In other words the callee function has to preserve them which is ensured when function like SVC is used in C (#pragma SWI_ALIAS() or __svc())
        ;       Take care when assembly inlining SVC / SWI.

        MRS     A4, SPSR            ; Get spsr

        TST     A4, #0x20           ; Called in Thumb state?

        ; Note: When called from Thumb code only 256 unique SVC handlers can be distungished, as the Thumb SVC instruction has only a 8 bit field.
        ;       When called from ARM code 2^24 unique SVC handlers can be distungished, as the ARM SVC instruction has a 24 bit field.

        LDRNEH  A3, [lr,#-2]        ; Yes: Load halfword and...
        BICNE   A3, A3, #0xFF00     ; ...extract comment field
        LDREQ   A3, [lr,#-4]        ; No: Load word and...
        BICEQ   A3, A3, #0xFF000000 ; ...extract comment field
                                    ; r2/A3 now contains SVC number
                                    ; r3/A4 now contains SPSR (Saved Program Status Register)

        CMP     A3, #32
        BHI     _default            ; Branch if higher

		LDRLS   pc, [pc, A3, LSL #2]; Load address from table

		.word   0x00

_table: .word   (_case0)  ; unimplementedSVC
        .word   (_case1)  ; switchCpuMode
        .word   (_case2)  ; switchToSystemMode
        .word   (_case3)  ; switchToUserMode

        .word   0x00

_case0: ; unimplementedSVC (used to test fault handler)
        B       _default

_case1: ; switchCpuMode
        AND     A2, A1, #0x0000001F ; Ensure that only mode bits are in A1
        AND     A1, A4, #0x0000001F ; Store mode on entry in R0/A1 to return it to callee
        BIC     A4, A4, #0x0000001F ; Clear Mode bits
        ORR     A4, A4, A2          ; Set Mode bits as in A2 (former A1)
        MSR     SPSR_cxsf, A4       ; Restore spsr
        B       _exit_svc           ; Branch to exit handler

_case2: ; switchToSystemMode
        ;BIC     A4, A4, #0x0000001F
        ORR     A4, A4, #0x0000001F ; Set bits fro System Mode (M0-M4 are set)
        MSR     SPSR_cxsf, A4       ; Restore spsr
        B       _exit_svc

_case3: ; switchToUserMode
        BIC     A4, A4, #0x0000001F ; Clear Mode bits
        ORR     A4, A4, #0x00000010 ; Set Mode Bits for User Mode
        MSR     SPSR_cxsf, A4       ; Restore spsr
        B       _exit_svc

_default:

_exit_svc:
        MOVS PC, LR              ; Return from Exception

        .endasmfunc

        .end

With the #defines added to a relevant include file:

#pragma SWI_ALIAS(unimplementedSVC,     0);
#pragma SWI_ALIAS(switchCpuMode,        1);
#pragma SWI_ALIAS(switchToSystemMode,   2);
#pragma SWI_ALIAS(switchToUserMode,     3);

void     unimplementedSVC(void); /* Used to test fault handler */
uint32_t switchCpuMode(uint32_t u32ModeNum);
void     switchToSystemMode(void);
void     switchToUserMode(void);

I verified that the mode switcher functions work by replicating the failures I was experiencing by not switching to SYSTEM mode when calling FEE driver routines. So I am of the opinion these work. Typical logic is as follows:

    TI_FeeModuleStatusType Status_l;

    switchToSystemMode();
    if(uni_cfg_tim_write && (IDLE == TI_Fee_GetStatus(0)))
    {
        uni_cfg_packdata(uni_cfg_blk3_params, UNI_CFG_NUMPARAMS_BLK3);
        TI_Fee_WriteSync(3,(uint8*)fee_databuffer);
        uni_cfg_tim_write = FALSE;
    }
    uni_cfg_unpackdata(uni_cfg_blk2_params, UNI_CFG_NUMPARAMS_BLK2);
    switchToUserMode();

The problem I am now seeing is that my RTI interrupts are being killed when I execute the writes. It would look like I get a spurious interrupt that is sending me to the undefEntry vector. Can you see an obvious problem with my assembler routines? I'll keep digging to try and understand the source of the undefEntry.

It appears that the application is hitting an undefined instruction as it is jumping to the undefEntry. Now from reading around the subject this is due to an ARM versus Thumb instruction being requested (see SPNA218 sec 2.2). Screenshot below of the SPSR_UND register, what are the best steps to working back to root cause? From what I can see the MCU is in ARM mode and also set to USER mode. Could this be an indication that an interrupt has moved us back from SYSTEM to USER mode? How best to avoid this - by disabling interrupts prior to running the FEE routines?