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.

CCS/TMS570LS1224: Trace issue when executing code from RAM

Part Number: TMS570LS1224
Other Parts Discussed in Thread: HALCOGEN,

Tool/software: Code Composer Studio

Hi, 

I'm generating a boot loader application which is basically complete except for the flash program and erase. I've used Halcogen to produce the initialisation code, and copied part of the example 'spna192' for the flash programming API functions.

My issue occurs when the code first jumps to the RAM based code, whereupon I get an error message from the launchpad as below :

"CortexR4: Trouble Reading Memory Block at 0x8001c04 on Page 0 of Length 0xbc: (Error -1208 @ 0x20000600) Unable to access an ETM register. Check that the ETM is configured properly as a cs_child. (Emulation package 8.0.903.6) "

Any assistance would be gratefully received.

  • Hello Bob,

    The flash API related code should be copied to SRAM and executed from SRAM if you want to erase/program the sector in the same flash bank. Did you access the ETM registers? How did you copy the code to SRAM?
  • Hi,

    The code is being copied to SRAM, I've basically copied the linker script from spna192 and have the following sections :

    SECTIONS
    {
    .intvecs : {} > VECTORS

    /* USER CODE BEGIN (4) */
    flashAPI : {
    Fapi_UserDefinedFunctions.obj (.text)
    bl_flash.obj (.text)
    --library = "C:\TI\Hercules\F021 Flash API\02.01.01\F021_API_CortexR4_BE_L2FMC.lib" (.text)

    } load=FLASH_API, run = RAM, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)

    /* USER CODE END */

    .text : {} > FLASH0
    .const : {} > FLASH0
    .cinit : {} > FLASH0
    .pinit : {} > FLASH0

    /* USER CODE BEGIN (5) */
    GROUP {
    .sysmem : {}
    .data : {}
    .bss : {}
    } > RAM
    /* USER CODE END */
    }

    And in sys_startup.c i have

    /* initialize copy table */
    __TI_auto_init();
    /* USER CODE BEGIN (75) */
    _copyAPI2RAM_();

    /* USER CODE END */

    /* call the application */
    /*SAFETYMCUSW 296 S MR:8.6 <APPROVED> "Startup code(library functions at block scope)" */
    /*SAFETYMCUSW 326 S MR:8.2 <APPROVED> "Startup code(Declaration for main in library)" */
    /*SAFETYMCUSW 60 D MR:8.8 <APPROVED> "Startup code(Declaration for main in library;Only doing an extern for the same)" */
    main();

    the copyAPI2RAM is in sys_core.asm and is identical to the supplied file in spna192 

    When debugging, If I stop in main prior to calling any of the functions in bl_flash.obj and display the memory area under code composer after the copyAPI2RAM has run I see :

    0x08001500 Fapi_serviceWatchdogTimer
    0x08001500 E3A00000 E12FFF1E
    0x08001508 BLInternalFlashFirstSectorSizeGet
    0x08001508 E24DD008 E59FC7A0 E59F0798 E59CC000 E5900000 E080C00C E58DC000 E59D0000 E28DD008 E12FFF1E
    0x08001530 BLInternalFlashSizeGet
    0x08001530 E24DD008 E59FC780 E59F0778 E59CC000 E5900000 E080C00C E58DC000 E59D0000 E28DD008 E12FFF1E
    0x08001558 BLInternalFlashStartAddrCheck
    0x08001558 E24DD018 E58D1004 E58D0000 E3A0C000 E58DC008 E59F0744 E59FC744 E5900000 E59CC000 E080C00C
    0x08001580 E58DC010 E3A0C000 E58DC00C E59DC00C E35C0010 2A00001E
    0x08001598 $C$L1
    0x08001598 E59DC00C E59F1710 E1A0020C E080C10C E59D0000 E791C00C E15C0000 8A000010 E59D000C E59DC00C
    0x080015C0 E59F26EC E1A01200 E59F36E0 E0810100 E1A0120C E081C10C E7920000 E793C00C E59D1000 E08CC000
    0x080015E8 E15C0001 9A000002 E59DC008 E28CC001 E58DC008
    0x080015FC $C$L2
    0x080015FC E59DC00C E28CC001 E58DC00C E59DC00C E35C0010 3AFFFFE0
    0x08001614 $C$L3
    0x08001614 E59DC008 E35C0000 1A000001 E3A00000 EA00000E
    0x08001628 $C$L4
    0x08001628 E59DC000 E35C0802 1A000008 E59D0000 E59D1004 E59DC010 E0810000 E15C0000 3A000002 E59DC000
    0x08001650 E31C0003 0A000001

     and the dissassembly appears to show reasonable code. However as soon as I try to execute the code I get the error reported

  • I forgot to mention : I don't access the ETM registers in my code
  • I have made some progress. I have a small test function that I call to test the erase & programme functions. as shown below :
    U32 Result;
    U8 MyData[128];

    memset(MyData, 0, sizeof(MyData));
    memcpy(MyData,"Hello world/n", strlen( "Hello world/n") );
    Result = Fapi_BlockErase( 0, FMDS_IMAGE_START, 0x10000);
    Result = Fapi_BlockProgram(0, FMDS_IMAGE_START, (uint32_t)(MyData), sizeof(MyData));

    return (S32) Result;

    I added this function to bl_flash.c (at the end of the file). I have just moved the code to the start of the file and I no longer get the ETM error, but the code is hanging in FAPI_BlockErase () in the while loop that checks for Fapi_Status_FsmBusy.
  • Hi Bob,

    The flash library that you are loading is incorrect. The correct library to use for the TMS570LS1224 is:
    C:\ti\Hercules\F021 Flash API\02.01.01\F021_API_CortexR4_BE_v3D16.lib

    Regards,
    Sunil
  • Thanks Sunil, that solved one issue and the code is making progress. The issue now is a data abort exception which ends up at flashErrorReal in dabort.asm.

    Placing a break at the data abort, the Link register indicates the ldr r1, [r0], #4 instruction in the Flash_Erase_Check function (part of C line 268) , r0 in this case is 0x20008 and r1 is 2. which appears to be the second U32 location in the sector that I am attempting to erase/programme.

    Any thoughts, have I got something wrong in the Halcogen setup somewhere ?

    regards Bob

  • Hi Bob,

    The content of the erased sector is 0xFFFFFFFF. Is the abort caused by the code in the while() loop:

    while(bytes > 0)
    {
    if(*dst1++ != 0xFFFFFFFF){
    error = 2;
    }
    bytes -= 0x4;
    }
  • Yes, the abort is in the loop. It appears to be happening the second time through the loop.

  • Hi Bob,

    It might be caused by the ECC. When you issue the erase command, the flash API erases both the flash sectors and the ECC section for those erased flash sectors. The content of both sections become 0xFFFFFFFF. The TMS570 microcontrollers protect all accesses to the on-chip flash memory by Single-Bit Error Correction Double-Bit Error Detection (SECDED) logic.

    If the ECC checking is enabled, the data you read out from the flash is the corrected data which is not 0xFFFFFFFF.

    Please disable the flash ECC before doing this flash content checking:

    _coreDisableFlashEcc_();