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

Flash API prefetchEntry

Thomas Hess
Prodigy 70 points
Other Parts Discussed in Thread: TMS570LS3137

Hi,

I'm trying to use the Flash API 021 (F021_API_CortexR4_BE_V3D16.lib) with the TMS570LS3137. Whenever calling a function from the Fapi Library I get a prefetchEntry Interrupt.

There seem to be quite a few entries in this Board about the same problem. So, I already checked following points:

  • Running wrapper function out of RAM (Linker Command File and wrapper function attached below)
  • Flushing Pipeline after last Fapi Function Call with Fapi_flushPipeline()
  • Changing MPU Permission to Read/Write
  • Using privileged Mode for Fapi Function Execution

Do you have any further ideas what could cause the probelm ?

Thank you very much for your Help

Best Regards

Thomas

Software used:

  • HALCoGen04.05.01
  • CCS 6.1.1.00022

void useFlashApi()
{

	Fapi_StatusType oReturnCheck = Fapi_Status_Success;

	oReturnCheck = Fapi_initializeFlashBanks(160); // Example code is assuming operating frequency of 160 MHz //
	if((oReturnCheck == Fapi_Status_Success) &&	(FLASH_CONTROL_REGISTER->FmStat.FMSTAT_BITS.BUSY != Fapi_Status_FsmBusy))
	{
		oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);

		Fapi_enableMainBankSectors(Fapi_FlashBank0);
		// Place specific example code here //
		// Wait for FSM to finish //
		while(FLASH_CONTROL_REGISTER->FmStat.FMSTAT_BITS.BUSY == Fapi_Status_FsmBusy);
		// Check the FSM Status to see if there were no errors //
		if (FLASH_CONTROL_REGISTER->FmStat.u32Register != 0)
		{
		// Put Error handling code here //
		}
	}
	Fapi_flushPipeline();
}

--retain="*(.intvecs)"


MEMORY
{
    VECTORS    (X)   : origin=0x00000000 length=0x00000020
    FLASH_API  (RX)  : origin=0x00000020 length=0x000014E0
    FLASH0     (RX)  : origin=0x00001500 length=0x002FEB00   //LS31x and RM48 Flash size is 0x300000
    SRAM       (RW)  : origin=0x08002000 length=0x0002D000
    STACK      (RW)  : origin=0x08000000 length=0x00002000
}
SECTIONS
{
   .intvecs : {} > VECTORS
   flashAPI :
   {
     ..\Release\Fapi_UserDefinedFunctions.obj (.text)
     ..\Release\bl_flash.obj (.text)

     --library= F021_API_CortexR4_BE.lib < FlashStateMachine.IssueFsmCommand.obj
     									  FlashStateMachine.SetActiveBank.obj
     									  FlashStateMachine.InitializeFlashBanks.obj
     									  FlashStateMachine.EnableMainSectors.obj
     									  FlashStateMachine.IssueFsmCommand.obj
     									  FlashStateMachine.ScaleFclk.obj
                                          Init.obj
                                          Utilities.CalculateEcc.obj
                                          Utilities.WaitDelay.obj
                                          Utilities.CalculateFletcher.obj
                                          Read.MarginByByte.obj
                                          Read.Common.obj
                                          Read.FlushPipeline.obj
     									  Read.WdService.obj
                                          Async.WithAddress.obj
                                          Program.obj > (.text)
   } load = FLASH_API, run = SRAM, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)

   .text  > FLASH0
   .const > FLASH0
   .cinit > FLASH0
   .pinit > FLASH0
   .data  > SRAM
   .bss   > SRAM
}

  • 0
    TI__Guru**** 191906 points

    Hi Thomas,

      Can you read out the Instruction Fault Status Register and the Instruction Fault Address Register from the CPU core? It will help us track the cause of the prefetch abort?

  • 0 in reply to Charles Tsai
    Prodigy 70 points
    Hi Charles,

    Thanks for your repyl. The Instruction Fault Status Register is 0x00000409 and the Instruction Fault Address Register is 0x08040000
  • 0 in reply to Thomas Hess
    TI__Guru**** 191906 points
    Hi Tomas,
    This error indicates that you have a precise ECC error from address location 0x008040000. Do you have the ECC enabled? Please check bit[27:26] in the auxiliary control register inside the CPU. If you have the intention to enable ECC then you will need to enable ECC before you copy the flashAPI to the RAM. This is to allow the ECC code to be generated for the flashAPI image in the SRAM. Later when you execute the flashAPI code from the SRAM it will not fail ECC checking. Another thing to try is to make sure the ECC is disable and see if it makes a difference so we can isolate the problem.
  • 0 in reply to Charles Tsai
    Prodigy 70 points
    Hi Charles,

    You're right ECC, was actually enabled. I tried disableing it with _coreDisableFlashEcc_() and _coreDisableRamEcc_() at the beginning of the main routine, before calling the flash wrapper function. This actually set the Bit [26,27] to 0. However, when running the code it still goes into the prefetchEntry State and the Instruction Fault Status Register and the Instruction Fault Address Register still have the same values. I also tried enabeling both ECCs which led to the same result.
  • 0 in reply to Thomas Hess
    TI__Guru**** 191906 points

    Hi Thomas,

     Is ECC ever enabled in your code at any point of time? When you program the code into the flash memory did you generate the ECC using the auto-ECC feature in  CCS  or your .out file is already appended with the corresponding ECC?  The reason I'm asking is because the moment you enable ECC you need to make sure that the program image has the corresponding ECC checksum. Otherwise, you will have ECC errors even running code out of the flash. However, the Fault address register is showing the SRAM area.

    If you single step through the code, can you tell me at which line did it start to abort?

  • 0 in reply to Charles Tsai
    Prodigy 70 points

    Hi Charles,


    I tried enabeling ECCat the beginning of the main Routine with _coreEnableFlashEcc_() and _coreEnableRamEcc_(), however the prefetchEntry still occurs with the same Error Code.

    The ECC Code is generated with the auto-ECC feature in CCS.

    When single stepping through the Code the abort happens right after executing the last Flash API function, before jumping back into the main routine where the wrapper function was called from.

    Could the problem be that one has to create the ECC Code manually after using the Flash API Function with Fapi_calculateEcc() and copy it to flash manually?

  • 0 in reply to Thomas Hess
    TI__Guru**** 191906 points
    Hi Thomas,
    I assume the last instruction of this API function is in the SRAM, right?

    If you single step further, is the abort generated at the last line of API function?

    This is what I kind of suspect happening but I don't know for sure. The CPU could sometime perform speculative fetch from an address where there isn't a corresponding ECC. In this case, an uncorrectable ECC error is detected.

    Can you try not to enable ECC at all in your code as an experiment just to see if it makes a difference?

    I also want to know if you have initiated the SRAM during your startup. Since you are running code from the RAM for the flash API function and if the CPU performs some speculative access in the RAM where there is no valid ECC then you can also get ECC error. If the RAM is initialized then even the unused RAM locations will have their default ECC values.
  • 0 in reply to Charles Tsai
    Prodigy 70 points
    Hi Charles,

    The Abort actually occurs independently of the falsh API functions. When commenting out all code within the wrapper function the Abort occurs as soon as calling the wrapper function in RAM. So the problem isn't really the Flash API as I suspected, but rather calling the function from RAM.

    The Function is executed in the SRAM at 0x08002000, as specified in the linker command file.

    The RAM is initialized during the startup Routine, I also checked the correct initialization of the default ECC at the Memory space from 0x08400000 - 0x0843FFFF which are all 0x0C. According to another thread on the e2e board, this is the default ECC after initialization of the RAM.

    I tried disabling ECC with _coreDisableRamEcc_() and _coreDisableFlashEcc_(). However this doesn't seem to help, even thogh it sets the corresponding bits [26:27] of the Auxiliary_Control Register to 0.
  • 0 in reply to Thomas Hess
    TI__Guru**** 191906 points
    Hi Thomas,
    I might need to take a look at your project? Can you send me the CCS project?

    Can you also tell me at which line did it start to abort so I can have a head start on debugging?
  • 0 in reply to Charles Tsai
    TI__Guru**** 191906 points
    Hi Thomas,
    One thing I'd like you to quickly check is your MPU setting. When you run from RAM, you need to make sure that the RAM area is declared for executable attribute. Perhaps I was confused because your initial abort was due to ECC based on the instruction fault status register. However, i didn't ask you to re-check the IFSR again when you totally disabled the ECC. And if you are still getting prefetch abort, what does the IFSR say? Is it MPU related or still ECC related?
  • 0 in reply to Charles Tsai
    Prodigy 70 points

    Hi Charles


    After disabling ECC ,the IFSR and the IFDR still have the same Entries (IFSR = 0x00000409 and IFDR = 0x08040000 = end of RAM). For the MPU all registers are configured as read/write/execute, so the MPU shouldn't restrict execution from RAM.

    I attached a minimalist example of my programm code which illustrates the basic problem below:

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/312/1385.FlashProgramm.7z

  • 0 in reply to Thomas Hess
    TI__Guru**** 191906 points

    Hi Thomas,

     I think what happened was that you did not copy the flashAPI library to the SRAM. In your linker command file, the RUN_START(api_run) does not mean the linker will automatically copy the library from the load address to the run address. You will need to copy your self. Without the executable code copied to the RAM area, the CPU will execute the code currently stored in the RAM which is nothing but all zeros. I don't know why the ARM CPU is giving an ECC error rather than undefined instruction. 

     Please find attached modified project where I inserted a _copyAPIRAM_() right before the call to the main() in the sys_startup.c file. The _copyAPIRAM_() is defined in the copyAPI2RAM.asm file. Please give a try.

    6840.Flash_programming_using_flashAPI.zip

      

  • 0 in reply to Charles Tsai
    Prodigy 70 points
    Hi Charles,

    With your _copyAPIRAM_ Function the programm works.
    Thank you very much for your help!

    Best Regards

    Thomas
  • 0 in reply to Thomas Hess
    TI__Guru**** 191906 points
    Hi Thomas,
    Glad that your problem is resolved.