RM48 Bootloader/Application with self tests enabled

Hi Heinz,

yes, we have the boot up self-test library supported, but don't know exactly all RM versions that it can support now.

I will forward your answer to the software library team and they can assist you soon.

Hi Heinz,

Just for clarification, bootloader-code? Are you talking about peripheral boot code which can be downloaded from ( http://processors.wiki.ti.com/index.php/RM48_HDK_Kit#HDK_BootLoader_Sample_Code) or just HALCoGen starup code not working when Safety fatures are enabled?

In HALCoGen if you have Enabled CPU Self Test or CCM Self Test as below, you cannot run in debug mode. So you program the device, Disconnect CCS, Hit reset to start running the code, Connect CCS you can see that your code would have passed all self test, startup and running your application.

Hi Prathap

 I’m using the bootloader “spna190.zip” as referenced inside the document “UART Bootloader for Hercules RM48x MCU” (SPNA190–September 2013), to be found on the RM48L952 home page (http://www.ti.com/product/rm48l952, section “Application Notes”). For my application I’m using startup code as generated by HALCoGen V3.06 with CPU tests enabled. I know that I cannot run the code with the debugger attached. I’m using GIO outputs to get error state information. It would be very helpful for me to have a demo-application (running on the evaluation board) with self-tests enabled.

 Thanks

 

Heinz

Hello Heinz,

Did you succeed to resolve your problem?

We have the same issue with RM46 device on TMDXRM46HDK evaluation board.
We use UART bootloader provided by Texas Instrument. T his bootloader is used to download our personal application software which startup code are generated by Halcogen.
When we disable self-test function (from SAFETY tab of Halcogen), everything works fine. But if we activated its, then we have many problem:
- Apparently, the self-test found an error about ESM group 3 and the application gets stuck.
- If we comment this ESM group 3 test, then the application go to "Undefined Instruction Interrupt" vector because of Self-test.

For information, we have generate another configuration of our personal Application which not use bootloader (source are identical, just the linker file have been changed) and in this case the Application works fine even if self-test are enabled.

Thanks,
Mathieu

Hi Mathieu,

Questions
1) What all Safety Functions you have to disable to make it work? Can you e-mail the HALCoGen project ( .dil and hcg files).
2) If I understand your Flow, you have the boot loader loaded to Micro, started the boot loader, downloaded your image, branch to application, when executing the application with self test you get the ESM error. CPU self test will generate Reset, What procedure you have in place to come back to application startup not using the boot loaders startup?
3) Did you customize the TI UART boot loader, meaning did you change the sys_startup.c of the boot loader application?

Hello Prathap,

Thanks for your fast response.

Response:

1) The following picture show the safety tab when application works fine

and the following one, when application failed (red rectangle show difference between the two picture).

More over in sys_startup.c file of application (generated by Halcogen), application works only if we disable esmREG->SR1[2] test.

if ((esmREG->SR1[2]) != 0U)
{
         /* USER CODE BEGIN (24) */
#if0
        /* USER CODE END */
        /*SAFETYMCUSW 5 C MR:NA <APPROVED> "for(;;) can be removed by adding "# if 0" and "# endif" in the user codes above and below" */
        /*SAFETYMCUSW 26 S MR:NA <APPROVED> "for(;;) can be removed by adding "# if 0" and "# endif" in the user codes above and below" */
        /*SAFETYMCUSW 28 D MR:NA <APPROVED> "for(;;) can be removed by adding "# if 0" and "# endif" in the user codes above and below" */
        for(;;)
        {
        }/* Wait */                 
       /* USER CODE BEGIN (25) */
#endif
        /* USER CODE END */
}

We attach our halcogen to this response(through insert file functionnality)

2) This is our flow:

a) Bootloader is loaded to micro, we download our application with self-test option (picture 2) and with esmREG->SR1[2] test.

Then we branch to application ==> application get stuck into infinite loop for(;;) due to esmREG->SR1[2] test.

b) Bootloader is loaded to micro, we download our application with self-test option (picture 2) but  without esmREG->SR1[2] test  (see below)

Then we branch to application ==> seft test generate "Undefined Instruction Interrupt" vector.

c) Bootloader is loaded to micro, we download our application without self-test option (picture 1) and without esmREG->SR1[2] test  (see below)

Then we branch to application ==> Our application works fine.

3) No, we did not customize sys_startup.c file of UART bootloader

I hope my explanation are clear.

THanks for your help,

Mathieu

8306.Mech_Halcogen_project.zip

 

 

Hi Mathieu,

The pics are not attached in your message. Please attach it again.

One more , please share following files

1) The linker command and sys_startup.c file of UART boot loader.

2) The linker command and sys_startup.c file of your Application.

3) Whats the value of esmREG->SR1[2] during the failure case.

Hello Prathap,

Sorry for pictures, I made a copy/paste but that didn't works.

So, the following picture show the safety tab when application works fine

and the following one, when application failed (red rectangle show difference between the two picture).

More over here is the response to your questions:

1)  startup_and_linker zipper files contains:

- link_release_bootloader is the linker command file of bootloader.

- sys_startup_bootloader.c is the startup file of bootlaoder.

2)  startup_and_linker zipper files contains too:

- link_release_application is the linker command file of application. Linker file of application and bootloader are similar, only one preprocessor define is different.

- sys_startup___works.c is startup file when application run correctly(startup generate by halcogen with configuration of picture 1 + code modification of previous post)

- sys_startup___not_works.c startup file when application run correctly(startup generate by halcogen with configuration of picture 2)

3) esmREG->SR1[2] seems to be equal to 0x00000008.

I hope all is clear for you.

Thanks for your Help,

Mathieu

4428.startup_and_linker.zip

Hi Mathieu,

I believe it's an ECC issue. 

Try enabling RAM ECC in the bootloader startup file... You need to add the API's highlighted in red after systemInit() API call in startup file.

#######################################################

/* Initialize System - Clock, Flash settings with Efuse self check */

systemInit();

/* Initialize CPU RAM.
* This function uses the system module's hardware for auto-initialization of memories and their
* associated protection schemes. The CPU RAM is initialized by setting bit 0 of the MSIENA register.
* Hence the value 0x1 passed to the function.
* This function will initialize the entire CPU RAM and the corresponding ECC locations.
*/
memoryInit(0x1U);

/* Enable ECC checking for TCRAM accesses.
* This function enables the CPU's ECC logic for accesses to B0TCM and B1TCM.
*/
_coreEnableRamEcc_();

/* Enable IRQ offset via Vic controller */
_coreEnableIrqVicOffset_();

#######################################################

One more thing I noticed from your linker command file is you have application specific vector table, since I do not have the intvecs copy, I assume you have used right symbols mapped in the boot loader intvecs.asm file to point to Application vector table in case of interrupts like Abort , UDEF, Reset etc. during application.

Hi Prathap,

Thanks for your advice but we add memoryInit(0x1U) and _coreEnableRamEcc_() but that change nothing.

Application works fine only if we disable self-test.

About the second point, I am not sure that we have correctly configured vector table of application. I supposed " __TI_auto_init " fonction (called in sys_startup of application) initialize its automatically. Is it wrong?

Moreover we used IRQ in our application code and its work fine, so vector table of application have to be correctly initialize. Is it wrong?

Do you think that could be linked to our problem about self-test?

 

PS : We tried to load application at 0x00000000 address with NowFlashWin to start application immediately and that works fine even if self-test are enabled.

Thanks,

Mathieu

Hi Mathieu,

1) I suspected ECC issue because esmREG->SR1[2] = 0x00000008, which is a RAM double bit error. Do you get this error even with enabled ECC in bootloader code?

2) "Enable ESRAM ECC Check" will add checkRAMECC(); to sys_startup.c file. The details of the function is given below. So there will be a deliberate data abort caused which requires _dabort function in dabort.asm.. In your case since the booloader's intvecs is loaded to address 0, which does not have branch to _dabort routine at data abort since it is part of application code. Either you remove Enable ESRAM ECC Check from application or find a way to branch to _dabort during data abort.

/* Test the CPU ECC mechanism for RAM accesses.
* The checkBxRAMECC functions cause deliberate single-bit and double-bit errors in TCRAM accesses
* by corrupting 1 or 2 bits in the ECC. Reading from the TCRAM location with a 2-bit error
* in the ECC causes a data abort exception. The data abort handler is written to look for
* deliberately caused exception and to return the code execution to the instruction
* following the one that caused the abort.
*/

Hi Prathap,

Thanks a lot for your help,

1) No we don't get this error when we enabled ECC in bootloader code

2) Effectively, we have error about exception interrupt of application, because bootloader’s intvecs (loaded at 0x0, 0x4, address) don't jump to corresponding routine of application. When an exception occurs in application, the code goes to bootloader's intvecs and stuck here.

We supposed "__TI_auto_init" make automatically link between hardware exception (based in 0x0) and application exception routine, but apparently this function initialize only C environments.

We wiil modify our bootloader exception routine to jump to application routine.

 

Thank you,

Mathieu

Excellent!! 

Hopefully you got the code working. Let me know if you need any help.