我有4个板，正在被复位的看门狗定时器SPI flash启动后不久。
这些板使用PAN1740模块。
通过在整个代码中添加GPIO切换，我确定软件永远不会从对rwip_init的调用中返回。
我在之前的一篇文章中看到，由于硬件(接地)问题，其他人也有这个问题。由于我们使用的是PAN1740，这种情况不太可能发生，但仍然是可能的。这是复杂的事实，这个设计已经在以前的板运行，但这批是由一个新的供应商(对我们来说是新的，他们是一个建立的，好的制造商)。
您能推荐如何继续解决这些问题吗？我很乐意通过电子邮件提供源代码、示意图等。
谢谢,
凯文
设备：
嗨hughesk,
如果您尝试在没有睡眠模式的情况下运行，那么设备是否可以运行，或者在取消定义看门狗时是否可以运行？还可以尝试在开发工具包上运行fw，并检查设备在该板上是否可以运行，或者尝试在您提到的板上的最新SDK上运行任何示例。您也可以检查（确保）其中，通过检查NMI_处理程序（）以及代码暂停和看门狗出现的确切位置，代码暂停。
由于MT_dialog
我也在研究这个问题，我看到改变的行为可能受到一些微妙的硬件定时的影响。
禁用睡眠不会改变行为，使用SDK 5.0.4也不会。仅改变Tx和Rx端口引脚的SPS配置文件示例DA1458x_DSPS_v_5.150.2显示了相同的行为，有时是硬故障，有时是正常的。
由于CFG_HOST和BLE_HOST_PRESENT都定义了，因此rwip_init()不能用于单步执行，因为调用的是ROM堆栈中的rwip_init()，而不是源代码中的版本。除非堆栈源可用，否则跟踪ROM代码的异常捕获是不可能的。
嗨nzbackpackers
无论使用哪个SDK版本，设备在Hardfault或NMI (watchdog)中暂停?如果设备正确地执行代码是否独立于任何特定的事件?你看到PC从中断结束在一个ROM地址，对应于rwip_init()，无论你使用哪个SDK(你可以检查PC在Hardfault或NMI和匹配的地址与地图文件)?
由于MT_dialog
硬故障处理程序：看起来像0x20002298处的smpc.obj（链接在0x200002280处-
只有在DA14580使用吹风机暖手的情况下，我的主板才会出现这种情况；如果问题消失，则会出现这种情况。引脚复位或断电-通电复位都不能可靠地恢复，尽管断电-通电复位有时会恢复。我将重新访问更高版本的SDK5。
.text 0x200002194第0节附件任务.obj（.text）.text 0x20002280 Section 0 smpc.obj(.text)
.text 0x2000236c Section 0 smpc_task.obj(.text)
嗨，背包客们，
所以你必须预热它以便设备有这样的行为，关于复位和设备不能正确地恢复可能与事实有关，引导加载程序是温度依赖于一个错误的测量ADC在引导期间，但是这会导致单个或多个引导加载程序的执行而不是执行失败，当设备启动失败时，它在引导期间停止或它总是由于Hardfault而停止?
事实上，在设备上方有一个吹风机会影响太多的参数，580的建议操作条件是在85摄氏度，但温度会影响晶体(减少稳定时间)。请给它与最新的SDK，但你应该检查设备达到的确切温度，你开始有这些问题，烤箱将是一个更合适的温度测试比电吹风。
由于MT_dialog
故障似乎是随机的，但如果确保是暖的(热手温度，远低于85度)而不是冷的，则会增加应用电源时故障的频率。有时设备永远不会出现硬故障，代码甚至不能进行步进处理，但是运行调试会话当然会影响行为。
关于您提到的引导加载程序使用的ADC和温度测量，我没有看到任何关于引导加载程序测试内容和后续操作的文档。这是否可用？我看到了几个可能正在测试的值：
DA14580 ADC单端模式
=================
0000 - 0011 = P0 [0] . . PO [3]
0100=AVS
0101=VDD_参考
0110=VDD_RTT
0111=VBAT3V
1000=VDCDC
1001=VBAT1V
(其他人保留)
差模
=================
0000 = P0[0] vs P0[1]
else = P0[2] vs P0[3]
我也找不到PAN1740 DA14580模块内的电源连接细节;你知道他们是否有空吗?松下数据表我没有给出细节。Dialog DA14580数据表中的图9和图12表示vddc - vdcdc_rf连接(ADC和RF)是外部平滑电容，但这些都隐藏在模块内部。
我正在使用最新的SDK进行测试，到目前为止，我在这里看到启动时出现的故障：
NVIC_ClearPendingIRQble_rxdesccnt.getf
我将继续测试-感谢您对这个问题的帮助。
嗨，背包客们，
ADC功能是ROM引导加载程序的一部分，但不可用，正如我所说，虽然这不应影响设备的运行，因为温度的变化会影响引导加载程序执行顺序引导过程的次数，而不是引导加载程序本身。因为设备在某个时间点运行和暂停int当代码已经启动时，我不认为这是你的问题。
我不知道PAN模块中的内部连接是否可用，但由于崩溃是随机的，而且据我所知，您有时会与调试器失去连接，也许您应该检查电源（应该非常稳定，没有波纹），或者PCB的组装有问题，我正在与松下公司联系，如果我对您的请求有任何反馈，我会通知您，但最合理的解释是PCB组件的问题。
由于MT_dialog
我终于能够使用Dialog empty_peripheral_template软件在SDK5上重现这个问题;当冷却时，它运行良好，但当加热到手热(低于65度)，代码失败。代码只有在冷却和重置后才能恢复。我在用北欧部件嗅探数据包。我将尝试捕捉失败时的失速点，目前看起来像一个nmi。
权力是干净的，我看不出有什么问题;电源是一个独立的LDO，在输入和输出上是干净的。
一旦开始跑步，温度就不是问题了，即使是非常热的时候——至少65度。
对话框empty_peripheral_template软件
从我的测试中，温度敏感组件是PAN1740模块，因为通过接触加热模块而不提高周围组件的温度，我得到了故障。在使用Keil SDK5 v5.22.0.0构建的对话框empty_peripheral_模板软件上，我从0x200004B2的NMI_处理程序中得到了0xFFFFFE处的可重复中断，这似乎是错误的源于DA14580 ROM。调用地址指示为0x40FFFFFC。在电源循环发生之前，即使在模块冷却后，简单地发出RESET也会重复该故障。在稍微冷却后的电源循环后，故障将被删除。但是，在空\u外围设备\u模板软件对话框中，NMI\u处理程序（）boot_vectors.s中的代码不调用NMI_HandlerC（），因此堆栈跟踪不会捕获到0x81850处的STATUS_BASE中。Keil表示名为0xFFFFFE的NMI_处理程序，这可能意味着一个硬错误，尽管似乎没有到达硬错误处理程序（），所以HardFault_HandlerN（）未调用，并且再次没有信息复制到状态库中（这次是0x81800）。已定义开发调试，但堆栈信息未明显保存（NMI all=0）在对话框代码上。手动预写的测试值不会更改。除非按照前面文章中的说明稍微加热，否则此代码工作正常，并按预期广播广告包，在加热成功启动后，未观察到任何故障。
客户的应用程序代码
在客户端的应用程序代码上，已达到HardFault_HandlerN（），但实际的调试工具似乎不起作用。
调用堆栈跟踪：
0xFFFFFENMI_Handler位置/值0x200004B2类型无效(f)
0x00000000
定义了DEVELOPMENT_DEBUG，但是堆栈信息来自于上次的失败;调试模式下的后续失败不会生成任何堆栈跟踪信息。STATUS_BASE在保留RAM中为0x81850的NMI和0x81800的HardFault处理:
//堆栈跟踪-启动失败后的客户端代码// ==============================================
// 0x81800 0x81850 <== STATUS_BASE
//
// HardFault NMI寄存器地址
// ========== ========== ======== ==========
//0x00000000 0x00000013 R0
// 0x00000000 0x00000000 R0
//0x00000000 0x00000000 R1
// 0x00000000 0x00000000 R2
// 0x00000000 0x00000000 R3
//0x00000000 0x0000100 R12
// 0x00000000 0x00000000 LR
// 0x00000000 0x01000000 PC
// 0x00000000 0x00000000 PSR
//
// 0x00000000 0x00000000 CFSR 0xE000ED28
// 0x00000000 0x00000000 hsr 0xE000ED2C . 0x00000000
// 0x00000000 0x00000000 DFSR 0xE000ED30
// 0x00000000 0x00000000 AFSR 0xE000ED3C
//0x00000000 0x00000000 MMAR 0xE000ED34
//0x00000000 0x00000000 BFAR 0xE000ED38
嗨，背包客们，
由于设备非功能性一旦加热低于85,你一定没有问题的电源模块,然后印刷电路板的组装是应该检查(问题当加热设备可能出现由于焊接inadequancy)。只要没有看门狗，NMI_Handler()就不应该发生，尽管模板已经定义了看门狗，但不确定您是否尝试了没有看门狗的情况。我不认为你所经历的与SDK做任何事情，因为就我所能告诉的错误，你没有任何一致性，也提供给SDK的例子超过测试。我还认为你正在多个设备上测试这个问题。
由于MT_dialog