• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 717 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.

Safety Demo on TMS570LS04x launchpad: NHET parity error triggered at unexpected line of code

Jan Cumps
Guru 15740 points
Other Parts Discussed in Thread: NOWECC, HALCOGEN

I'm investigating the Hercules Safety Demo code. When I checked the HET parity error, the parity error occured on an unexpected line of code.

The error is generated in the file nhet.c , in the function void NHET_Parity(void):

The error is thrown at this line:

/** Enable NHET Parity */
nhetREG->HETPCR = 0x0000000A;


I was expecting it to happen here:

/** Corrupt the Parity RAM location to introduce a * Single bit error */
RAMBASE = (unsigned int *) (nhetMEM+0x2000) ;
*RAMBASE =~(*RAMBASE);

because it is only at that point that the memory inconsistency is introduced?

/** @fn void NHET_Parity(void)
*   @brief NHET RAM Parity Error creation and check routines.
*/
void NHET_Parity(void)
{
	unsigned int temp;
	unsigned int *RAMBASE = (unsigned int *)nhetMEM;

	/** Enable NHET Parity */
	nhetREG->HETPCR = 0x0000000A; // this is where the error is occuring
	
	/** Fill NHET RAM with known Pattern 
	 *  The Parity Gets updated while filling the RAM */	
	for (temp=0;temp<0x080;temp++)
	{
		*RAMBASE = 0xA5A5A5A5;
		RAMBASE++;
	}
	
	/** Enable access to parity RAM */
	nhetREG->HETPCR |= 0x00000100;
	
	/** Corrupt the Parity RAM location to introduce a 
	 *  Single bit error */
	RAMBASE = (unsigned int *) (nhetMEM+0x2000) ;
	*RAMBASE =~(*RAMBASE); // this is where I was expecting it to occur

  • 0
    TI__Guru 68930 points

    Jan,

    Could you have run your code before, left a parity error in the HET RAM, and not gone through or skipped the RAM initialization the next time resulting in the behavior you see above?

    If you start from a Reset->CPU Reset and Reset->System Reset and try again, do you see the same behavior?

     

  • 0 in reply to Anthony F. Seely
    Guru 15740 points

    I'll check. The code in the  demo application does a restore to normal and a new hetInit, so I was not expecting this behaviour.

    	/* Undo the corruption */

	/** Enable access to parity RAM */
	nhetREG->HETPCR |= 0x00000100;

	*RAMBASE =~(*RAMBASE);

	/** Disable HTU RAM Parity */
	nhetREG->HETPCR = 0x00000005;

	hetInit();

	/** Turn off all PWM channels */
	hetREG1->DIR   	= 0xAA178035;
	hetREG1->DOUT   	= 0x08110034;

	pwmStop(hetRAM1,pwm0);
	pwmStop(hetRAM1,pwm1);
	pwmStop(hetRAM1,pwm2);
	pwmStop(hetRAM1,pwm3);
	pwmStop(hetRAM1,pwm4);
	pwmStop(hetRAM1,pwm5);
}

  • 0 in reply to Jan Cumps
    Guru 15740 points

    I have retested this with a freshly started PC and a powered-off and resetted LaunchPad.

    I'm using the source from the Hercules Safety Demo, 
    from subdir "Hercules Safety MCU Demos\TMS570LS04x_target_sources".

    Version of the safety demo : 3.2.0; the latest available on the TI download page.

    (the source manifest pdf file in "Hercules Safety MCU Demos\TMS570LS04x_target_sources". says it is 3.02.00, but it is installed by the latest installer downloaded from ti)

    I imported that project in CCSv5, left all settings as default (including full memory erase), only corrected the path to nowecc so that it points to the right location on my pc.

    Did a full rebuild, and put a breakpoint on line nhet.c line 23.

    	nhetREG->HETPCR = 0x0000000A;

    I started the program, and launched the "Hercules Safety MCU Demos" program from the windows start menu.
    Selected the Safety Features button
    Clicked the NHET parity error button.

    The program breaks on line 32.

    The EMS led goes red when I step over that line of code.

    Edit:

    > If you start from a Reset->CPU Reset and Reset->System Reset and try again, do you see the same behavior?

    Yes, same behavior.

  • 0 in reply to Jan Cumps
    Guru 15740 points

    I tried to run the code of void NHET_Parity(void) outside the demo application and see the same behaviour (had to adapt some things to the naming convention of the HALCoGen generated reg-het.h file).

  • 0 in reply to Jan Cumps
    TI__Mastermind 49120 points

    Jan,

    The NHET module requires parity checking to be enabled for the parity memory to be initialized along with the code written to the NHET RAM.

    Refer to this forum post: http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/317176/1104240.aspx#1104240

    In your hetInit() routine, you can turn ON the parity check on the NHET RAM before copying the NHET program to the NHET RAM. This will initialize the NHET parity RAM as well along with the NHET program memory.

    Even the code generated by HALCoGen is not correct in this regard. The parity check needs to be enabled inside a module before the associated memory is initialized using the hardware auto-initialization mechanism.

    Please try this out and let us know the results. We will update the documentation as well as the start-up code generated by HALCoGen to match this requirement.

    Regards, Sunil