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.

[参考译文] TM4C1294KCPDT:CFGCTRL MAINPEND SWTRIG

Guru**** 2562120 points
Other Parts Discussed in Thread: TM4C1294KCPDT

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/785713/tm4c1294kcpdt-cfgctrl-mainpend-swtrig

器件型号:TM4C1294KCPDT

当    CFGCTRL (REG60) MAINPEND 位(第175页) 从未置位时、向 SWTRIG REG52 (第163页)重复的非特权 SW 写入操作如何不会导致 NMI 异常?

几次读取数据表后、似乎是合理的、为 SW 启用特权模式的唯一方法 是为   默认存储器映射启用 MPU (表2-4)。 即使从未在 任何曾经使用 SWTRIG REG52的 Tivaware 示例中配置 MPU、 也应根据数据表导致 NMI 异常 BUSFAULT。 那么、MAINPEND 的设置方式或位置如何允许特权写入需要解锁密钥的其他寄存器以进行对齐写入、例如 REG58和其他寄存器确实需要密钥? 如果 MAINPEND 位从未被 SWTRIG 的软件写入首先置位、那么似乎需要一个解锁密钥来访问 SWTRIG?

特别关注蓝色:

3.4 NVIC 寄存器说明
本节按照地址偏移量由小到大的顺序依次详细介绍 NVIC 寄存器。
NVIC 寄存器只能在特权模式下完全访问、但是可以挂起中断
在非特权模式下、通过启用配置和控制(CFGCTRL)寄存器来实现。 任何
其他非特权模式访问会导致总线故障。
确保软件使用正确对齐的寄存器访问。 处理器不支持未对齐
访问 NVIC 寄存器。
即使中断被禁用、也可以进入挂起状态。
在对 VTABLE 寄存器进行编程以重新定位向量表之前、请确保向量表
新向量表的条目针对故障处理程序、NMI 和所有启用的异常进行设置
中断。 更多信息、请参阅第170页。

 

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

    您好 BP101:

     您能否检查控制寄存器(REG21)。 它将告诉您您是否处于特权模式。

     至于"中断即使被禁用也可以进入暂挂状态"这句话、您对此有何疑问? 我认为这种说法没有问题。 它只是说中断可以挂起。 PENDx 寄存器在接收到来自外设的中断请求后可以置位。 但是、这并不意味着内核将会发生异常、直到中断被启用。 这与外设中的 RIS 寄存器和 IM 寄存器没有什么不同。 RIS (与内核中的 PENDx 寄存器类似)寄存器可以置位、但如果没有 IM (启用中断)、就不会产生中断请求。  

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

    您好、Charles、

    [报价用户="Charles Tsaaaa">您能否检查控制寄存器(REG21)。 它将告诉您您您是否处于特权模式

    寄存器21 POR 0 = 只有特权级软件才能在线程模式下执行。

      根据数据表、在 POR 之后、MCU 自动从处理程序模式切换到线程模式。 那么、有什么 Tivaware 示例工程、甚至是使用具有 信标 SWTRIG 中断的 LWIP 1.4.1的示例工程、如何在 REG21中设置 Tmpl 位?   如果 MCU 处于非特权模式、其他 SWTRIG SW 中断如何挂起和激活?  似乎 MCU 始终处于特权模式、或者 SWTRIG 中断永远不会挂起、其行为就像被禁用一样、但它们却没有被禁用。 这似乎表明、如本论坛以及 下面的主题所述、NVIC 处理子优先级的问题也会失败!

    [引用用户="Charles Tsaaa"]关于"中断即使被禁用也可以进入挂起状态"的说法,您对此有什么疑问?

    本声明是在 NVIC 的上下文中作出 的、如果 CPU 不处于特权模式、则可能会解释 NVIC 的 REG21 SWTRIG 问题。  在   首次尝试 AHB 仲裁访问后、在 NVIC 处理和处理非法外设挂起期间、被禁用的中断仍然可以挂起并切换回激活模式、并且不会在此过程中标记总线故障。

    我最近发布 了一个有关在进入处理程序清除中断后禁用边沿计数器的问题、该中断允许 在  仅 重新启用边沿计数中断的500ms 期间重新进入。 在   从 边沿计数 器中断上下文启动的500ms OneShot 内、控制次优先级中断控制下另一个计时器的中断状态的500ms 延迟失败。   边沿计数器和一次激发子优先级被 NVIC 忽略、为什么?

    它可能与 SWTRIG REG21对子优先级中断组的非法访问有什么关系 、以某种方式污染   3:5拆分的 NVIC 单个子优先级?  多少次非法 NVIC 子优先级访问 违反了 ARM cortex AHB 仲裁规则和 256级的任何 单个中断、从而在 TI 修改 的 REG58 [10:8]位拆分中只有3个位的处理中造成了混乱?  当  高优先 级分组 中断处理程序 开始仲裁 AHB 上的数据/地址空间时、NVIC 如何加快低优先级中断的处理速度?   如果任何事情都 应该减速、那么该行为就会超出合理逻辑的任何低优先级分组处理程序的范围。

    我想说这是上述声明的一个很好的例子 、但 仍然不清楚 为什么 说它是与 SWTRIG 寄存器的保护模式相关的链接。   

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

    确保软件使用正确对齐的寄存器访问。 处理器不支持对 NVIC 寄存器进行非对齐访问。

    或者、如何通过 UINT32_t (DWORD)写入来设置外设_MIS 位、从而保持16位(字)对齐访问以抢占 NVIC? 因此、NVIC 可能无法完全支持通过 AHB 写入其寄存器的未对齐 DWORD 中断请求、但仍然挂起请求、但 AHB 仲裁处理没有子优先级。

    数据表似乎暗示了对齐寄存器访问和不对齐寄存器访问之间的差异直接信息字长决定了每个访问模式。 如果确实如此、Tivaware HWREG 会调用具有未对齐访问的 NVIC。

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

    表2-10还显示了 EXC_RETURN 行为(线程/处理程序)模式、并且在 RST 之后从处理程序进入时似乎0x0被设置为 LR。

    奇怪的(下面)只能看到 BX 指令和 LR 调用_C_INT00、但复位后没有 EXC_RETURN 值行为被设置为 LR。 同样、当较高优先级的 INT 组断言处理程序(PWM0、ADC0、GPTM4)使较低优先级的处理程序断言挂起有效时、它们会加速这些处理程序。 可能是由于通过 Lr 的非特权模式默认行为进行非法的 SWPEND [15:0] DWORD 访问造成的? 谁知道 NVIC 在做什么、但如果挂起或取消挂起相对 MSP/PSP 出现时似乎始终处于处理模式、他确定优先级组不会按预期处理。

    2.5.7.1.
    同时、处理器向 LR 写入 EXC_RETURN 值、指示哪个堆栈指针对应于堆栈帧、以及处理器在进入发生前处于何种操作模式。 如果在异常进入期间没有更高优先级的异常发生、处理器开始执行异常处理程序、并自动将相应挂起中断的状态更改为激活。 (例如、即使已禁用????)
    如果在异常进入期间发生另一个更高优先级的异常、称为延迟到达、处理器开始执行该异常的异常处理程序、并且不会改变先前异常的挂起状态。


    386;------------------------------------------------
    387.
    388
    389;*函数名:ResetISR *
    390;*
    391 ;*修改的寄存器:*
    392 ;* Regs Used : LR *
    393;*本地帧大小:0 args + 0 Auto + 0 Save = 0字节*
    ??****394 *
    395 00000000 ResetISR:
    396;*-------------------------------------------------------------- *
    397 dwcfi CFA_offset、0
    398 .global _c_int00
    399 00000000 BFFEF7FF! b.w _c_int00;[保留32位 ins]
    400 $C$DW$28 .dwtag DW_TAG_TI_BRANCH
    401 .dwattr $C$DW$28、DW_AT_LOW_PC (0x00)
    402 .dwattr $C$DW$28、DW_AT_TI_RETURN
    403 00000004 4770 BX LR;[DPU_3_PIPE];[ORIG 16位 INS]
    404;分支发生;[]
    405 .dwattr $C$DW$27、DW_AT_TI_END_FILE ("../tm4c1294kcpdt_startup_ccs.c")
    406 .dwattr $C$DW$27、DW_AT_TI_END_LINE (0xf8)
    407 .dwattr $C$DW$27、DW_AT_TI_END_COLUMN (0x01)
    408. dwendentry
    409 .dwendtag $C$DW$27

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

    不需要在点 BX 之后跟随 lr 指令、或者(可能)在不应该强制将"重置线程"模式恢复到处理程序中。 由于数据表控制分析意味着 CPU 自动进入 Thread 特权模式、而不是强制将 LR 加载到所需的 Thread 模式。 请随意将此帖子转移到新主题、因为它确实会跳转到新主题、但 仍然与 NVIC 的行为不符合预期的同一问题相关。  

    我再次返回 NVIC 子优先级顺序(AIRCR) AKA REG58表3-9不同于 ARM Cortex M4v7技术参考表 B1-7。 TM4C1294x 数据表表表表表3-9未完全解释看起来 M4v7 NVIC 优先级架构中不存在的 Tivaware 子优先级分组拆分(4:4、3:5)。 ARM 怎么说也怎么说、而 TI 却说与 ARM B1-7完全相反的表3-9? 为什么 TI 会尝试通过更改 M4v7 Arm Cortex NVIC 中已配置的子优先级中断分组来混淆社区? 从逻辑上来说、似乎是发生了什么!  

    ARM 技术参考显示了由 3位[10:8]设定的8个优先级组级别。  但是 、我们仍然必须配置7:5/7:4拆分中子优先级中断字段的低4:0位。 Tivaware IntPrioritySet()配置中断级别优先级与组相同。 似乎只针对每个特定中断子优先级分配将高3组位移入低4位。 Tivaware IntPrioritySet()错误地为同一分组中的所有中断分配了相同的子优先级,因此与 AIRCR [10:8]位指定的4:0子优先级位设置的 AIRCR 拆分和子优先级发生冲突。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    似乎 ARM 表 B1-7建议7:5拆分任何单优先级分组都可以分配[4:0]位{INA、INTB、INTC、INTD}、从而产生16级的子优先级、而不是如表3-9所示的简单1级。 AIRCR 7:5分离较低的[4:0]位与外设_MIS 处理速度的中断应用程序处理有何关系当较高优先级的异常相对于 AHB 总线仲裁断言时、对较低优先级组的增加如何保持未应答。

    同样、如果有任何降低应用处理速度的因素、较低优先级的外设 MIS 组也应如此。 不会随着更高优先级的中断挂起而加速、从而立即在 NVIC 中将一个激活状态置为有效。 特别是对于较慢的延迟到达(30Hz)、较低优先级组中已存在尾链的情况、应根据 ARM 优先级处理分离架构降低速度。