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:CCS GEL 文件中指定的 ROM 大小与 TM4C 器件中实际的 ROM 大小之间存在差异

Guru**** 2322270 points
Other Parts Discussed in Thread: TM4C123GH6PM, TM4C1294NCPDT
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/587445/ccs-tm4c1294ncpdt-discrepancy-between-the-rom-size-specified-in-ccs-gel-files-and-the-actual-rom-size-in-tm4c-devices

器件型号:TM4C1294NCPDT
主题中讨论的其他器件:TM4C123TM4C123GH6PM

工具/软件:Code Composer Studio

在 CCS 7.1.0.00016安装中 、所有 TM4C123和 TM4C129器件的 ROM 大小在 GEL 文件中指定为0x00008c00字节:

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

从数据表中不确定实际的 ROM 大小、但运行测试程序、从0x01000000 ROM 基址 开始的递增地址读取数据、直到出现总线故障、ROM 大小为:

- ROM 版本 为0x26e 时、TM4C123GH6PM 的0x8800字节

- 0xe700字节、用于 ROM 版本 为0x301的 TM4C1294NCPDT

GEL 文件中的存储器映射旨在阻止 CCS 调试器访问地址、这会因未映射而导致总线故障。 由于器件中的实际 ROM 大小与在调试使用 ROM 函数的程序期间 GEL 文件中的存储器映射中指定的大小不同:

a)对于 TM4C123GH6PM、GEL 存储器映射大于实际器件 ROM、这会导致调试器报告形式为"Cortex_M4_0:读取长度0x2d8第0页上0x1008800处的存储器块时遇到问题: 调试端口错误"。  0x01008BFF、在 GEL 文件存储器映射中标记为可读 ROM 空间、但实际上并未映射到存储器。

b)对于 TM4C1294NCPDT、GEL 存储器映射小于实际器件 ROM。 如果程序在 ROM 函数内的 GEL 文件存储器映射中未标记为可读的地址处停止、则 CCS 调试器会报告"Memory map prevented reading"、而不是反汇编 ROM 函数。 例如  、ROM 版本0x301中地址为0x1009fe2的 ROM_UARTCharPut 函数可能会发生这种情况。

 TM4C123和 TM4C129器件的实际 ROM 大小是固定的、以便可以更新 CCS GEL 文件以匹配 ROM 大小、还是 ROM 大小可以随器件版本的变化而变化?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 USER="Chester Gillon"> TM4C123和 TM4C129器件的实际 ROM 大小是否已修复、以便可以更新 CCS GEL 文件以匹配 ROM 大小、或者 ROM 大小是否会随器件版本而变化?找到一些 ROM 大小如下的 LM4F 器件:

    - 0x8c00字节、用于 ROM 版本 为0x1a9的 LM4F232H5QD

    -对于 ROM 版本 为0x1c0的 LM4F120H5QR、为0x8c00字节

    因此、不同版本的 ROM 大小可能会有所不同。 此外、 0x8c00字节的 ROM 大小与 CCS 7.1 GEL 文件中指定的大小相匹配。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    切斯特、您好!
    我建议在循环中使用(*((uint32_t)*) 0x01000000读取命令对几行进行编码、当发生异常时、您可以在代码中捕获异常之前的最后一个可用地址、然后在主应用程序代码中的#define (s)中将此地址空间用作指南。
    祝你一切顺利、
    John
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 user="John Piliounis">我建议在循环中使用(*((UINT32_t)*) 0x01000000读取命令对几行进行编码,当发生异常时, 您可以在代码中进行陷阱、打印例外前的最后可用地址、然后在主应用程序代码中的#define (定义)中将此地址空间用作指南。我执行了与第一种方法类似的操作、 它将尝试读取的最后一个地址存储在全局变量中、并使故障处理程序显示已读取的最后一个地址。 这种方法的问题是、程序在硬故障处理程序中被终止。

    通过查看 Cortex-M 异常处理的选项、您可以通过设置 BFHFNMIGN 位 FAULTMASK 位来使器件忽略总线故障、从而探测地址是否可访问、然后相应地继续执行程序。  

    在附加的 CCS 工程中,该方法在 Read_probe ()中执行,该函数被调用以确定器件中 ROM 的实际大小。  e2e.ti.com/.../TM4C_5F00_find_5F00_rom_5F00_size.zip

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Chester。

    这是我的观点。 可以利用 Cortex-M4单元的异常处理机制、避免意外的程序崩溃。 例如在 C#和 C++中使用"尝试/捕捉"机制。  

    让我们都乐在其中、使用 TM4C1294xxxxx 器件吧。 祝你一切顺利、

    John

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    在相关的注释中、TM4C1294[KN]CPDT 的数据表中 ROM 的地址错误。 第103页将0x02000000.0x02FFFFFF 显示为 ROM 的存储器范围、但我们知道 ROM 实际上从0x01000000开始。 数据表的其他部分给出了正确的地址。 也许我应该为数据表错误启动一个新的线程。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Brian、
    谢谢你。 我已记下数据表误差。