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.

AWR1843AOP: L3 memory acyclic zero initialization problem

HI. TI

As the application size increases while using 1843AOP,

It has become impossible to store data using only R4F's TCMB (ori:0x0800_0000, len:0x0002_FFFF) Data RAM.

Therefore, an exception occurs after moving the statically allocated .bss (global variables) area to L3 memory.

There is some randomness in the occurrence cycle, but it generally occurs within 3 seconds after successfully executing the sensorStart command.

As a result of debugging in the EVM kit environment through *.map files and CCS Memory Viewer,

we confirmed that all .bss areas moved to L3 were initialized to 0 when abort() occurred.

before abort() occurs :

after abort() occurs: (frame count : 17)

(1) https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1020429/failed-to-access-awr1843-l3-ram/3778097?tisearch=e2e-sitesearch&keymatch=SHMEMBANKSEL#3778097

(2) https://www.ti.com/lit/ug/swru520e/swru520e.pdf?ts=1712213767734#page=1548

(3) https://www.ti.com/lit/ug/swru520e/swru520e.pdf?ts=1712213767734#page=1136

By referring to the links above, I found out that it may be related to the 'SHMEMBANKSEL' register.

Related code to set TOPRCMRegs(MSS_TOPRCM) appears to be in SDK/ti/drivers/soc,

but TOPRCMRegs::SHMEMBANKSEL3TO0 and TOPRCMRegs::SHMEMBANKSEL7TO4 I couldn't find the code to set it.

Since the problem I am experiencing is initialization while running the application,

it may be different from the case in link (1),

but it is difficult to judge because the technical manuals in links (2) and (3) are not detailed enough.

 

Is this a problem that needs to be corrected by writing the code that controls SHMEMBANKSEL?

Or is it a different problem with some other factor that could cause the memory to be initialized?

we plan to set up the MPU region to check if there is anything incorrectly accessed inside R4F.

here is my r4f_linker.cmd

/*----------------------------------------------------------------------------*/
/* r4f_linker.cmd                                                                 */
/*                                                                            */
/* (c) Texas Instruments 2016, All rights reserved.                           */
/*                                                                            */

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


/*----------------------------------------------------------------------------*/
/* Linker Settings                                                            */
--retain="*(.intvecs)"


/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */
/* 1843 L3                       : ADDR:0x5100_0000 ~ 0x511F_FFFF             */
/* MMWAVE_L3RAM_NUM_BANK         : 8                                          */
/* MMWAVE_SHMEM_BANK_SIZE        : 0x00020000                                 */
/* MMWAVE_MSSUSED_L3RAM_SIZE     : 0x000A0000                                 */
/* MMWAVE_MSSUSED_L3RAM_CODESIZE : 0x00010000                                 */
/* MMWAVE_L3RAM_SIZE             : 0x00060000                                 */
/* MMWAVE_L3RAM_DATA_SIZE        : 0x00090000                                 */
#define MMWAVE_L3RAM_SIZE (MMWAVE_L3RAM_NUM_BANK*MMWAVE_SHMEM_BANK_SIZE - MMWAVE_MSSUSED_L3RAM_SIZE)
#define MMWAVE_L3RAM_DATA_SIZE (MMWAVE_MSSUSED_L3RAM_SIZE - MMWAVE_MSSUSED_L3RAM_CODESIZE)

MEMORY{
/*PAGE 0:*/
    VECTORS     (X)  : o=0x00000000 l=0x00000100
    PROG_RAM    (RX) : o=0x00000100 l=0x0007FF00
    DATA_RAM    (RW) : o=0x08000000 l=0x00030000
    L3_CODE_RAM (RW) : o=0x51000000 l=0x00000000+(MMWAVE_MSSUSED_L3RAM_CODESIZE)
    L3_DATA_RAM (RW) : o=0x51000000+(MMWAVE_MSSUSED_L3RAM_CODESIZE) l=0x00000000+(MMWAVE_L3RAM_DATA_SIZE)
    L3_DSS_RAM  (R)  : o=0x51000000+(MMWAVE_L3RAM_DATA_SIZE)+(MMWAVE_MSSUSED_L3RAM_CODESIZE) l=0x00000000+(MMWAVE_L3RAM_SIZE)
    HWA_RAM     (RW) : o=0x52030000 l=0x00010000
    HS_RAM      (RW) : o=0x52080000 l=0x8000
}

/*------------------------------------------------------------------------------*/
/* Section Configuration                                                        */
/*------------------------------------------------------------------------------*/
/* Name	           | Initialized | Notes                                        */
/*------------------------------------------------------------------------------*/
/* .text	       | yes	     | executable code                              */
/* .bss	           | no	         | global variables                             */
/* .cinit	       | yes	     | tables which initialize global variables     */
/* .data (EABI)	   | yes and no  | initialized coming out of the assembler;     */
/*                 |             | changed to uninitialized by the linker       */
/* .data (COFF ABI)| yes	     | initialized data                             */
/* .stack	       | no	         | system stack                                 */
/* .heap      	   | no	         | malloc heap                                  */
/* .sysmem         | no	         | malloc heap                                  */
/* .const	       | yes	     | initialized global variables                 */
/* .switch	       | yes	     | jump tables for certain switch statements    */
/* .init_array     | yes	     | Table of C++ constructors called at startup  */
/* .pinit	       | yes	     | Table of C++ constructors called at startup  */
/* .cio	           | no	         | Buffer for stdio functions                   */
/*------------------------------------------------------------------------------*/
SECTIONS{
    .intvecs    : {} > VECTORS
    .text       : {} > PROG_RAM ALIGN(8)
    .const      : {} > PROG_RAM ALIGN(8)
    .cinit      : {} > PROG_RAM ALIGN(8)
    .init_array : {} > PROG_RAM ALIGN(8)
    .pinit      : {} > PROG_RAM ALIGN(8)
    .data       : {} > DATA_RAM
    .bss        : {} > L3_CODE_RAM ALIGN(8)
    .stack      : {} > L3_CODE_RAM ALIGN(32)
    .sysmem     : {} > L3_CODE_RAM ALIGN(8)
}
/*------------------------------------------------------------------------------*/

  • Hi,

    You should not put the .bss section in L3mem because it is not initialized by the RBL. I think.

    Trying to modify the SHMEMBANKSEL will be more complicated

    What are the other sections you can move?

    Thank you

    Cesar

  • What is RBL?


    Initialization is normally performed by instant constructors.

    The problem is that it is not initialized. The problem is that all instances are deleted during execution, as shown in the capture screen, and jump to the exception handler (.intvec).


    Is SHMEMBANKSEL only relevant for initialization when loading code?

    And is there logic to initialize L3? Or does it look like a custom software bug?

  • here is my .map output.

    Due to the misra C rule requiring static allocation, there is no choice but to move .bss global variables whose size has increased.

    The spare portion of the L3 area, which was fully allocated for DPM module use, was allocated as .bss.

    MEMORY CONFIGURATION
    
             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
      VECTORS               00000000   00000100  0000003c  000000c4     X
      PROG_RAM              00000100   0007ff00  0005ffe8  0001ff18  R  X
      DATA_RAM              08000000   00030000  000299c2  0000663e  RW  
      L3_CODE_RAM           51000000   00010000  0000c13b  00003ec5  RW  
      L3_DATA_RAM           51010000   00090000  00090000  00000000  RW  
      L3_DSS_RAM            510a0000   00060000  00000000  00060000  R   
      HWA_RAM               52030000   00010000  00000000  00010000  RW  
      HS_RAM                52080000   00008000  00000000  00008000  RW  
    
    
    SEGMENT ALLOCATION MAP
    
    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    00000000    00000000    0000003c   0000003c    r--
      00000000    00000000    0000003c   0000003c    r-- .vecs
    00000100    00000100    0005fff0   0005fff0    r-x
      00000100    00000100    00057e82   00057e82    r-x .text
      00057f88    00057f88    00007abe   00007abe    r-- .const
      0005fa48    0005fa48    00000058   00000058    r-- .init_array
      0005faa0    0005faa0    00000650   00000650    r-- .cinit
    08000000    08000000    000299c8   00000000    rw-
      08000000    08000000    00025800   00000000    rw- systemHeap
      08025800    08025800    00002000   00000000    rw- .dpcLocalRam
      08027800    08027800    000019c2   00000000    rw- .data
      080291c8    080291c8    00000800   00000000    rw- .myFiqStack
    51000000    51000000    0000c140   00000000    rw-
      51000000    51000000    0000b93b   00000000    rw- .bss
      5100b940    5100b940    00000800   00000000    rw- .stack
    51010000    51010000    00090000   00000000    rw-
      51010000    51010000    00090000   00000000    rw- .l3ram

  • creating an R/W barrier by setting the MPU region between the initialized areas,

    it was confirmed that the error did not occur in MSS program.

    Meanwhile, I also confirmed that the 18xx L3 MPU region setting in sdk/drivers/soc was only half set to 1MB.

    (mmwave_sdk_03_05_00_04\packages\ti\drivers\soc\platform\soc_xwr18xx_mss.c)

    Is there any hints from TI regarding memory initialization?

  • Hello,

    As mentioned in Section 11.3.2 of the TRM, hardware auto-initialization of the DSS_L3 memory banks is supported at reset and memory is initialized to all zero values. You can view the memory initialization status by using the MSS_TOPRCM.MEMINITDONESHMEM register, so you can confirm whether or not the .bss being overwritten with zeros is a result of this reset behavior. 

    The RBL is the ROM Bootloader and should be responsible for allocating the L3 memory banks. By default, the mmwave_sdk_xwr18xx.mak file should allocate all memory banks to L3 if shared memory is used.

    Regards,

    Kristien

  • Thanks Kristien. It was very helpful.

    I found MSS_TOPRCM::MEMINITDONESHMEM.

    However, from the first line of main(), it was set to 0xFF.



    for check additional initialization, I tried to reset the register to 0.

    but when I write zero directly to the address,

    an exception occurred and I confirmed that the LR register was the corresponding code.


    I confirmed that it is Read only in the data sheet, but is there no way to reset MEMINITDONESHMEM?

    I'm looking for a reset function like MSS_TOPRCM::SYSRSTCAUSECLR.

  • Hey,

    Unfortunately, there is no way to reset the MEMINITDONESHMEM register. 

    Regards,

    Kristien

  • I saw an article saying that cache_wbInvAllL2Wait() initializes L3 inside the dss code inside labs.

    (3D_people_counting_demo_implementation_guide.pdf - page21)

    This code is called in cache_setMar() and Pcount3DDemo_DPC_RadarProc_dpmTask().

    And it was confirmed that 1 was written to L1DWBINVRegAddr (L1DWBINV : 0x0184_5044) inside cache_wbInvAllL2Wait().

    Related information could be found here ( https://www.ti.com/lit/ug/sprufk5a/sprufk5a.pdf#page=56&zoom=100,0,571 ).

    I think, the code appears to erase the required L3 size or larger (0x2000_0000 - 0x20FF _FFFFh, 16MB, MAR32).

    I don't know exactly what it does to erase it. Please let TI know.

    This is because it is Global Coherence Operations, but it appears that it can be changed to Block Coherence Operations.

    In the example code, it appears that L3 was initialized very unkindly, causing problems with shared memory customization.

    Is there an example of initializing L3 using L1DWBAR and L1DWIWC?

    It appears that L1DWIWC can only initialize 0x1_0000 words(256KB). I don't know why it doesn't match the MARxx range.

    Also, please let me know if there is a reason to initialize L3 only in this example.

  • Hello,

    I will need some time to look into this, but please create a new thread for this question to help keep E2E organized so other engineers can find similar information easily in the future. You can click the orange "Ask a related question" button in the top-right corner of the website to create a new thread that is automatically linked to this one; I would recommend replying to this message with the new thread link in case others stumble upon this post as well. I will reply in your new thread once it has been created with more information.

    Regards,

    Kristien