How to create ADC RAM parity error?

One year old, maybe not tracked anymore so I better start a new thread ...

Chuck,

HALCoGen generates the code you need to test the parity checking mechanism for the ADC RAM. The sequence is as follows:

• Initialize the ADC RAM using the system module memory auto-init hardware
• Set the parity test enable bit and enable parity checking
  • Note that this is different from the RAM_TEST_EN field of the ADC operating mode control register. That field is used to allow the CPU to directly write to the ADC RAM.
• Now the ADC RAM's parity bits are also memory-mapped.
• Flip one bit in the parity bits for one (or more) ADC RAM location.
• Clear the parity test enable bit.
• Read from the ADC RAM location with the corrupted parity bit.
• You should see a parity error reported to the ESM now.
• You may want to restore the parity bits for the location that you corrupted, or wait for the ADC to write new conversion results at this location before reading it again.

Thank you Sunil,

Yes I already enabled the ADC1 parity check and used the global HW initilization to initialize the ADC1 RAM. So now I am using this code and thinking that since my ADC1 is used to sample channels 0, 1, 2, 3 and 4 every 200 ms, an error will be declared sooner or later, but it didn't:

        AD1OPMODECR_bit.RAM_TEST_EN = 1;                // enable ADC1 results RAM access
        *((volatile int *) 0xFF3E0000) = 0xFFFFFFFF;    // write to beginning of ADC1 results RAM
        AD1OPMODECR_bit.RAM_TEST_EN = 0;                // disable ADC1 results RAM access

        AD1PARCR_bit.TEST = 1;                          // enable ADC1 parity RAM remapping
        *((volatile int *) 0xFF3E1000) = 0xFFFFFFFF;    // write to beginning of ADC1 parity RAM
        AD1PARCR_bit.TEST = 0;                          // disable ADC1 parity RAM remapping

EDITED: Then I read back the ADC1 results RAM:

        u32 dummy = *((volatile int *) 0xFF3E0000);

Anything you see wrong?

Sunil,

Since I'm sampling only 5 channels every 200 ms, and please correct me if I'm wrong, I'm sure that the ADC will not do anything at the beginning of the 200 ms before the conversions are triggered (or at the ending of the cycle, depends how you see it), my code to create the parity error + read back should not be interrupted by the ADC, which should take only a couple of nano-seconds.

So I'm kind of skeptical ... Do you recommend disabling the ADC before carrying out this test?

Could it be the way I write and read to/from address not right?

Thanks.

Chuck,

Yes, please test the ADC RAM parity error checking/reporting mechanism before enabling the ADC. This is the recommendation for all other diagnostic mechanisms as well.

Regards, Sunil

Sunil,

I'm despaired ... I've must missed something in my procedure but could figure out what. Below is what I've done ... why it couldn't work as intended?

I've the AD1PARCR=0x0000000A to enable parity checking. After setting bit TEST=1 below, the register content is 0x0000010A. ADC1 RAM has previously been "HW Auto-Init" after enabling the PARITY_ENA=1 instruction ...

              AD1OPMODECR_bit.ADC_EN = 0;                     // disable channel-select registers

        AD1PARCR_bit.TEST = 1;                          // enable ADC1 parity RAM remapping
        *((volatile int *) 0xFF3E1000) = 0xFFFFFFFF;    // write to beginning of ADC1 parity RAM
        AD1PARCR_bit.TEST = 0;                          // disable ADC1 parity RAM remapping

        u32 dummy = *((volatile int *) 0xFF3E0000);     // ADC1 parity error should be declared here
        AD1OPMODECR_bit.ADC_EN = 1;                     // enable channel-select registers

Am I writing and reading the right memory addresses?

Please help.

Sunil,

Just add additional info: I put a breakpoint into my code listed above, and when I write 0xFFFFFFFF to ADC parity RAM 0xFF3E1000, its contents changed from "00 00 00 00" to "00 00 00 01" every time; then when I read back ADC results RAM at 0xFF3E0000, no error is generated via ESM low-level interrupt.

Chuck.

Chuck,

The parity check mechanism uses the odd-parity scheme by default. There is a single parity check bit implemented for 16 bits of data in case of the ADC RAM. This bit will be 1 after the auto-initialization of the ADC RAM to all zeros. You are also writing all F's to the parity bit location, so you are not really changing the parity bit.

You can use the code generated by HALCoGen as a reference even if you don't want to use it as-is. You should flip the parity bit so that the test procedure works regardless of the parity scheme being used. The code generated by HALCoGen is as follows:

void adc1ParityCheck(void)
{
volatile uint32 adcramread = 0U;

/* Set the TEST bit in the PARCR and enable parity checking */
adcREG1->PARCR = 0x10AU;

/* Invert the parity bits inside the ADC1 RAM's first location */
adcPARRAM1 = ~(adcPARRAM1);

/* clear the TEST bit */
adcREG1->PARCR = 0x00AU;

/* This read is expected to trigger a parity error */
adcramread = adcRAM1;

/* Check for ESM group1 channel 19 to be flagged */
if ((!(esmREG->ESTATUS1[0U] & 0x80000U)) !=0U)
{
    /* no ADC1 RAM parity error was flagged to ESM */
    /* Need custom routine to handle this failure instead of the infinite loop */
    /* for(;;) can be removed by adding "# if 0" and "# endif" in the user codes above and below */
    for(;;);
}
else
{
    /* clear ADC1 RAM parity error flag */
    esmREG->ESTATUS1[0U] = 0x80000U;

    /* Set the TEST bit in the PARCR and enable parity checking */
    adcREG1->PARCR = 0x10AU;

    /* Revert back the parity bits to correct data */
    adcPARRAM1 = ~(adcPARRAM1);

    /* clear the TEST bit */
    adcREG1->PARCR = 0x00AU;
}   // end if
}   // end adc1ParityCheck()

Regards, Sunil

Hi Sunil,

You see, only human make mistake, machine never did. I mishandled the ESM low-level ISR because of a copy-and-paste problem, using mistakenly a variable from the ESM high-level ISR ... bla bla bla. My procedure to trigger the parity error was near-correct, except the "~" thing, and if my ESM ISR was well implemented, I would have see the parity error when I keyed-in manually the changes to the memory address. The bottom line is: my mistake and I'm sorry for wasting your time.

However, correction to my ISR has revealed other info provided by TI support that has misled me regarding parity vs HW memory initialization. I will report my finding on that thread.

Thank you very much for your support.

Chuck.