• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 30 subscribers
  • Views 1523 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.

RM46 PBIST endless loop when enabling PBIST Self Test

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

I am trying to port the Hercules Functional Safety demo to the RM46 + Educational BoosterPack

I'm using the test cases from the project that's installed when you run the Hercules Safety MCU Demo installer (Hercules\Hercules Safety MCU Demos\4.0.0\RM46x_target_sources)

I have the following issue when entering the PBIST test:

These two calls, implemented in function pbistInit() in file demo-app\source\pbist.c throw me in the error loop of dabort.asm.or sys_intvectors.asm

	/*Enable PBIST Memory Init MSI register*/
	systemREG1->MSINENA = 1U; // my code loops in dabort.asm
	
	/*Enable PBIST self test*/
	systemREG1->MSTGCR = 0x0A; // my code loops in sys_intvectors.asm

  • 0
    TI__Guru 68920 points
    Thanks Jan, I'll look into this.
    In the meantime, when you hit the data abort, the value in LR is 8 past the instruction that caused the exception.
    If you look at LR, then subtract 8 -- what's the disassembly at this instruction and just before?
    You could then run from a system reset again with a breakpoint set at this address, and examine what it's about to do..
    before it does the operation that causes the abort. There may be a bad value in a register that it's about to derefeference
    and you could see it that way.

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

    I will check this. I'll also check what happens if I start from a fresh clean project?

    The one I'm running now is a freeRTOS one, and i had to extend KERNEL memory (the .cinit part is too small in a HALCoGen FreeRTOS project if you enable GIO, mibSPI and ADC).

    Here's how I extended the KERNEL part:
    The part that I added at the end of KERNEL, I took from the start of FLASH0. Maybe that's a no-no.

    /* USER CODE BEGIN (1) */

/* jc 20160501 making more room for .cinit in Kernel */
#if 0
/* USER CODE END */

/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */

MEMORY
{
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    KERNEL  (RX) : origin=0x00000020 length=0x00008000 
    FLASH0  (RX) : origin=0x00008020 length=0x00137FE0
    STACKS  (RW) : origin=0x08000000 length=0x00000800
    KRAM    (RW) : origin=0x08000800 length=0x00000800
    RAM     (RW) : origin=(0x08000800+0x00000800) length=(0x0002f800 - 0x00000800)
    
/* USER CODE BEGIN (2) */
#endif


MEMORY
{
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    KERNEL  (RX) : origin=0x00000020 length=0x0000A000
    FLASH0  (RX) : origin=0x0000A9020 length=0x00117FE0
    STACKS  (RW) : origin=0x08000000 length=0x00000800
    KRAM    (RW) : origin=0x08000800 length=0x00000800
    RAM     (RW) : origin=(0x08000800+0x00000800) length=(0x0002F800 - 0x00000800)


/* USER CODE END */
}

    4621.pbist.zip

  • 0 in reply to Jan Cumps
    Guru 15740 points

    LR: 0x000CBD70

    -8 = 0x000CBD68

             pbistInit():

    000cbd58:   E24DD008            sub        sp, sp, #8

    000cbd5c:   E58D0000            str        r0, [sp]

    47       systemREG1->MSINENA = 1U;

    000cbd60:   E3E0009F            mvn        r0, #0x9f

    000cbd64:   E3A0C001            mov        r12, #1

    000cbd68:   E580C000            str        r12, [r0]

    And that line matches with the location of my code when stepping trough it:
    In the zip I attached in the previous post here,
    pbist.c line 47:

    void pbistInit(unsigned int RAM_GRP_SEL)
{
	/*Enable PBIST Memory Init MSI register*/
	systemREG1->MSINENA = 1U;  // JUST AFTER THIS LINE //////////////////////////
	
	/*Enable PBIST self test*/
	systemREG1->MSTGCR = 0x0A;

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

    Heads-up:

    the code runs fine in a fresh HALCoGen project without freeRTOS.

    I'm now proceeding to try it in a fresh project with freeRTOS, but with the default link file...

  • 0 in reply to Jan Cumps
    Guru 15740 points
    It also works fine when I run a clean RTOS project, and also with one that has the linker file that I modified.
    I'll go back now to my original project, and disable as much of the functionality I can until this works.
    Then I'll re-introduce functionality and see where it stops working..
  • 0 in reply to Jan Cumps
    Guru 15740 points

    I narrowed it down to this:

    If I call the PBIST self test from within an RTOS task, it fails.

    If I call the PBIST self test in the main function (regardless if RTOS is involved or not) it works.

    I've attached a minimal project,
    with in sys_main.c a call to PBIST in main() line 83 and in a RTOS thread() line 98. 

    the one on line 83 works, the one on line 98 doesn't.
    Do I have to elevate the RTOS task to a higher level?

    8546.RM46_PBIST_RTOS.zip

  • 0 in reply to Jan Cumps
    TI__Guru 68920 points
    Hi Jan,

    So yes this is an issue of not having Privilege.

    if (xTaskCreate(vTask,"Task", configMINIMAL_STACK_SIZE, NULL, 1, 0) != pdTRUE)

    creates a task in User mode.

    You want to use www.freertos.org/xTaskCreateRestricted.html
    instead when your task is one that modifies hardware registers that are protected by "Priv".
    This should make the task execute in System Mode (User Mode + Privilege) instead of User Mode.

    That much said, you need to be very careful of which PBIST tests you run from this task.
    All the task control blocks are stored in SRAM and if you run PBIST on the ESRAM you'll corrupt the RTOS.

    So just for demo purposes you can run PBIST on the other memories or on an ESRAM block that you
    are not using - but trying to run PBIST at runtime within a 'live' app on memory the app is using is a
    difficult problem. Not really anything technically challenging per-se but you need to have a scheme
    in place to save & restore the SRAM contents for the bank of ESRAM that is being tested. And this is all code that really needs to be hand crafted probably in assembly to be safe. Also means interrupts probably need to be disabled for at least some time.

    Someone designing a system w. PBIST needs to consider PBIST v.s. ECC very carefully.

    You could argue that PBIST is best used at boot and maybe when some count of ECC errors is too high. If the application is on 24x7 then it may be necessary at some longer term interval to run PBIST periodically but if it could be done via a 'warm start' (reboot the application) that may arguably be a lot simpler than trying to PBIST while the application is live. PBIST is very quick so such a warm boot could probably be 'hidden'.

    PBIST is there to catch latent defects in the RAM - and it's for hard failures which don't occur as frequently as soft errors. But the advantage it has is it can test the RAM to make sure it's good before any tasks with functional safety requirements are even started.

    ECC on the other hand is minimally intrusive and always online. But it only detects failures in memory used by the application (checked during each access). It is great for soft errors because it's online and because single bit soft errors (almost all soft errors are single bit) can be automatically corrected.

    Thanks and Best Regards
    -Anthony
  • 0 in reply to Anthony F. Seely
    Guru 15740 points
    I'll resolve this for the moment by running the self-test at startup.
    My PBIST check can then show the cashed outcome of the test, success or failure.
    I can always bring the PBIST test inside the RTOS when I have a deeper understanding of the effects.

    Thanks for the help.
  • 0 in reply to Jan Cumps
    TI__Guru 68920 points
    Hi Jan,

    Yes I think this is the best approach.

    You could get past the problem you are stuck at now with xTaskCreateRestricted() but if you then try PBIST on the ESRAM you'll immediately hit the second problem.

    For a demo - I'd suggest if you want to run PBIST with the application live, run it on a RAM that's not in use like one of the DCAN RAMs or HET RAM.. (whatever your application *isn't* using). May be silly to do so but at least it can show PBIST running without losing the nice Graphical Display that you have.