STC self-test

Vaclav Cechticky

Other Parts Discussed in Thread: HALCOGEN

Hi,

I've recently updated the project code generated by HalCoGen 3.00.00 by code generated with HalCoGen 3.00.01. Since then I have difficulties with safety tests.

For example, the STC test is not working as specified. Before code update, the CPU was reset after the STC test finished and one could verify systemREG1->SYSESR for 0x20.

The code generated with HalCoGen 3.00.01 changes the behavior, after execution of the STC test, it comes data abort interrupt instead of reset interrupt.

The influence on this behavior has sys_core.asm generated by HalCoGen 3.00.01.

Regards Vaclav

over 13 years ago

0 Prathap over 13 years ago

TI__Genius 14205 points

Could you pls send the Code snippet? Have you found the source for the Data abort?. Since I do not know the options you selected, could you please compare the sys_core.asm generated by 3.00.00 and 3.00.01? To corner the issue can you try replacing only this file and see if the issue still exists?

Best Regards
Prathap

0 Vaclav Cechticky over 13 years ago in reply to Prathap

Intellectual 560 points

Hello Prathap,

Here are some code snippets that might clarify the reported issue:

1) code running the STC test

	Uint8 i = 0;

	/* clock rate for STC/LBIST = 80MHz when HCLK=160MHz
	 * 160 / 2 = 80 MHz */
	systemREG2->STCCLKDIV = 0x01000000;

	systemREG1->SYSESR = (1 << 5);

  	/* Select the Test interval for Max coverage, 32 Interval for 90.84 */
  	//stcREG->STCGCR0 = (24 << 16);
	stcREG->STCGCR0 = 0x00010001;

	// Enable comparator self-check and stuck-at-0 fault insertion in CPU, 0x1A
	stcREG->STCSCSCR = 0x1A;

  	/* Configure the SelfTest Run Time out counter pre-load Register */
  	stcREG->STCTPR = 0xFFFFFFFF;

  	// Wait for 16 VBUS clock cycles at least
	for (i=0; i<16; i++);

  	/** - Enable the STC Self Test */
  	stcREG->STCGCR1 = 0xA;

  	// Wait for 16 VBUS clock cycles at least
	for (i=0; i<16; i++);

  	/** - Enter ARM IDLE state to start the test  */
  	asm("	WFI");
        asm("	nop");
  	asm("	nop");
  	asm("	nop");

2) this shall lead to CPU reset, but first is executed void _data(void) in sys_data.c

3) when I reset the CPU, the first instruction is _coreEnableVfp_();

4) _coreEnableVfp_() is provided in sys_core.asm

5) the first instruction of _coreEnableVfp_() is executed stmfd sp!, {r0} and it comes

again to void _data(void) in sys_data.c

6) the steps 3) - 5) are running in endless loop

I'm attaching two sys_core.asm, one was generated with HalCoGen 3.00.00

the other one with HalCoGen 3.00.01. The effect I described above happens with the files

generated with HalCoGen 3.00.01.

Thank you

Regards

  Vaclav

1050.sys_core.zip

0 Prathap over 13 years ago in reply to Vaclav Cechticky

TI__Genius 14205 points

Hi Vaclav,

There is a change in the sys_startup.c as well in the version 3.00.01.
After reset the first function call will be _coreInitRegisters_(); which has the "_coreEnableVfp_()" routines inside.

The reason you were getting Data abort when "stmfd sp!, {r0}" because the stack would be corrupted after STC test, so it's adviced to call "_coreInitRegisters" before going further. This is an enhancement which was fixed in the version 3.00.01. In the version 3.00.00 "stmfd sp!, {r0}" was not present in the "_coreEnableVfp_()" so you would have not seen the issue.

Please use the latest files generated out of Version 3.00.01 ( especially sys_startup.c, system.c and sys_core.asm).

Best Regardss
Prathap

0 Vaclav Cechticky over 13 years ago in reply to Prathap

Intellectual 560 points

Hi Prathap

It works now. Thank you for providing us support.

To be frank, I'm a bit confused by this solution. Firstly, including enabling floating-point unit in the register initialization routine is something that I wouldn't expect. It does more now, than its name is saying. Secondly, there is not obvious compliance with the initialization sequence defined in SPNA106A, where the first step is "Enable the floating-point unit ...". Thirdly, it was for us a small change with unexpected consequences for us, I think that a change log shall be a part of every HalCoGen release, otherwise we won't be able to use this concept anymore, as the changes in background are for us difficult to investigate.

Thank you

Regards

Vaclav

Arm-based microcontrollers

Arm-based microcontrollers forum

STC self-test