• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 962 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.

CCS/TM4C1294NCPDT: Discrepancy between the ROM size specified in CCS GEL files and the actual ROM size in TM4C devices

Chester Gillon
Guru 92251 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: TM4C123GH6PM,

Tool/software: Code Composer Studio

In a CCS 7.1.0.00016 installation the ROM size for all TM4C123 and TM4C129 devices is specified as 0x00008c00 bytes in the GEL files:

    GEL_MapAddStr(0x01000000, 0, 0x00008c00, "R", 0);  /* ROM */

From the datasheets not sure of the actual ROM sizes, but running test programs which read from incrementing addresses starting at the ROM base address of 0x01000000 until get a bus fault the ROM sizes are:

- 0x8800 bytes for a TM4C123GH6PM with ROM version 0x26e

- 0xe700 bytes for a TM4C1294NCPDT with ROM version 0x301

The memory map in the GEL files is designed to stop the CCS debugger from accessing addresses which will cause a bus fault due to not being mapped. Since the actual ROM size in the devices differs from the that specified in the memory map in the GEL files during debugging of programs which use ROM functions:

a) For a TM4C123GH6PM the GEL memory map is larger than the actual device ROM, which causes the debugger to report errors of the form "CORTEX_M4_0: Trouble Reading Memory Block at 0x1008800 on Page 0 of Length 0x2d8: Debug Port error occurred" if attempt to read the area of memory from addresses 0x01008800 .. 0x01008BFF which is marked as readable ROM space in the GEL file memory map, but is not actually mapped to memory.

b) For a TM4C1294NCPDT the GEL memory map is smaller than the actual device ROM. If the program is halted inside a ROM function at an address not marked as readable in the GEL file memory map then the CCS debugger reports "Memory map prevented reading" rather than disassembling the ROM function. E.g. can occur for the ROM_UARTCharPut function which is at address 0x1009fe2 in ROM revision 0x301.

Are the actual ROM sizes for TM4C123 and TM4C129 devices fixed so the the CCS GEL files can be updated to match the ROM size, or can the ROM sizes change with device revisions?

  • 0
    Guru 92251 points

    Chester Gillon said:
    Are the actual ROM sizes for TM4C123 and TM4C129 devices fixed so the the CCS GEL files can be updated to match the ROM size, or can the ROM sizes change with device revisions?

    Found some LM4F devices which had the following ROM sizes:

    - 0x8c00 bytes for a LM4F232H5QD with ROM version 0x1a9

    - 0x8c00 bytes for a LM4F120H5QR with ROM version 0x1c0

    Therefore, the ROM size can vary between versions. Also, the ROM size of 0x8c00 bytes matches the size specified in the CCS 7.1 GEL files.

  • 0
    Expert 1690 points
    Hello Chester,
    I would suggest coding some few lines with the (*((uint32_t)*)0x01000000 read command in a loop and when exception occurs, which you can trap in code, print the last available address before exception and then use this address space as a guideline in #define(s) inside your main app's code.
    All the best,
    John
  • 0 in reply to John Piliounis
    Guru 92251 points

    John Piliounis said:
    I would suggest coding some few lines with the (*((uint32_t)*)0x01000000 read command in a loop and when exception occurs, which you can trap in code, print the last available address before exception and then use this address space as a guideline in #define(s) inside your main app's code.

    I did something similar as the first approach, which was to store the last address attempted to be read in a global variable, and make the fault handler display the last address which had been read. The problem with that approach is that the program got terminated in the hard-fault handler.

    On looking at the options for Cortex-M exception handling found that you can make the device ignore bus-faults by setting the BFHFNMIGN bit FAULTMASK bits and thus probe if an address is accessible and then continue the program accordingly. 

    In the attached CCS project that approach is performed in the read_probe() which is called to determine the actual size of the ROM in the device. TM4C_find_rom_size.zip

  • 0 in reply to Chester Gillon
    Expert 1690 points

    Hello Chester.

    That was my point . That one can take advantage of the exception handling mechanism of Cortex-M4 units and avoid accidental program crashes. Like in C# and C++ with the use of the "try/catch" mechanism. 

    Let's all have fun with this TM4C1294xxxxx unit. All the best,

    John

  • 0
    Genius 4630 points
    On a related note, the Data Sheet for the TM4C1294[KN]CPDT has the wrong address for the ROM. Page 103 shows 0x02000000.0x02FFFFFF as the memory range for ROM, but as we know the ROM actually starts at 0x01000000. Other parts of the Data Sheet give the correct address. Perhaps I should start a new thread for the Data Sheet error.
  • 0 in reply to Brian Willoughby
    TI__Guru 72500 points
    Brian,
    Thank you. I have made note of the datasheet error.