• 状态 Resolved
  • 已锁定 已锁定
  • 回复 10 回复
  • 订户 0 订户
  • 视图 276 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] EK-TM4C1294XL：STR.w 导致未对齐的内存访问

admin
Guru**** 2473270 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/683276/ek-tm4c1294xl-str-w-leads-to-unaligned-memory-access

器件型号：EK-TM4C1294XL

您好！

在我的 TM4C1294XL 程序中有一条指令

0xF8420021：str.w r0、[R2、R1、LSL #2]
使用
R0 = 0x00000001
R1 = 0x00000000
R2 = 0x20012AD1

该指令是从 C 行汇编的

grandedeQoos[(*count)+]]= readChar (&curdata)；

并且可能构成数组元素的存储过程。 但是、执行该指令会立即导致硬故障故障故障。故障类型是未对齐的存储器访问、我可以看到这是因为 UFSR = 0x0100。

现在、我的问题是该指令到底是什么作用？ 它是否计算 R2+R1并将结果左移2位？ 那么、在我看来、不会发生未对齐的存储器访问。

此致

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

    调试 C 代码我发现问题可能是 granedQoS 存储在地址0x20012AD1中。 在未对齐的地址存储变量是否甚至有效？

  • 0
    TI__Guru**** 2473270 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    回答问题的最佳方法是向您指出《ARMv7架构参考手册》：
    static.docs.arm.com/.../DDI0403E_B_armv7m_arm.pdf
    具体而言、该指令将 r0的内容存储在 R2内容和 R1内容之和指向的位置、然后将其向左移位两个位置。 由于 R2的内容为奇数、这是一个32位存储、这显然是一个未对齐的写入。
  • 0
    TI__Guru**** 2473270 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    感谢您的回复。 进一步分析 C 代码、我发现 grandedQoS 存储在地址0x20012AD1中、据我所知、这不是一个有效地址。

    声明如下： 

    typedef 结构体 MQTTSubbackData
｛
枚举 QoS 格式化 QoS；
｝MQTTSubbackData；

...

MQTTSubbackData 数据；

  • 0
    TI__Guru**** 2473270 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    使用编译器优化级别0可以解决该问题。 我可以在某个位置为编译器提交错误报告吗？
  • 0
    TI__Guru**** 2473270 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    首先、您使用的是什么编译器？ 我不相信这是编译器问题。 0x20012AD1是有效的 RAM 地址。 可能是设置或类型转换问题。
  • 0
    TI__Guru**** 2473270 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我使用 CCS V8。

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

    是的、但您使用的是哪种编译器？ 您可以通过右键点击"Project Explorer"窗口中的工程并选择"Show Build Settings"来找到该文件。 在下图中、显示了使用 TI 编译器版本16.9.x。

    您能否提供更多信息提供重新创建此问题的示例项目？

  • 0
    TI__Guru**** 2473270 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我的编译器版本是 TI v18.1.1 LTS。 该项目是用于 TM4C1294XL 上的 TI RTOS 的 Eclipse 泛美卫生组织嵌入式 C 客户端。
    访问从枚举中发出的 int[]后、问题就会出现。 我可以在接下来的几天内提供一个示例项目。
  • 0
    TI__Guru**** 2473270 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我想您刚才告诉我关键部分。 默认情况下、编译器使用打包枚举。 如果枚举可以以8位表示、则表示为。 这节省了空间、但允许枚举位于字节边界上。 将枚举指针强制转换为无符号整型指针时，编译器现在将生成对奇字节边界的32位写操作。 您可以在"ARM 编译器"->"Advanced Options""->"Runtime Model Options"设置中更改枚举的处理方式。 将枚举类型从 packed 更改为 int、如图所示。 这会导致一些内存效率低下。 您可能需要重写代码、以便在存储变量之前将其转换为正确的枚举类型。

  • 0
    TI__Guru**** 2473270 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    非常感谢！ 这就巧妙地解决了我的问题。 感谢您的大力支持！

    此致