• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 1069 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.

CCS11 fails to load F021 Flash API from debugger

Jack Cochran
Prodigy 40 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: UNIFLASH, SEGGER, , RM48L952, HALCOGEN, TMS570LS0432, LAUNCHXL-TMS57004, RM42L432, LAUNCHXL-RM42

We have a Hercules application that links to the F021 Flash API library for flash programming.  When loading the application using the CCS 11 debugger, the Flash API section is not loaded, but the rest of the application is loaded.  When loading the same application using Segger tools, Uniflash 7, or CCS 10.4, this behavior is not reproduced:  All sections are loaded as expected.

Environment:

 - MCU:  TMS570LS3137

 - Programmer:  Segger J-Link Pro

 - IDE:  Code Composer Studio 11.0.0.00012 on Windows and Linux (reproduced on both)

Steps to reproduce:

1. Write a Hercules application that uses the F021 Flash API.  Flash API is configured to be copied from flash into RAM.  We link the Flash API library with the following linker script (excerpt):

   flashAPI : fill = 0xFFFFFFFF // This guarantees that the holes will be filled with this value.
   {
     Fapi_UserDefinedFunctions.obj (.text)
     bl_flash.obj (.text)
     --library= ../../common/flash_lib/F021_API_CortexR4_BE.lib (.text)
     . += FLASH_API_LENGTH - .; // Aforementioned hole that will be filled (remaining flash in this section).
   } load = FLASH_API, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)

2. Obtain a TMS570 device with empty flash memory, or erase the flash on a previously-used device.  Empty flash ensures that you detect if the Flash API section was not loaded.

3. Load the application onto the device using the CCS 11 debugger.

4. Using the debugger, observe that the section of memory reserved for the Flash API section is not programmed (0xFF).

The following tools load the Flash API section as desired when operating on the same ELF binary:

1. Code Composer Studio 10.4.0.00006

2. Uniflash 7.0.0.3615

3. SEGGER J-Flash 7.56.d

  • 0
    TI__Guru**** 196686 points

    Hi Jack,

    Can you share your linker cmd file? 

  • 0
    Guru 92251 points

    I had a project setup using the GCC 9.2.1 compiler and a RM48L952 with theFlash API is configured to be copied from flash into RAM, and the GCC linker script contains:

      /* used by the startup to initialize flashAPI */
   _siflashAPI = LOADADDR(.flashAPI);

  .flashAPI :
  {
    . = ALIGN(4);

    _sflashAPI = .;         /* create a global symbol at data start */
    *Fapi_UserDefinedFunctions.o (.text*)
    *F021_API_CortexR4_LE_V3D16.lib:* (.text*)

    . = ALIGN(4);
    _eflashAPI = .;            /* define a global symbol at data end */
  } >RAM AT> FLASH_API

    For information, the project is at https://github.com/Chester-Gillon/E2E_example_projects/tree/master/RM48L952_GCC_FEE_read_write

    Using CCS 11.0.0.00012 under Ubuntu 18.04 I can't repeat the problem.

    The linker map file shows the Flash API section of size 0x888 being placed at flash at address 0x20 with a run address in SRAM at 0x8001500:

    .flashAPI       0x0000000008001500      0x888 load address 0x0000000000000020
                0x0000000008001500                . = ALIGN (0x4)
                0x0000000008001500                _sflashAPI = .
 *Fapi_UserDefinedFunctions.o(.text*)
 .text          0x0000000008001500        0x8 ./source/Fapi_UserDefinedFunctions.o
                0x0000000008001500                Fapi_serviceWatchdogTimer
 *F021_API_CortexR4_LE_V3D16.lib:*(.text*)
 .text          0x0000000008001508        0x0 /home/mr_halfword/ti/Hercules/F021 Flash API/02.01.01/F021_API_CortexR4_LE_V3D16.lib(Async.obj)
 .text:Fapi_issueAsyncCommand
                0x0000000008001508       0x2a /home/mr_halfword/ti/Hercules/F021 Flash API/02.01.01/F021_API_CortexR4_LE_V3D16.lib(Async.obj)
                0x0000000008001508                Fapi_issueAsyncCommand
 .text          0x0000000008001532        0x0 /home/mr_halfword/ti/Hercules/F021 Flash API/02.01.01/F021_API_CortexR4_LE_V3D16.lib(Async.WithAddress.obj)
 *fill*         0x0000000008001532        0x2 
<snip>
 .text:Fapi_isAddressEEPROM.__stub
                0x0000000008001d80        0x8 linker stubs
                0x0000000008001d88                . = ALIGN (0x4)
                0x0000000008001d88                _eflashAPI = .
                0x0000000008001d88                . = ALIGN (0x4)

    The debug probe used was a XDS100v2.

    In the CCS project properties under Debug -> Flash Settings ticked the "Enable Verbose Output" to cause CCS to report what flash operations are performed.

    When start a debug session can see all flash sectors being erased, followed by writing and then verifying "Flash @ Address 0x00000020 of Length 0x00000888" which is the load address of the F021 Flash API:

    CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
CortexR4: Writing Flash @ Address 0x00000000 of Length 0x00000020
CortexR4: Erasing Flash Bank 0, Sector 0
CortexR4: Erasing Flash Bank 0, Sector 1
CortexR4: Erasing Flash Bank 0, Sector 2
CortexR4: Erasing Flash Bank 0, Sector 3
CortexR4: Erasing Flash Bank 0, Sector 4
CortexR4: Erasing Flash Bank 0, Sector 5
CortexR4: Erasing Flash Bank 0, Sector 6
CortexR4: Erasing Flash Bank 0, Sector 7
CortexR4: Erasing Flash Bank 0, Sector 8
CortexR4: Erasing Flash Bank 0, Sector 9
CortexR4: Erasing Flash Bank 0, Sector 10
CortexR4: Erasing Flash Bank 0, Sector 11
CortexR4: Erasing Flash Bank 0, Sector 12
CortexR4: Erasing Flash Bank 0, Sector 13
CortexR4: Erasing Flash Bank 0, Sector 14
CortexR4: Erasing Flash Bank 1, Sector 0
CortexR4: Erasing Flash Bank 1, Sector 1
CortexR4: Erasing Flash Bank 1, Sector 2
CortexR4: Erasing Flash Bank 1, Sector 3
CortexR4: Erasing Flash Bank 1, Sector 4
CortexR4: Erasing Flash Bank 1, Sector 5
CortexR4: Erasing Flash Bank 1, Sector 6
CortexR4: Erasing Flash Bank 1, Sector 7
CortexR4: Erasing Flash Bank 1, Sector 8
CortexR4: Erasing Flash Bank 1, Sector 9
CortexR4: Erasing Flash Bank 1, Sector 10
CortexR4: Erasing Flash Bank 1, Sector 11
CortexR4: Erasing Flash Bank 7, Sector 0
CortexR4: Erasing Flash Bank 7, Sector 1
CortexR4: Erasing Flash Bank 7, Sector 2
CortexR4: Erasing Flash Bank 7, Sector 3
CortexR4: Verifying Flash @ Address 0x00000000 of length 0x00000020
CortexR4: Writing Flash @ Address 0x00000020 of Length 0x00000888
CortexR4: Verifying Flash @ Address 0x00000020 of length 0x00000888
CortexR4: Writing Flash @ Address 0x00001500 of Length 0x00007ff0
CortexR4: Verifying Flash @ Address 0x00001500 of length 0x00007FF0
CortexR4: Writing Flash @ Address 0x000094f0 of Length 0x00005608
CortexR4: Verifying Flash @ Address 0x000094F0 of length 0x00005608
CortexR4: Writing Flash @ Address 0x0000eaf8 of Length 0x00000444
CortexR4: Verifying Flash @ Address 0x0000EAF8 of length 0x00000444
CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset

    The program ran successfully, and stepping in the debugger confirmed called Flash F021 API functions which had been copied from flash to SRAM.

    Will try and recreate the problem by changing to the TI compiler / debug probe used / different device to see what the trigger is.

    Jack Cochran said:
    When loading the application using the CCS 11 debugger, the Flash API section is not loaded, but the rest of the application is loaded

    In your failing case the following may be helpful get more information:

    a. The output from the CCS console when starting a debug session with "Enable Verbose Output" selected in the flash settings. Edit: That option doesn't exist when using a J-Link. For a J-Link enable the J-Link log file. Found that the "J-Link Log File Path" in the CCS Target Configuration file seemed to be ignored. Instead use the generic way described in Enable J-Link Log File

    b. The CCS Debug Server Logs. In the past the debug server logs have shown how the debugger determines which sections from the ELF binary are to be programmed.

  • 0 in reply to Chester Gillon
    Guru 92251 points
    Chester Gillon said:
    Will try and recreate the problem by changing to the TI compiler / debug probe used / different device to see what the trigger is.

    Used the same RM48L952 program as above, but with CCS 11.0.0.00012 under Windows 10 and using a Segger J-Link.

    Prior to the test used the a XDS100v2 to be able to use the CCS Flash options to erase and then blank check the device, due to the Segger flash progammer skipping the flashing if the contents in flash already matches.

    Still couldn't recreate the failure.

    Looking in the JLinkLogOverride.log can see:

    1. A call to JLINK_WriteMem(0x00000020, 0x888 Bytes, ...) which is for the Flash F021 API:

    T1B30 3103:984.384 JLINK_BeginDownload(Flags = 0x00000000)
T1B30 3103:984.384 - 0.037ms
T1B30 3103:984.384 JLINK_WriteMem(0x00000000, 0x20 Bytes, ...)
T1B30 3103:984.384   Data:  A2 15 00 EA FE FF FF EA FE FF FF EA FE FF FF EA ...
T1B30 3103:985.152   completely In flash
T1B30 3103:985.152 - 0.588ms returns 0x20
T1B30 3103:985.152 JLINK_ReadMem(0x00000000, 0x4 Bytes, ...)
T1B30 3103:985.152    -- Read from flash cache (4 bytes @ 0x00000000)
T1B30 3103:985.152   Data:  A2 15 00 EA
T1B30 3103:985.152 - 0.052ms returns 0
T1B30 3103:985.408 JLINK_WriteMem(0x00000020, 0x888 Bytes, ...)
T1B30 3103:985.408   Data:  00 00 A0 E3 1E FF 2F E1 10 B5 04 46 10 2C 0B D0 ...
T1B30 3103:985.408   completely In flash
T1B30 3103:985.408 - 0.125ms returns 0x888
T1B30 3103:985.664 JLINK_ReadMem(0x00000020, 0x4 Bytes, ...)
T1B30 3103:985.664    -- Read from flash cache (4 bytes @ 0x00000020)
T1B30 3103:985.664   Data:  00 00 A0 E3
T1B30 3103:985.664 - 0.050ms returns 0
T1B30 3103:985.920 JLINK_WriteMem(0x00001500, 0x7FF0 Bytes, ...)
T1B30 3103:985.920   Data:  10 B5 42 F2 CC 14 C0 F6 00 04 23 78 63 B9 40 F2 ...
T1B30 3103:985.920   completely In flash
T1B30 3103:986.176 - 0.088ms returns 0x7FF0
T1B30 3103:986.176 JLINK_ReadMem(0x00001500, 0x4 Bytes, ...)
T1B30 3103:986.176    -- Read from flash cache (4 bytes @ 0x00001500)
T1B30 3103:986.176   Data:  10 B5 42 F2
T1B30 3103:986.176 - 0.050ms returns 0
T1B30 3103:986.432 JLINK_WriteMem(0x000094F0, 0x5608 Bytes, ...)
T1B30 3103:986.432   Data:  28 23 02 E3 00 28 40 E3 C8 30 A0 E3 93 2A 23 E0 ...
T1B30 3103:986.432   completely In flash
T1B30 3103:986.432 - 0.073ms returns 0x5608
T1B30 3103:986.688 JLINK_ReadMem(0x000094F0, 0x4 Bytes, ...)
T1B30 3103:986.688    -- Read from flash cache (4 bytes @ 0x000094F0)
T1B30 3103:986.688   Data:  28 23 02 E3
T1B30 3103:986.688 - 0.050ms returns 0
T1B30 3103:986.688 JLINK_WriteMem(0x0000EAF8, 0x444 Bytes, ...)
T1B30 3103:986.944   Data:  00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 ...
T1B30 3103:986.944   completely In flash
T1B30 3103:986.944 - 0.054ms returns 0x444
T1B30 3103:986.944 JLINK_EndDownload()

    2. The flash being erased and the programmed:

    T1B30 3103:987.200   Old firmware which does not support pausing periodic actions during flash download
T1B30 3103:987.200    -- --------------------------------------
T1B30 3103:987.200   Flash bank @ 0x00000000: Default: L2 verify disabled because algorithm performs L1 verify
T1B30 3103:987.200    -- Start of determining dirty areas in flash cache
T1B30 3103:988.224    -- End of determining dirty areas
T1B30 3103:988.224    -- Start of preparing flash programming
T1B30 3103:988.224    -- Calculating RAM usage
T1B30 3103:988.224    -- RAM usage = 11368 Bytes
T1B30 3103:988.224    -- Preserving CPU registers
T1B30 3103:998.720    -- Preparing memory
T1B30 3103:998.720    -- Determining CPU clock frequency
T1B30 3104:283.136    -- Preparing target
T1B30 3104:283.136    -- Preserving target RAM temporarily used for programming
T1B30 3104:452.096    -- Downloading RAMCode
T1B30 3104:546.560    -- Checking target RAM
T1B30 3104:573.952    -- CPU frequency = 15997 kHz
T1B30 3104:573.952    -- End of preparing flash programming
T1B30 3104:574.208   Looking for J-Link GUI Server exe at: C:\ti\ccs1100\ccs\ccs_base\DebugServer\drivers\JLinkGUIServer.exe
T1B30 3104:574.464   Looking for J-Link GUI Server exe at: \JLinkGUIServer.exe
T1B30 3104:874.752   Failed to connect to J-Link GUI Server.
T1B30 3104:886.784    -- CPU is running at 15997 kHz.
T1B30 3104:886.784    -- Start of comparing flash
T1B30 3104:886.784    -- CRC check was estimated as fastest method
T1B30 3104:887.040    -- Comparing range 0x0000 - 0xFFFF (2 Sectors, 64 KB), using single-block CRC calculation
T1B30 3104:999.936    -- CRC does not match, checking individual sectors
T1B30 3105:063.680    -- CRC does not match for sector 0
T1B30 3105:127.936    -- CRC does not match for sector 1
T1B30 3105:128.192    -- End of comparing flash
T1B30 3105:128.192    -- Start of erasing sectors
T1B30 3105:128.192    -- Erasing range 0x00000000 - 0x00007FFF (  1 Sector, 32 KB)
T1B30 3105:143.296    -- Erasing range 0x00008000 - 0x0000FFFF (  1 Sector, 32 KB)
T1B30 3105:158.144    -- End of erasing sectors
T1B30 3105:158.144    -- Start of flash programming
T1B30 3105:158.400    -- Programming range 0x00000000 - 0x00007FFF (  1 Sector, 32 KB)
T1B30 3106:004.992    -- Programming range 0x00008000 - 0x0000FFFF (  1 Sector, 32 KB)
T1B30 3106:851.328    -- End of flash programming
T1B30 3106:851.328    -- 0x0000 - 0xFFFF (  2 Sectors, 64 KoB)
T1B30 3106:851.584    -- Start of restoring
T1B30 3106:851.584    -- Restoring RAMCode
T1B30 3106:865.664    -- Restoring target memory
T1B30 3107:019.776    -- Restore target
T1B30 3107:019.776    -- Restore memory
T1B30 3107:019.776    -- Restoring CPU registers
T1B30 3107:020.032    -- End of restoring
T1B30 3107:020.032    -- Bank 0 @ 0x00000000: 1 range affected (65536 bytes)
T1B30 3107:020.032    -- Total: 3.031s (Prepare: 0.898s, Compare: 0.241s, Erase: 0.030s, Program & Verify: 1.693s, Restore: 0.168s)
T1B30 3107:020.032    -- Program & Verify speed: 37 KB/s
T1B30 3107:024.128 - 3037.203ms returns 65536 (0x10000)

  • 0
    Guru 92251 points
    Jack Cochran said:
     - IDE:  Code Composer Studio 11.0.0.00012 on Windows and Linux (reproduced on both)

    Can you confirm which version of SEGGER J-Link is installed in CCS 11.0?

    Looking back the Installation History in CCS 11.0.0.00012, under both Windows and Linux:

    • When CCS 11 was first installed the version of SEGGER J-Link was v6.44.0.b
    • Subsequent updates to SEGGER J-Link v7.52.4.0 and then v7.56.2.0 were performed, when prompted by the CCS updates

    For the above tests I was using SEGGER J-Link v7.56.2.0 in CCS.

    Your TMS570LS3137 MCU is a big-endian device.

    In Release notes for the J-Link / Flasher Software and Documentation Package for Version V7.52c (2021-08-10) for the DLL there is:

    2. Big endian Cortex-A and Cortex-R devices flash programming, fixed.

  • 0
    Prodigy 40 points
    Chester Gillon said:
    Can you confirm which version of SEGGER J-Link is installed in CCS 11.0?

    com.segger.jlink.win64.feature.group is 7.56.2.0 (perhaps corresponds with 7.56.b?)

    com.segger.jlink.drivers.win64.feature.group is 1.0.1.0

    I don't think I can upload the full linker command file to a public forum, but I can confirm that I see the same problem with the spna193 UART Bootloader example for LS31x devices.  This linker command file is below:

    --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 :
   {
     Fapi_UserDefinedFunctions.obj (.text)
     bl_flash.obj (.text)
     --library= ..\..\..\lib\F021_API_CortexR4_BE.lib (.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
}

    I will have to look into the Segger release notes later.

  • 0 in reply to Chester Gillon
    Prodigy 40 points

    Here's something interesting from the CCS DebugServer Logs:

    0x00008204 13215 4 CortexR4 OFS I: OFS error code being set to 0
0x00008204 13215 4 CortexR4 OFS_DWARF I: Attempting to read program file.  Trying COFF format.
0x00008204 13215 4 CortexR4 OFS_DWARF I: Invalid COFF magic number
0x00008204 13215 4 CortexR4 OFS I: OFS error code being set to 6
0x00008204 13215 4 CortexR4 OFS_DWARF I: Attempting to read program file.  Now trying ELF format.
0x00008204 13215 4 CortexR4 OFS I: OFS error code being set to 0
0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: .intvecs
0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 32, or 0x20
0x00008204 13215 4 CortexR4 OFS D:   load location: 0x0
0x00008204 13215 4 CortexR4 OFS D:   run location: 0x0
0x00008204 13215 4 CortexR4 OFS D:   memory page: 0
0x00008204 13215 4 CortexR4 OFS D:   offset in file: 52 or 0x34
0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: flashAPI
0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 3880, or 0xf28
0x00008204 13215 4 CortexR4 OFS D:   load location: 0x8002000     <------ Look here
0x00008204 13215 4 CortexR4 OFS D:   run location: 0x8002000
0x00008204 13215 4 CortexR4 OFS D:   memory page: 0
0x00008204 13215 4 CortexR4 OFS D:   offset in file: 84 or 0x54
0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: .text
0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 12408, or 0x3078
0x00008204 13215 4 CortexR4 OFS D:   load location: 0x1500
0x00008204 13215 4 CortexR4 OFS D:   run location: 0x1500
0x00008204 13215 4 CortexR4 OFS D:   memory page: 0
0x00008204 13215 4 CortexR4 OFS D:   offset in file: 3968 or 0xf80
0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: .const
0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 1066, or 0x42a
0x00008204 13215 4 CortexR4 OFS D:   load location: 0x4578
0x00008204 13215 4 CortexR4 OFS D:   run location: 0x4578
0x00008204 13215 4 CortexR4 OFS D:   memory page: 0
0x00008204 13215 4 CortexR4 OFS D:   offset in file: 16376 or 0x3ff8
0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: .cinit
0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 64, or 0x40
0x00008204 13215 4 CortexR4 OFS D:   load location: 0x49a8
0x00008204 13215 4 CortexR4 OFS D:   run location: 0x49a8
0x00008204 13216 4 CortexR4 OFS D:   memory page: 0
0x00008204 13216 4 CortexR4 OFS D:   offset in file: 17448 or 0x4428
0x00008204 13216 4 CortexR4 OFS D: OFS Section added:  name: .pinit
0x00008204 13216 4 CortexR4 OFS D:   size in bytes: 0, or 0x0
0x00008204 13216 4 CortexR4 OFS D:   load location: 0x0
0x00008204 13216 4 CortexR4 OFS D:   run location: 0x0
0x00008204 13216 4 CortexR4 OFS D:   memory page: 0

... more sections follow

    Meanwhile, armofd on the same binary gives this:

     Section Information

    id name                      load addr  run addr      size align alloc
    -- ----                      ---------  --------      ---- ----- -----
     0 (no name)                 0x00000000 0x00000000     0x0     0   N  
     1 .intvecs                  0x00000000 0x00000000    0x20     4   Y  
     2 flashAPI                  0x00000020 0x08002000   0xf28     4   Y  
     3 .text                     0x00001500 0x00001500  0x3078     4   Y  
     4 .const                    0x00004578 0x00004578   0x42a     4   Y  
     5 .cinit                    0x000049a8 0x000049a8    0x40     8   Y  
     6 .pinit                    0x00000000 0x00000000     0x0     1   N  
     7 .data                     0x08002f28 0x08002f28   0x431     4   Y  
     8 .bss                      0x0800335c 0x0800335c    0x94     4   Y  
     9 .TI.noinit                0x00000000 0x00000000     0x0     1   N  
    10 .TI.persistent            0x00000000 0x00000000     0x0     1   N  
    11 __llvm_prf_cnts           0x08002000 0x08002000     0x0     1   Y  
    12 .debug_info               0x00000000 0x00000000 0x1a029     1   N  
    13 .debug_line               0x00000000 0x00000000  0x3da1     1   N  
    14 .debug_frame              0x00000000 0x00000000   0xdc5     4   N  
    15 .debug_abbrev             0x00000000 0x00000000  0x2fcd     1   N  
    16 .debug_str                0x00000000 0x00000000  0x8553     1   N  
    17 .debug_aranges            0x00000000 0x00000000   0x7c8     1   N  
    18 .debug_pubnames           0x00000000 0x00000000  0x12da     1   N  
    19 .debug_pubtypes           0x00000000 0x00000000  0x1c6e     1   N  
    20 Veneer$$CMSE              0x00000000 0x00000000     0x0     1   N  
    21 .ARM.attributes           0x00000000 0x00000000    0x57     0   N  
    22 .symtab                   0x00000000 0x00000000  0x5fe0     0   N  
    23 .TI.section.flags         0x00000000 0x00000000    0x1e     0   N  
    24 .strtab                   0x00000000 0x00000000  0x1922     0   N  
    25 .shstrtab                 0x00000000 0x00000000   0x119     0   N

    Note the discrepancy in the load address of FlashAPI section.

  • 0 in reply to Jack Cochran
    Guru 92251 points
    Jack Cochran said:
    Note the discrepancy in the load address of FlashAPI section.

    Agree that the discrepancy in the load address of flashAPI section appears to be the issue:

    1. armofd reports the load address is 0x00000020 (flash) and the run address is 0x08002000 (SRAM) which is correct
    2. The CCS DebugServer logs report the load address and run address are both 0x8002000 (SRAM) which is incorrect , and could explain why the flashAPI section doesn't get programmed to flash.
    Jack Cochran said:
    I will have to look into the Segger release notes later.

    Given the discrepancy you have found with the load address in the CCS DebugServer logs I don't think the Segger software is the issue. If you looked at the J-Link log file expect it would show the Segger software is being told by the CCS 11 DebugServer to write the flashAPI section to its run address in SRAM, rather than its load address in flash.

    Jack Cochran said:
    I don't think I can upload the full linker command file to a public forum, but I can confirm that I see the same problem with the spna193 UART Bootloader example for LS31x devices.

    Hopefully, TI will be able to repeat the problem with UART bootloader example for LS31x devices and investigate.

  • 0 in reply to Chester Gillon
    Guru 92251 points
    Chester Gillon said:
    Will try and recreate the problem by changing to the TI compiler / debug probe used / different device to see what the trigger is.

    I created the example_TI_Fee_Write_Read.c example for a TMS570LS0432 using HALCoGen 04.07.01, and edited the sys_link.cmd linker command file to set the flash API with load address in flash and a run address in ram:

    /* USER CODE BEGIN (4) */
   flashAPI : fill = 0xFFFFFFFF // This guarantees that the holes will be filled with this value.
   {
     Fapi_UserDefinedFunctions.obj (.text)
     *F021_API_CortexR4_BE.lib (.text)
   } load = FLASH0, run = RAM, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)
/* USER CODE END */

    The linker map file shows the flashAPI section having a load address of 0x0000d4e0 in flash and a run address of 0x08001500 in ram:

    SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    0000d4e0   0000d4e0    r-x
  00000000    00000000    00000020   00000020    r-x .intvecs
  00000020    00000020    0000d4c0   0000d4c0    r-x .text
0000dc78    0000dc78    00003150   00003150    r-x
  0000dc78    0000dc78    00002ef0   00002ef0    r-x FEE_TEXT_SECTION
  00010b68    00010b68    00000180   00000180    r-- .const
  00010ce8    00010ce8    000000a0   000000a0    r-- FEE_CONST_SECTION
  00010d88    00010d88    00000040   00000040    r-- .cinit
08001500    0000d4e0    00000798   00000798    r-x
  08001500    0000d4e0    00000798   00000798    r-x flashAPI
08001c98    08001c98    00000208   00000000    rw-
  08001c98    08001c98    00000131   00000000    rw- FEE_DATA_SECTION
  08001dcc    08001dcc    0000006e   00000000    rw- .data
  08001e3a    08001e3a    00000066   00000000    rw- .bss

    This was run in a LAUNCHXL-TMS57004, using the on-board XDS100v2.

    With CCS 11.0.0.00012 under Windows 10 can repeat the problem:

    1. In the CCS properties under Debug -> Flash settings ticked "Enable Verbose Output". The output when CCS flashed the program when started a debug session did appear to show Writing Flash which covered the load address of the flashAPI section:

    CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
CortexR4: Writing Flash @ Address 0x00000000 of Length 0x00007ff0
CortexR4: Erasing Flash Bank 0, Sector 0
CortexR4: Erasing Flash Bank 0, Sector 1
CortexR4: Erasing Flash Bank 0, Sector 2
CortexR4: Erasing Flash Bank 0, Sector 3
CortexR4: Erasing Flash Bank 0, Sector 4
CortexR4: Erasing Flash Bank 0, Sector 5
CortexR4: Erasing Flash Bank 0, Sector 6
CortexR4: Erasing Flash Bank 0, Sector 7
CortexR4: Erasing Flash Bank 0, Sector 8
CortexR4: Erasing Flash Bank 0, Sector 9
CortexR4: Erasing Flash Bank 0, Sector 10
CortexR4: Erasing Flash Bank 0, Sector 11
CortexR4: Erasing Flash Bank 0, Sector 12
CortexR4: Erasing Flash Bank 0, Sector 13
CortexR4: Erasing Flash Bank 0, Sector 14
CortexR4: Erasing Flash Bank 7, Sector 0
CortexR4: Erasing Flash Bank 7, Sector 1
CortexR4: Erasing Flash Bank 7, Sector 2
CortexR4: Erasing Flash Bank 7, Sector 3
CortexR4: Verifying Flash @ Address 0x00000000 of length 0x00004D00
CortexR4: Verifying Flash @ Address 0x00004D00 of length 0x000032F0
CortexR4: Writing Flash @ Address 0x00007ff0 of Length 0x000054f0
CortexR4: Verifying Flash @ Address 0x00007FF0 of length 0x00004D00
CortexR4: Verifying Flash @ Address 0x0000CCF0 of length 0x000007F0
CortexR4: Writing Flash @ Address 0x0000dc78 of Length 0x00003150
CortexR4: Verifying Flash @ Address 0x0000DC78 of length 0x00003150

    2. When the program halted at the start of main(), verifying the program failed with:

    CortexR4: File Loader: Verification failed: Values at address 0x08001500 do not match Please verify target memory and memory map.

    3. If attempted to run the program failed with an undefined instruction exception, this is because the flashAPI section which is copied from flash to ram contains all 0xff.

    4. Looking in the CCS debug server log can see the following for flashAPI section, which has incorrectly reported the load location as 0x8001500 in ram, rather than 0x0000d4e0 in flash:

    0x0000209C 13194 4 CortexR4 OFS D: OFS Section added:  name: flashAPI
0x0000209C 13194 4 CortexR4 OFS D:   size in bytes: 1944, or 0x798
0x0000209C 13194 4 CortexR4 OFS D:   load location: 0x8001500
0x0000209C 13194 4 CortexR4 OFS D:   run location: 0x8001500
0x0000209C 13194 4 CortexR4 OFS D:   memory page: 0
0x0000209C 13194 4 CortexR4 OFS D:   offset in file: 54548 or 0xd514

    And also:

    0x0000209C 13194 4 CortexR4 OFS D: Program Header contents @ index 1
0x0000209C 13194 4 CortexR4 OFS I: p_type: 0x00000001
0x0000209C 13194 4 CortexR4 OFS I: p_offset: 0x0000d514
0x0000209C 13194 4 CortexR4 OFS I: p_vaddr: 0x08001500
0x0000209C 13194 4 CortexR4 OFS I: p_paddr: 0x0000d4e0
0x0000209C 13194 4 CortexR4 OFS I: p_filesz: 0x00000798
0x0000209C 13194 4 CortexR4 OFS I: p_memsz: 0x00000798
0x0000209C 13194 4 CortexR4 OFS I: p_flags: 0x00000005
0x0000209C 13194 4 CortexR4 OFS I: p_align: 0x00000004
0x0000209C 13194 4 CortexR4 OFS I: PT_LOAD: 
0x0000209C 13194 4 CortexR4 OFS D: OFS LOAD Section added:  name: .text
0x0000209C 13194 4 CortexR4 OFS D:   size in bytes: 1944, or 0x798
0x0000209C 13194 4 CortexR4 OFS D:   load location: 0x8001500
0x0000209C 13194 4 CortexR4 OFS D:   run location: 0x8001500
0x0000209C 13194 4 CortexR4 OFS D:   memory page: 0
0x0000209C 13194 4 CortexR4 OFS D:   offset in file: 54548 or 0xd514

    The example used is attached, and the debug_server.log file is that produced by CCS 11.0

    TMS570LS0432_TI_fee_read_write.zip

    The example works OK when using CCS 10.4.0.00006 under Windows 10.

  • 0 in reply to Chester Gillon
    Guru 92251 points
    Chester Gillon said:
    With CCS 11.0.0.00012 under Windows 10 can repeat the problem:

    Can also repeat the same failure using the above example with CCS 11.0.0.00012 under Linux.

  • 0 in reply to Chester Gillon
    Guru 92251 points
    Chester Gillon said:

    This was run in a LAUNCHXL-TMS57004, using the on-board XDS100v2.

    With CCS 11.0.0.00012 under Windows 10 can repeat the problem:

    The TMS570LS0432_TI_fee_read_write.zip which showed the problem in CCS 11.0 used a BE32 TMS570LS0432.

    The sample example was created to run on the LE RM42L432 in LAUNCHXL-RM42 using the on-board XDS100v2, in the attached project.

    The example which runs on the RM42L432 doesn't show the problem in CCS 11.0. Therefore, perhaps the issue in CCS 11.1 with not correctly reading the load address from an ELF image only occurs for big-endian devices.

    For the RM42L432 the linker map file has the following for the flashAPI section:

    SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    0000d4d4   0000d4d4    r-x
  00000000    00000000    00000020   00000020    r-x .intvecs
  00000020    00000020    0000d4b4   0000d4b4    r-x .text
0000dc74    0000dc74    00003100   00003100    r-x
  0000dc74    0000dc74    00002ee0   00002ee0    r-x FEE_TEXT_SECTION
  00010b54    00010b54    00000180   00000180    r-- .const
  00010cd4    00010cd4    000000a0   000000a0    r-- FEE_CONST_SECTION
00010d78    00010d78    00000040   00000040    r--
  00010d78    00010d78    00000040   00000040    r-- .cinit
08001500    0000d4d4    000007a0   000007a0    r-x
  08001500    0000d4d4    000007a0   000007a0    r-x flashAPI
08001ca0    08001ca0    00000208   00000000    rw-
  08001ca0    08001ca0    00000131   00000000    rw- FEE_DATA_SECTION
  08001dd4    08001dd4    0000006e   00000000    rw- .data
  08001e42    08001e42    00000066   00000000    rw- .bss

    The CCS 11.0 debug_server.log does show the following for the flashAPI section which has the load location incorrectly reported as 0x8001500 :

    0x000004DC 11228 4 CortexR4 OFS D: OFS Section added:  name: flashAPI
0x000004DC 11228 4 CortexR4 OFS D:   size in bytes: 1952, or 0x7a0
0x000004DC 11228 4 CortexR4 OFS D:   load location: 0x8001500
0x000004DC 11228 4 CortexR4 OFS D:   run location: 0x8001500
0x000004DC 11228 4 CortexR4 OFS D:   memory page: 0
0x000004DC 11228 4 CortexR4 OFS D:   offset in file: 54536 or 0xd508

    However, the debug_server.log later has the following which gives the correct load location as 0x0000d4d4:

    0x000004DC 11230 4 CortexR4 OFS D: Program Header contents @ index 1
0x000004DC 11230 4 CortexR4 OFS I: p_type: 0x00000001
0x000004DC 11230 4 CortexR4 OFS I: p_offset: 0x0000d508
0x000004DC 11230 4 CortexR4 OFS I: p_vaddr: 0x08001500
0x000004DC 11230 4 CortexR4 OFS I: p_paddr: 0x0000d4d4
0x000004DC 11230 4 CortexR4 OFS I: p_filesz: 0x000007a0
0x000004DC 11230 4 CortexR4 OFS I: p_memsz: 0x000007a0
0x000004DC 11230 4 CortexR4 OFS I: p_flags: 0x00000005
0x000004DC 11230 4 CortexR4 OFS I: p_align: 0x00000004
0x000004DC 11230 4 CortexR4 OFS I: PT_LOAD: 
0x000004DC 11230 4 CortexR4 OFS D: OFS LOAD Section added:  name: .text
0x000004DC 11230 4 CortexR4 OFS D:   size in bytes: 1952, or 0x7a0
0x000004DC 11230 4 CortexR4 OFS D:   load location: 0xd4d4
0x000004DC 11230 4 CortexR4 OFS D:   run location: 0x8001500
0x000004DC 11230 4 CortexR4 OFS D:   memory page: 0
0x000004DC 11230 4 CortexR4 OFS D:   offset in file: 54536 or 0xd508

    RM42L432_TI_fee_read_write.zip

  • 0 in reply to Chester Gillon
    TI__Guru**** 463831 points

    Thank you Chester for the excellent test case. I can reproduce the issue also. 

    I have filed a bug for this. Tracking link: https://sir.ext.ti.com/jira/browse/EXT_EP-10633

    Please see the above link for details on how to work around the issue.

    Thanks

    ki