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.

Simulating 1-bit ECC error in F035 flash module

Other Parts Discussed in Thread: TMS570LS20216, NOWECC

Hi,

I am trying to simulate a 1-bit ECC error in the flash memory of a TMS570LS20216 board but I am not succeeding; I am using IAR 6.30 to create the object file (pseudoACBappCode.out) which is compiled from C++ as part of smxRTOS. Then I use nowECC v2.17 with the following line:

>nowecc -i pseudoACBappCode.out -o pseudoACBappCode_ECC.out -r4 -f035 -s1 0x90000 2

so that I can create a 1-bit error at bit 2 of the data word located at address 0x90000.

With these two available object files, I use nowFlash v3.41 (along with an XDS100v2 emulator) to program both pseudoACBappCode.out and pseudoACBappCode_ECC.out. This pseudo application code resides in Bank 1 of the flash, and fills the first sector (it resides in the address range 0x80000-0x9FFFF), and so its ECC code is programmed in its corresponding address range (0x440000-0x44FFFF).

My pseudo application code is meant to enable the ECC checking in Flash (EDACEN = 0xA), and in the CPU (which is explained in the TRM, document spnu489c, section 8.5.3.3 ). Then it enables the interrupt by setting EZFEN (bit 9) of the FEDACCTRL1 register. After this code setup, I make a pointer that reads address 0x90000 in an infinite loop, which should in theory kickstart an interrupt that increments a counter, and, after every time I read the misbehaving address, I send the interrupt counter serially so that I can read it in TeraTerm. I am doing this test because I read in section 8.5.3.9 of the TRM, that in JTAG debug mode, the interrupt won't be generated if a correctable error is encountered, and I would like to implement an interrupt that updates information if a 1-bit error occurs.

While I am receiving data serially, i.e. I get the counter value, I see that the counter does not get incremented and it always remains at 0.

So, am I meant to use nowFlash and nowECC differently? How am I meant to simulate a 1-bit ECC error on this board?

Any help would be appreciated,

-Juan Martinez

  • Hello Juan,

    before trying to get the interrupts to work, I'd recommend the following:

    did you check that the SBE FLG bit in FEDACSTATUS is set for the single bit error? You may set the SUSP_IGNR bit in FEDACCTRL1 to see this bit getting set also when working with the JTAG debugger.

    Regarding the interrupt, then the next step is to check if the interrupt is flagged in the VIM and also if interrupts are enabled at the VIM and CPU level.

    Best regards

    Andreas

     

    If a post answers your question, please mark it with the "verify answer" button.

  • Hi Andreas,

    I have good news and bad news

    Good news:

    Thank you for your suggestions. I checked SBE_FLG, and it was set; I tried testing with SUSP_IGNR but either value I gave it would not make a difference; the VIM and the ESM both flagged the interrupt/error... but I had not enabled the interrupt in the VIM by asserting bit 20 in REQENASET0. Once I enabled the VIM interrupt, it worked... sort of.

    Bad news:

    I read the variable from address 0x90000 and the interrupt ran once, and so the counter is incremented to 1. Then the interrupt does not run anymore, even though I read the address again in the next loop iteration.

    Is there something I'm missing?

    Is this related to the thread called "RAM ECC Questions" and located at http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/111043/392799.aspx#392799 ? If you check Pratip Kumar's response on 2 Jun 2011 8:11 AM, he mentions that a correctable ECC error is corrected and stored in an internal buffer. So, is this internal buffer also at play even though the ECC error occurs in the flash memory module as opposed to RAM?

    Thank you so much for your help,

    Juan


  • Hello Juan,

    good to hear that your were able to make some progress on this.
    Which steps are you taking in your interrupt service routine? As far as I can see the follwowing steps should be done:

    - clear the single bit error flag (SBE FLG) by writing a '1' to it
    - read FCOR_ERR_ADD
    - clear the corresponding error in the ESM

    Best regards

    Andreas

     

    If a post answers your question, please mark it with the "verify answer" button.

  • Hi Andreas,

    In my interrupt I am

    1) Clearing SBE_FLG by writing a '1' to it

    2) Clearing ESMSR1 bit 6 by writing a '1' to it (this is the "Flash (ATCM) - correctable error" ESM flag according to document spns141f)

    3) Incrementing my counter

    4) I wasn't reading FCOR_ERR_ADD before, but now I am, and it did not make a difference (it does read the correct address though).

    Any ideas?

    -Juan

  • Hi Juan,

    can you check at the end of the ISR that the corresponding interrupt pending flag in the VIM  is cleared (INTREQx) ? It should be cleared, however if not then we need to find out why this is the case. Have you eventually enabled in the ESM other error sources going to the low level interrupt of the ESM ?

    Also it would be useful to check each of the steps above by reading the registers back or checking in the debugger that the clearing has worked as expected.
    Have you put a breakpoint in your ISR to check that this really called only once ?

    Not sure what is really happening in your case, just collecting some debugging ideas...

    Best regards

    Andreas

     

    If a post answers your question, please mark it with the "verify answer" button.

  • Hi Juan,

    a colleague just pointed out to me, that the explanation of the behaviour which your are seeing, is in fact really related to the same mechanism as described in the thread about RAM ECC which you had mentioned above: http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/111043/392799.aspx#392799

    Best regards

    Andreas

     

     

    If a post answers your question, please mark it with the "verify answer" button.