• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 1082 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SRAM ECC single bit interrupt on TMS470M

Ben W
Prodigy 30 points

I am attempting to trigger the ESM low interrupt when a SRAM single bit error occurs on a TMS470M06607.

In the eSRAM control register, I have ECC_ENABLE set to 0x0A, RMWCBPY also set to 0xA, SECINTEN set to 1.
RAMTHRESHOLD is set to 0x01. According to section 5.5.8.1 of the TRM, this should trigger SERR_INT, which is then connected to ESM channel 1.26.

In the ESM controller, ESMIESR1 is set to 0x4000040, to enable both the Flash ECC single bit interrupt (on channel 6) and the SRAM single bit interrupt on channel 26.
ESMILSR1 is set to 0x00 (all interrupts are low level, triggering IRQ2 on the VIM).

In the VIM, IRQ2 is enabled and triggers a ISR routine, which counts the number of flash and SRAM single bit errors.

All this works when I trigger a single-bit error in the Flash, using the -ecc:data_error parameter of the ARM linker.
A ESM interrupt is triggered on channel 6, which propagates through and my ISR is started.


I have a function to trigger an SRAM error, by disabling ECC, modifying a variable, re-enabling ECC and reading it back.
Whilst debugging this, I added code to clear RAMERRSTATUS (by writing 0x01) and read all the registers in case it is frozen, after disabling ECC, prior to re-enabling it.
This function causes RAMERRSTATUS (SECINTFLAG) in the eSRAM controller to change to 0x01, so the SECDED logic appears to be working.

However, no ESM interrupt is triggered.
There is no change to any of the ESM registers when SECINTFLAG changes to 1.

This setup should trigger a ESM low level interrupt via ESM channel 26.
Given the Flash ECC interrupt works and the SECINTFLAG is set in ESRAM, I'm at a loss as to what the problem could be.
It almost seems as if the SERR_INT output from the SRAM isn't connected to the ESM 1.26 input.

  • 0
    TI__Guru 68920 points
    Ben,

    Did you set SERR_EN: Table 5-5. TCRAM Module Interrupt Control Register (RAMINTCTRL) Field Descriptions
  • 0 in reply to Anthony F. Seely
    Prodigy 30 points

    There's no SERR_EN bit defined in the TMS470M TRM, I assume you mean SECINTEN - bit 0 of RAMINTCTRL.
    This is set to 1.

  • 0 in reply to Ben W
    TI__Guru 68920 points
    You're right I was looking at the low end TMS570 TRM instead of the TMS470M my mistake.

    Ok so looks like the name changed but same idea.

    So you have:

    RAMERRSTATUS bit SECINTFLAG = 1
    RAMINTCTRL bit SECINTEN = 1

    But you never see ESMSR1 bit 0x0400 0000 set?

    That seems unlikely.

    I need to check on something in the documentation because the bits all say 'RCP-X/0' in their type which to me indicates read/clear in privileged mode but the description is write '1' to clear so not sure which is correct.. (from experience on the TMS570 though it would be write1 to clear...)

    Is it possible you are setting both the flash and the SRAM error bits but then clearing both in the flash error handler?

    It seems unlikely that there would be a broken connection.
  • 0 in reply to Anthony F. Seely
    Prodigy 30 points

    That's correct.

    I have RAMTHRESHOLD set to 1, which should trigger the ESM interrupt handler after a single bit error. I have a function that triggers a SRAM error, and I see SECINTFLAG change to 1. ESMIESR1 is set with channel 26 enabled (for a single bit SRAM error). My ESM interrupt handler reads ESMIOFFLR and clears the relevant bit in ESMSR2 (by writing 1), but I'm not triggering the Flash error currently so channel 6 on the ESM remains at 0, never being triggered. I have a breakpoint on the ESM handler and the processor never enters it when I use the below code to trigger a SRAM error.

    For a flash error, this break-point is hit. There's a comment in the TRM (section 5.5.9) which says the interrupt is masked "during emulation when SUSPEND signal is high", but I believe this is only relevant when single-stepping. In any case, the behaviour is the same without the debugger connected.

    My code in the test function is:

    volatile uint32_t testVar = 0;

    volatile uint32_t readVar = 0;

    sramReg->RAMINTCTRL = 0x00; //Disable interrupt

    sramReg->RAMERRSTATUS = 0x01; // Clear SECINTFLAG

    sramReg->RAMOCCUR = 0x00;

    sramReg->RAMCTRL = 0xA05; /* Set ECC_ENABLE to 0x05, disabled. Set RMWCBPY to 0x0A (default value */

    asm(" dmb");

    testVar = 1; /* Write to variable with ECC disabled */

    asm (" dmb");

    /* Re-enable and force SRAM error */

    sramReg->RAMCTRL = 0xA0A; /* ECC_ENABLE to enabled, and RMWCPBY to 0xA -  default */

    sramReg->RAMTHRESHOLD = 0x01;

    sRamReg ->RAMINTCTRL = 0x01;

    asm(" dmb")

    readVar = testVar; /* Trigger a SRAM failure when it reads testVar */

    At this point, SECINTFLAG  changes to 1, but no ESM interrupt is triggered and ESMSR1 doesn't change. I added the dmb during debugging in case it was something to do with memory accesses not completing, but this  didn't seem to make any difference. A lot of this code is probably unnecessary, but I've been trying several different things to get the ESM interrupt to trigger without success.

  • 0 in reply to Ben W
    TI__Guru 68920 points
    Ok that's good to know. That sounds like a bug but I'll check with the team to see if there might be a reason.
    AFAIK though if you see SECINT 0->1 then you should see some change in ESMSR1... as they should just be 'wired' together.
    I didn't notice any silicon errata on this point ... could be something quirky in the device itself like an extra control reg though.
  • 0 in reply to Anthony F. Seely
    TI__Guru 68920 points
    Talked to a colleague but not really clear that this should happen..
    Is it possible for you to send your test code so we can reproduce here.
  • 0 in reply to Anthony F. Seely
    TI__Guru 68920 points

    Hmm.  I need to do something about this problem I have getting TMS470M confused with RM42.

    There is some information in the TMS470M Series TRM that may be applicable here:

    And

    So there are some additional checks.

    1) try to run *through* the code that tests the ECC single bit rather than step.   Stepping should be OK but the debug suspend signal is shown in the 1st diagram as gating off the ECC error interrupt generation so wouldn't hurt.

    2) more likely check ECC_ENABLE != 5  and RMWCBYP != 5 ...  as per the 2nd table pasted above.