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.

RM42L432: RM42L432

Part Number: RM42L432

Hi Everyone,

I am testing the VIM parity check on RM42L432 with the following code. The parity check result can pass a few times(ESM channel 15 is flagged), but after a hundreds times, the ESM channel 15 can not be flagged.

And I also found that the interrupt may be effected by the VIM parity check if the VIMRAMLOC  is set to 0xFFF82000 although the 0xFFF82000  is related to a Phantom Vector!

Help!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

#define VIMRAMPARLOC (*(volatile uint32 *)0xFFF82578U)
#define VIMRAMLOC (*(volatile uint32 *)0xFFF82178U)

void vimParityCheck(void)
{
volatile uint32 vimramread = 0U;
uint32 vimparctl_bk = VIM_PARCTL;

/* USER CODE BEGIN (49) */
/* USER CODE END */

/* Enable parity checking and parity test mode */
VIM_PARCTL = 0x0000010AU;

/* flip a bit in the VIM RAM parity location */
VIMRAMPARLOC ^= 0x1U;

/* disable parity test mode */
VIM_PARCTL = 0x0000000AU;

/* cause parity error */
vimramread = VIMRAMLOC;

/* check if ESM group1 channel 15 is flagged */
if ((esmREG->SR1[0U] & 0x8000U) ==0U)
{
/* VIM RAM parity error was not flagged to ESM. */
selftestFailNotification(VIMPARITYCHECK_FAIL1);
vRedunLedOn(); /*LED indicator*/
}
else
{
/* clear VIM RAM parity error flag in VIM */
VIM_PARFLG = 0x1U;

/* clear ESM group1 channel 15 flag */
esmREG->SR1[0U] = 0x8000U;

/* Enable parity checking and parity test mode */
VIM_PARCTL = 0x0000010AU;

/* Revert back to correct data, flip bit 0 of the parity location */
VIMRAMPARLOC ^= 0x1U;
}

/* Restore Parity Control register */
VIM_PARCTL = vimparctl_bk;

/* USER CODE BEGIN (50) */
/* USER CODE END */
}

  • Hello Geng,

    I will need to investigate this and get back with you on it. On the surface, I don't have an explanation of the behavior.
  • Hello Geng,

    I apologize for the delay in answering this post, my intention was to address it earlier this week once I had some time to set it up on my bench and do some further testing. Since then, Hurricane Harvey and the subsequent flooding has led to a lot of devastation in the Houston area and I have been unable to go to work.

    In light of this, I can only offer some suggestions at this time until I have an opportunity to fully examine this behavior on a bench. My first suggestion is to add a couple of NOPs after the error location is read and before the check of the ESM flag. This may give some additional time for the error notification to make it to the ESM and for the flag to be set.

    In regard to the issue related to the phantom interrupt location, how is the interrupt being impacted? i.e., is it not occurring or is it being set when it shouldn't, etc. Also, what is the content of the phantom interrupt vector? What is it pointing to?