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.

[参考译文] tm4c123gh下午6:00:IntMasterEnable()和 PRIMASK -中断是否总是在系统复位时被默认启用?

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/605306/tm4c123gh6pm-intmasterenable-and-primask---are-interrupts-always-enabled-by-default-at-system-reset

器件型号:TM4C123GH6PM
主题中讨论的其他器件:TM4C123

我只想确认、在 TM4C123和 TM4C129器件上、系统复位时是否默认启用中断?

我提出这一要求是因为我来自其他嵌入式平台、在这些平台中、默认情况下会禁用中断、并且在其他初始化完成后、必须由软件执行全局中断启用。

这个问题的提示是,即使代码没有调用 IntMasterEnable(),也会为中断提供服务,因此:

我的理解是否正确:TivaWare 函数 IntMasterEnable()将 PRIMASK 设置为0,是否调用 IntMasterEnable()是因为 PRIMASK 在加电时为0?

是否有任何其他因素可以启用或阻止全局处理中断?  (除了 PRIMASK 和任何单独的中断使能)

在软件初始化完成之前、是否有一种可靠的方法来防止发生虚假外设中断? 我在 TM4C 论坛上看到了粘滞文章、建议首先禁用外设、但是在系统复位和被调用此类代码之间、包括 C 运行时库在内的 C 启动代码正在运行、内存为零、调用构造函数等。 这会留下一个窗口、在此窗口中、无论如何都可以发生中断。

谢谢

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

    [引用 user="12ve12pm"]提示此问题的是,即使代码未调用 IntMasterEnable(),[/quot],仍会为中断提供服务

    这是一个很好的观察结果-公司和我早就注意到了-但很明显、"中断被禁用为默认值。"   基于函数"IntMasterEnable()"的(明显)"不执行"(即您通过该函数查看代码时应披露受影响的 MCU 寄存器)来提出这样的诉求在逻辑上是不明智的。    然后、检查这些寄存器就会发现调用该函数的要求-和/或"必须"进行此类调用。"   (如果存在一个函数: "IntMasterDisable()"-并且它已经被调用-那么我怀疑需要调用您引用的函数...)

    在过去的十年中、商/我从未注意到过"软件初始化完成之前发生的假外设中断"。   我们的许多定制电路板/实现控制(非常)高功率器件-并且这种"非法-虚假中断"会被(肯定)注意到。    (或者命运对我们非常友好...)

    我们的经验证实(向我们和客户的想法)、 "只有在专门启用外设中断后"、然后正确触发、特定中断才会启动...

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

    在过去的测试中、我们遇到了同样的问题! 是的、如果不解决问题、结果可能非常"危险"、并且行为有点难调试。

    现在、我们的所有项目都在时钟设置后立即禁用了中断:

    void main (void)
    {
    系统实用程序 Init(120000000);//自定义时钟配置器
    
    MAP_IntMasterDisable();
    MAP_FPUEnable();
    MAP_FULazyStackingEnable();//为中断处理程序启用怠惰堆栈。 

    不过,我不会费心去研究让大师保持活力的"特殊"事件序列。 记住它发生了!

    布鲁诺

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

    我相信、布鲁诺-正如他的代码肯定会揭示的那样-用"不同的"MCU 来表达他的结果! (129x)

    此处的海报和 CB1介绍了"4C123"的操作和灵敏度。

    如果“结果非常危险”-正如您报告的那样-为什么延迟对“IntMasterDisable()”的调用?

    如果您可以"复制"此类"随机中断触发代码-而不是专门启用这些外设中断-这将证明(非常)非常有用、并且您必须记录这样的能力-正如(刚刚)报告的那样、"非常危险!"   (当然、您会记录(任何)危险-您不会这样做吗?)

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我是否可以问您为什么在时钟设置之后而不是以前执行它?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 USER="CB1_MOBILE "]

    然而、很明显、"中断被禁用为默认值。"

    [/报价]

    数据表是否显示了这种情况? 由于至少是我读取中断的方式、因此似乎默认启用了主中断(即使各个外设中断应在系统复位时禁用、这与内核复位不同、因为它们很乐意保持启用状态)

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

    我相信,这将在约瑟夫·耀(基于 ARM)的书中说明,并在 ARM 的网站上注明。

    如果每个中断都"准备就绪"-没有"门控/控制"联锁-在"加电"时(您和布鲁诺(看起来)都相信)-会导致严重破坏-是否不会?

    在时间和兴趣允许的情况下-我将让员工搜索/查找来自 ARM 的"中断管理/启用"语句。

    而轶事-"从不"在(任何)代码示例中注明了对"IntMasterDisable()"的调用-由该供应商提供。   这不仅仅是一个"小"的意思-是不是吗?

    由于公司/我使用来自"四个不同供应商"的 ARM MCU -并且已经设计/构建/测试验证并超过基于13K MCU 的电路板交付-"从不"在我们的任何电路板上注意到"非法进入 ISR "-来自(任何) ARM 供应商...

    在您的“启动(或其他)文件”中出现“IntMasterEnable()”(可能)(伪装)。    然而、该功能机制"单独"不应向"准备好所有中断以进行启动!"证明"必要且足够"

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

    如前所述-您提出了一个好的问题-我介绍了 Joseph Yiu 的著作《ARM Cortex - M3/M4的最终指南》中的以下内容(今天晚上被删除)。   我相信、我所揭示的要点将回答这些问题、并确认我先前的观点:"外设中断未(自动)启用"-当 MCU 退出复位时。   "多个、中断互锁"的概念似乎协同工作以防止(不需要的)外设中断的产生。  (再次-如前所述)

    YU's book -第30页、3.2.2注:"PRIMASK、FAULTMASK 和 BASEPRI 寄存器用于禁用异常。   (中断)  PRIMASK 和 BASEPRI 寄存器对于在时序关键型任务中临时禁用中断很有用。"   提供了一个表(3.2)-和注释"PRIMASK -一个1位寄存器、当置位时-允许不可屏蔽(NMI)中断和硬故障异常-所有其他中断被屏蔽。   默认值为"0"-表示未设置屏蔽。   

    因此,您的发现-我的详细搜索未能在4 个不同的项目中找到"IntMasterEnable()",证实了这一点!   我扩展了搜索范围、将 CMSIS 和 ASM 方法(拦截 PRIMASK 的写入)也包括在内-同样、"未找到任何方法。"    因此- Yiu 对 PRIMASK (电位)中断使能的描述证明(最有可能)。   (我公司的所有代码均已成功中断- w/out (曾经)使用了"IntMasterEnable()"。)

    现在、让我们来看看(我的术语-不在耀的书中) "多重、中断互锁"。   为了使外设中断信号从 MCU 引脚"完全传播"到启动中断的 NVIC 控制器、也必须正确配置这些中断。    我展示了两个示例-涵盖两个不同的 MCU 外设(PWM 和计时器)-以支持我的信念。

    ROM_PWMIntEnable (PWM0_BASE、PWM_INT_GEN_0);
    ROM_IntEnable (INT_PWM0_0);

    ROM_TimerIntEnable (WTIMER 0_BASE、TIMER_TIMA_TIMEOUT);
    ROM_IntEnable (INT_WTIME0A);

    请注意、顶部调用链接到特定外设和中断类型。    (我们可能会注意到这是"Peripheral_IntEnable()"。)    第2个调用标识并启用与该外设匹配的特定中断。

    我相信,“只要”以下各项都是真的“中断被发射”。     (这3个元素中的每一个都用作"中断门控"(和门))

    • PRIMASK  必须为"0"
    • 必须已调用"Peripheral_IntEnable()"
    • 对"IntEnable()"的调用必须已经发生

    因此、显示了一个"三级"中断机制、它位于:处理器级别(最高)、外设级别(中间)和中断源级别(最低)。

    此逻辑中可能存在的"缺陷"是两个函数调用指示的操作都"随机 "发生的可能性。   检查相关寄存器并确定此类位设置的"随机、完美风暴"的可能性不会很困难-足以启动"非法"中断。   

    进一步研究耀的书,发现另一个(特别是魔鬼)机制可能会产生「非法」的中断。    "即使中断被禁用、也可能会发生中断挂起稍后设置使能时、挂起的中断可以触发中断序列!   因此、在启用中断之前"检查挂起寄存器是否已设置!"可能很有用。  (您可以在启用该中断之前清除暂挂状态。)"    ( CB1添加了重点内容)  现在-由于外部世界发出信号(可能)在"完全启用外设中断"之前到达-这种"等待中断"可能会解释布鲁诺指出"危险"的原因。   (存在用于检查和清除此类挂起中断的 API 函数)

    在我们的工程院,我们被教导说:“不依赖“缺省行为”,因此,经常和及早使用“IntMasterDisable()”是很有意义的。    然而、我仍然(甚至更进一步)确信、我最初的断言"外设中断未(默认情况下)完全启用"(即使"PRIMASK"默认为"0")已被证明是正确的。    (13k 个 ARM MCU (来自多家供应商)"现场"(且所有(仅限)合法中断)-在这一信念基础上添加"现实世界消防"。。  

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

    我认为这是防范(不需要的)中断的一种特别高效的方法。

    如此处所示-复位后"SYSRESREQ"位默认为"0"。    向该位写入"1"-在"One F掉落"中-重置内核和所有外设-这应足以防止生成非法中断...    这证明远远优于"复位多个外设-一次一个-并"希望"所有外设都被"记住"并接受外设复位的单次(顺序)级联(因此减慢)...

    请注意,该操作与通过的操作不同,"IntMasterDisable()"本身似乎不是某些人希望的"主要保障"。   回想一下、中断可能会被"挂起"、因此当随后启用所有中断级别(处理器、外设和单独)时(可能)发生在后来调用"IntMasterEnable()"时)、多个中断(大多数处于挂起状态)可能同时被启用和释放!   APINT 寄存器-与"SYSRESREQ"一起-在调用"IntMasterEnable( )"之前调用-似乎提供 了"所有方法中最佳且最安全的!"   (通过重置所有外设来实现此类"最佳/最安全"-这样可以  减少调用"IntMasterEnable()"、"地球抖动!"   (即所有外设和单个中断必须(然后)正确且单独启用-这可确保不会发生多个"挂起"中断的"批量启动"!)

    这一结果取自2014年6月12日发布的"TM4C123" MCU 手册-第164页。    (这一切都是由前一个对约瑟夫·耀的书的"深入探讨"引发的-之前提到了...)

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

    [引用 user="12ve12pm "]

    CB1_MOBILE

    然而、很明显、"中断被禁用为默认值。"

    数据表是否显示了这种情况?  [/报价]

    是的-虽然需要"挖掘"、但我很确定确实是这样!    证据如下:   ("真实"但增强的版本: TM4C123手册、 2014年6月12日、第213页)

    您必须注意:"八个中的七个"(标准复位)全部复位 MCU 的外设-从而确保"中断被禁用为默认值!"   (将多个 MCU 复位视为此类"默认"的发起者当然是公平/恰当的。   

    • 您的开场白指出:"在软件初始化完成之前、是否有可靠的方法来防止发生虚假外设中断?

    ARM 有效地预见到了这种情况-"所需中断启用的多个级别"确实证明了"可靠"。

    • 然后,在断言之后,接着又出现了该问题:"系统重置与此类代码被调用之间的时间... (笑声)  这会留下一个窗口、在此窗口中、无论如何都可以发生中断。"

    正如这里所示、"没有这样的窗口"、这个结论"避免"提到或完全理解 "所需中断启用的多级"、这种窗口"关闭"(墙壁打开)!

    正如我昨天晚上写的那样-您对"主处理器中断被"启用"的发现-本身-证明不足以启用任何"外设中断"。   同样、还有一个"三级外设中断互锁机制"、它可以正确地门控"所有这种外设中断"-然后才能"反映到主处理器中断!"

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    @CB1_MOBILE、感谢您的所有输入。 在这里、您已经为我清除了很多内容、我非常感谢您进行的所有搜索。 听起来我得尽快拿到一本约瑟夫·耀的书!

    我们了解到:

    (1) PRIMASK 不是您在其他平台上找到的"全局中断启用"、而是用于实现关键段等的"全局中断禁用"。 这种区分很重要、因为现在、PRIMASK 默认不置位并且中断不会被阻止是合理的。

    (2)需要两条语句来启用外设中断(例如 ROM_PWMIntEnable()后跟 ROM_IntEnable()的示例)背后的逻辑是提供两级中断选通(PRIMASK 是第三级)、以防止(或使极不可能)出现伪中断。

    (3)在使能中断之前、必须先清除挂起的中断标志。 (我认为这对于任何系统都应该是正确的。)

    我对以下几点感到困惑:您说在 APINT 中设置 SYSRESREQ 会使内核和所有外设复位。 但我认为您无法在启动代码中执行此操作、因为复位内核意味着软件将再次从头开始执行、从而进入永无休止的循环、永远不会超过 SYSRESREQ。 不过、这似乎是从软件启动"重新启动"的方式、而不是通过 VECTRESET 启动"重新启动"、这会使外设处于混乱状态。 不过、我必须对此进行测试。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我的朋友-我想相关调查结果的深度、广度和及时性应该符合"验证答案"的标准。

    我既没有暗示也没有指示应在启动代码中完成"在 APINT 中设置 SYSRESREQ "。 相反-我认为这种情况应在调用"IntMasterEnable()"之前发生,即在调用"IntMasterDisable()"之前发生,即在调用"IntMasterDisable()"之后发生。 此方法可确保调用"IntMasterEnable()"不会使处理器泛洪并产生中断-因为每个中断都必须(首先)顺序并启用"compound (复合)"!
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 USER="CB1_MOBILE "]

    我的朋友-我想相关调查结果的深度、广度和及时性应该符合"验证答案"的标准。
    [/报价]

    完成。

    感谢您花时间并投入大量精力来帮助一位随机的陌生人。 我没有想到我的"简单"问题会导致如此多的研究!

    [引用 USER="CB1_MOBILE "]

    我既没有暗示也没有指示应在启动代码中完成"在 APINT 中设置 SYSRESREQ "。 相反-我认为这种情况应在调用"IntMasterEnable()"之前发生,即在调用"IntMasterDisable()"之前发生,即在调用"IntMasterDisable()"之后发生。 此方法可确保调用"IntMasterEnable()"不会使处理器泛洪并产生中断-因为每个中断都必须(首先)顺序并启用"compound (复合)"!

    [/报价]
    我认为这将"重新启动"设备。 但我将对其进行测试并告知您。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 user="12ve12PM">我认为这将"重新启动"设备。 但我将对其进行测试并告知您。

    这是有很大保证的。 如果不是、我认为文档中存在错误。

    Robert

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

    谢谢-非常感谢。   请注意、您考虑周到、能够"感知此问题"、并巧妙地提出您的请求、这与"随机陌生人!"远远不一样!   (更像"技术朋友-在制造中...")

    而且-您可能非常正确-可能会发生"重新启动"。   (然而、MCU 手册是否应该"注意"这样(重要)的事实?)   [它是,"死"沉默!]
    我被它的效率所吸引、"单功能调用-能够复位"所有"外设。"   (在我看来、这远远优于所需的函数调用级联、以检查"所有可能启用(尤其是中断挂起)的外设"。)

    根据时间/业务需求-我将回顾公司采用的"其他"Cortex M4和 M7器件上的类似方面-并报告...   

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我想您已经将 SYSRESREQ 位的设置与软件外设复位相混淆了。 后者不会重置内核、而是根据文档重置内核。

    Robert
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我不这么认为-我的目标是"确保所有外设的复位-理想情况下、一次即可!" 实现了这一目标!

    我在 MCU 手册中包括了一张图表(最多6-7篇文章),其中详细说明了...
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 USER="CB1_MOBILE "]我不这么认为-我的目标是"确保所有外设的复位-理想情况下一次复位!" 实现了这一目标!

    我在 MCU 手册中添加了一个图表(最多6-7个帖子)、其中详细说明了...

    这是我要参考的表(也在我的手册中)。 它记录了 SYSRESREQ 复位内核(IE 微控制器复位)。

    Robert

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    你和 O.P.(现在)都已确定了这一事实。 然而、在 O.P.的最初职位中、他表示有兴趣-如果不关心的话-请回复(同时)核心和外设复位。 他的问题的主旨是担心"非法"中断"很可能"。

    我已经(正确)详细说明了这种非法中断的可能性-使用"APINT"中的"SYSRESREQ"位-启用内核和外设复位-这似乎是我们的海报所关注的...
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    是的、但您也建议在初始化期间使用 SYSRESREQ、这会导致无限重置。

    Robert

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

    是的-但请记住-我在回答时"独自"-提出了许多事实/发现-这对我来说也是"新知识"(仍然不确定)...

    我曾多次正确地指出、此类"假中断"必须通过"三级中断资格"、因此此类 "假中断"( 我们的海报关注/关注)的发生率 大幅降低。

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

    [引用 USER="CB1_MOBILE "]

    是的-但请记住-我在回答时"独自"-提出了许多事实/发现-这对我来说也是"新知识"(仍然不确定)...

    我曾多次正确地指出、此类"假中断"必须通过"三级中断资格"、因此此类 "假中断"( 我们的海报关注/关注)的发生率 大幅降低。

    [/报价]
    由于 CB1_MOBILE 所解释的"三级中断门控"、寄生中断问题现在就可以解决了。 这使我对这个问题的看法变得非常模糊。
    我认为这里的教训是:内核与芯片的其余部分是分离的。 正常上电后不会触发杂散中断、因为内核和芯片的其余部分同时退出复位状态。
    但是... 如果您自行重新启动内核,而不重新启动芯片的其余部分,则*可能*获得"假中断"(在本讨论中,这意味着:在软件启动/初始化之前发生意外中断)。 这是 VECTRESET。
    所以... 如果您要"重新启动"您的微控制器、则应通过 SYSRESREQ 来实现、而不是通过 VECTRESET。 这将不会使整个芯片复位、包括内核、外设、整个线性中断和寄生中断。
    至少这是我到目前为止的理解。
    我确信、可能需要 VECTRESET 的原因有很多。 在某些情况下、您可能希望在重新引导时重新启动内核、同时保留外设的状态(包括中断选通)。 但是、确定这种方法的使用方式将需要更多有关这些器件的经验。 对我来说、现在应该避免 VECTRESET (或者内核的任何复位、这也不会复位芯片的其余部分)!!