RM57 ESM problem with __TI_auto_init()

Hello Wonjae,

   You are seeing a 0x8 in the ESM GP2 which indicates a Cortex-R5 AXI bus fault. This is most likely due to an uncorrectable ECC error when reading the L2 SRAM. Can you check if the L2 SRAM is initialized? Open the memory brower and scan through the L2 SRAM region to see if they are initialized to zero? The default HalcoGen startup file is supposed to initialize the memory for you.

  Can you also check the L2RAMW module RAMERRSTATUS register to see if any flags are set?

Hi Wonjae,

  In the startup code, there is call to _memInit_() which will initialize the L2 SRAM. After power up, if you browse the L2 SRAM starting at 0x0800_0000 you will see random values in the memory. After you initialize the SRAM they should be all zeros. If they are not zeros then it may result as an uncorrectable ECC error to the CPU when the CPU is executing the __TI_auto_init(). This was my first suggestion to look at since you said that running __TI_auto_init() will set ESM group 2 with 0x8 which is a uncorrectable AXI bus fault. RAMERRSTATUS is a status in the L2RAMW module. When you execute __TI_auto_init() it is trying to initialize the global variables which are stored in the L2 SRAM. Checking RAMERRSTATUS register will find out if there is any other issue reading and writing to the L2 SRAM.

  From your newest post, it looks like you are not getting anymore AXI bus fault with the value of 0x8 in the ESM STAT2 register. Can you please confirm this is the case? You think your current problem is due to CPU MPU fault.  However, if you have a MPU fault you will get an abort and there should be no ESM error to assert the LED. Therefore, if you still have the LED turned ON, then it is not related to MPU. Please let me know what ESM is showing. TWhich flag is set in ESM STAT1 to STAT9 registers.

  I'm not too clear on your last problem about the SDRAM. Is 0x9691 what you write to the SDRAM? Could you please elaborate the statement  "they use only upper bit (e.g. 0x00009691), there are values in right side 4 byte because it use little endian."?

Hi Wonjae,

  Can you upload the picture again? I can not see.

  In CCS you can setup a watchpoint. You can setup to watch for writes to address 0x8000_0000. When the watchpoint is hit, the CPU will be stopped. This way you can find out who is writing to 0x8000_0000.

  For the LED, is it turned ON immediately when you connect to the target? If you see the LED immediately when you connect to the targe tthen you can turn it OFF by writing 0x5 to the esmREG-EKR register. Please see below post.

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/366644.aspx

 If you encounter a reset event before you turn off the LED by writing 0x5 to the esmREG-EKR register then you will need to turn off the LED by first writing 0xA to the esmREG-EKR followed by writing 0x0.  You may ask where the reset event is coming from. I think what happen is that once you connect to the taget you may have tried to perform reflash the code. The flash loader will perform a reset to the device. When this happens it clears some of ESM's internal register and the ESM kin of  lost track of an earlier ESM event (the CCM compare  error event when you first connect to the target the first time). So try to clear the ESM by writing 0xA and then 0x0 if this is the case.  

Hi Wonjae,

  I tried to use your code sequence to access the SDRAM and below is the screenshot of my result. I'm able to write to the SRAM properly. I use HalCoGen to first configure the EMIF module. There is an example EMIF_SDRAM for RM57 device. Please make sure the EMIF is properly setup.

For your second question about why the the SDRAM space at 0x80000000 is displaying your last written value after a reset at the main(), I think the reason is that once you generate a reset you reset the EMIF configuration. All the registers in the EMIF are in the default states. Now the debugger is refreshing the memory browser for the SDRAM space using the default SDRAM configuration and this could lead to the problem you are seeing. Where do you initialize the EMIF? As you can see in my example screenshot the emif_SDRAMInit() is called after the main(). If you were to place a breakpoinit after the emif_SDRAMInit() and then do a reset and run to the breakpoint then you will see the correct values being displayed for the four 16-bit words you just wrote.

Hello Wonjae,

  Good that your fould the reason. As mentioned, there is a HalCoGen example for using SDRAM for RM57. You can take a look on its EMIF setup for SDRAM.