在SPI flash启动后不久，我有4块板正在被看门狗定时器复位。
这些单板均采用PAN1740模块。
通过在整个代码中添加GPIO切换，我确定了软件从呼叫到rwip_init返回。
我在上一篇文章上看到了别人因硬件（接地）问题而有这个问题。由于我们正在使用Pan1740，这一点不太可能，但仍然是可能的。这一事实使这一设计在现有局势上运行的事实是复杂的，但这个很多由新的供应商建造（新的给我们，他们是一个已建立的好的制造商）。
您能推荐如何继续解决这些问题吗？我很乐意通过电子邮件提供源代码，原理图等。
谢谢，
凯文
设备：
嗨hughesk,
如果您尝试在没有睡眠模式的情况下运行，那么设备是否可操作或删除看门狗？另外尝试在DEV套件上运行FW，并检查设备是否在该板上运行，或者尝试在您提到的电路板上的最近SDK上运行任何示例。您还可以通过检查代码丢失和看门狗的位置来检查（肯定）通过检查nmi_handler（）来检查代码停止。
由于MT_dialog
我也在看这个问题，我看到改变的行为可能受到一些微妙的硬件时机的影响。
禁用睡眠不会改变行为，使用SDK 5.0.4也不会。SPS配置文件示例DA1458x_DSPS_v_5.150.2，仅改变Tx和Rx端口引脚，表现出相同的行为，有时硬故障，有时ok。
由于CFG_HOST和BLE_HOST_PRESENT都已定义，因此rwip_init()不能用于逐级执行，因为要调用ROM堆栈中的rwip_init()，而不是源代码中的版本。试图跟踪ROM代码的异常捕获是不可能的，除非堆栈源是可用的。
嗨nzbackpackers
无论你使用哪个SDK版本，硬件故障或NMI(看门狗)的设备死机?如果设备正确地执行代码或不独立于任何特定的事件?您看到PC从中断结束在一个ROM地址对应于rwip_init()，无论您使用哪个SDK(您可以检查PC在Hardfault或NMI，并匹配地址与地图文件)?
由于MT_dialog
hardfault处理程序：看起来像smpc.obj 0x20002298（链接在0x200002280-
只有在电路板上发生，当DA14580使用吹磨机时，我有机会。如果较冷，问题会消失。销重置或断电复位两者都不可靠地恢复，尽管有时断电复位会恢复。我将重新访问稍后的SDK5版本。
.text 0x20002194第0节第0个atts_task.obj（.text）.text 0x20002280 Section 0 smpc.obj(.text)
.text 0x2000236c Section 0 smpc_task.obj(.text)
嗨nzbackpackers，
因此，您必须为设备提供这种行为，有关重置并且设备无法正常恢复的事实，因此您必须对此进行热量，并且由于在ADC期间的错误测量，因此引导加载程序是温度的事实依赖于此启动，但这将导致引导加载程序的单个或多次执行，而不是未能执行，当设备无法启动时，它在引导期间停止，或者它始终由于硬符而延迟？
您在设备上方有吹风机的事实可能会影响太多参数，580推荐的操作条件为85摄氏度，但温度可能会影响晶体（降低稳定时间）。请用最新的SDK发射拍摄，但您应该检查设备到达的精确温度，并且您开始拥有这些问题，烤箱也比吹风机更适当的温度测试。
由于MT_dialog
故障随机出现，但确保温暖(热手温度，远低于85度)而不是凉爽会增加电源应用故障的频率。有时设备永远不会出现硬故障，代码甚至不能被分级，但运行调试会话当然会影响行为。
关于ADC和温度测量，您提及引导加载程序使用，我没有看到引导加载程序测试和随后采取的操作的任何文档。那会有吗？我看到可能正在测试的几个值：
DA14580 ADC单端模式
=================.
0000 - 0011 = P0 [0] . . PO [3]
0100 =住客
0101 = vdd_ref.
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暗示了vdcddc - vdcdc_rf连接(ADC和RF)是外部平滑电容，但这些都隐藏在模块内。
我正在使用最新的SDK测试，到目前为止，我在此处看到出版物的故障：
nvic_clearpendingirq.ble_rxdesccnt.getf
我将继续测试 - 感谢您对此问题的帮助。
嗨nzbackpackers，
ADC功能属性是ROM引导程序的一部分，并且不可用，正如我所说的，因为我说不应该影响设备的操作，因为温度的变化会影响引导加载程序将执行顺序引导过程的次数而不是引导加载程序本身。由于设备在某些时候运行和摊位，当代码已启动时，我不认为这是您的问题。
我不知道是否有PAN模块中的内部连接可用，但由于崩溃是随机的，并且据我所知，您有时会丢失与调试器的连接，也许您应该检查电源（不应该相当稳定，没有涟漪）或者在PCB的组装中存在一些问题，我正在使用Panasonic检查，我会告诉您关于您的请求的一些反馈，但最逻辑的解释是PCB组件的问题。
由于MT_dialog
我终于能够在SDK5上使用Dialog empty_peripheral_template软件重现这个问题;冷却时运行良好，但加热到手热(小于65度)时，代码就失效了。代码只有在冷却和重置后才能恢复。我正在嗅探数据包使用北欧部分。我将尝试捕捉故障的失速点，目前看起来像一个nmi。
电力是干净的，我不认为这有什么问题;供应是一个独立的LDO是干净的输入和输出。
一旦运行温度不再是问题，即使在相当热的时候——至少65度。
对话框empty_peripheral_template软件
从我的测试，温度敏感部件是Pan1740模块，因为通过接触加热模块而不提高周围部件的温度，我得到了故障。在“使用KEIL SDK5 V5.22.0.0中构建的”Office_Peripheral_Template软件“上，我从0x200004B2的NMI_Handler获得了一个可重复的中断，似乎源于DA14580 ROM。调用地址表示为0x40FFFFC。在发生电源周期之前，即使在冷却模块后，即使在冷却模块后，也会简单地发出重置。在稍微冷却后的电源循环后，故障被移除。但是在Office_Peripheral_Template软件对话框中，Boot_vectors中的NMI_Handler（）代码不会调用NMI_Handlerc（），因此在0x81850中未捕获Status_Base中的堆栈跟踪。keil表示名为0xfffffffe的nmi_handler，暗示可能是一个硬故障，尽管Hardfault_handler（）似乎没有达到，所以尚未调用solutfault_handlern（），并且再次没有将信息复制到status_base中（在0x81800处）。development_debug是定义的，但堆栈信息在对话框代码上显然不会被保存（nmi all = 0）。手动预先写的测试值不会改变。除非在早期帖子中注明的稍微加热，否则此代码正常工作并按预期广播广告数据包，在加热一次成功启动时没有观察到的故障。
客户的应用程序代码
在客户端的应用程序代码上，达到HardFault_Handlern（），但没有真正的调试设施看起来功能。
调用堆栈跟踪：
0xfffffffe.NMI_Handler位置/值0x200004B2
0x00000000.
定义了DEVELOPMENT_DEBUG，但是堆栈信息来自前面的失败;调试模式下的后续失败不会生成任何堆栈跟踪信息。对于NMI, STATUS_BASE是在0x81850的保留RAM中，对于HardFault处理程序是0x81800:
//堆栈跟踪-客户端启动失败后的代码// ==============================================
// 0x81800 0x81850 <== STATUS_BASE
//
// HardFault NMI注册地址
// ========== ========== ======== ==========
// 0x00000000 0x00000013 R0
// 0x00000000 0x00000000 R0
// 0x00000000 0x00000000 R1
// 0x00000000 0x00000000 R2
// 0x00000000
// 0x00000000 0x00010100 R12
// 0x00000000 0x00000000 lr
// 0x00000000 0x01000000 PC
// 0x00000000
//
// 0x00000000 0x00000000 CFSR 0xE000ED28
// 0x00000000 0x00000000 HFSR 0xE000ED2C . txt
// 0x00000000 0x00000000 dfsr 0xe000ed30
// 0x00000000 0x00000000 AFSR 0xE000ED3C
// 0x00000000 0x00000000 mmar 0xe000ed34
// 0x00000000 0x00000000 bfar 0xe000ed38
嗨nzbackpackers，
由于设备非功能性一旦加热低于85,你一定没有问题的电源模块,然后印刷电路板的组装是应该检查(问题当加热设备可能出现由于焊接inadequancy)。只要没有看门狗，NMI_Handler()就不应该出现，尽管模板已经定义了看门狗，不确定你是否尝试过没有看门狗。我不认为你所经历的与SDK做任何事情，因为就我所能告诉的错误，你没有任何一致性，而且提供给SDK的例子是超过测试。我也认为你正在多个设备上测试这个问题。
由于MT_dialog