在SPI flash启动后不久，我有4块板正在被看门狗定时器复位。
这些单板均采用PAN1740模块。
通过在整个代码中添加GPIO切换，我确定软件永远不会从rwip_init调用中返回。
我在之前的一篇文章中看到有人因为硬件(接地)问题而遇到了这个问题。由于我们使用的是PAN1740，这有点不太可能，但仍然是可能的。这是复杂的事实，这个设计已经在之前的董事会运行，但这个lot是由一个新的供应商(对我们来说是新的，他们是一个成熟的，好的制造商)。
您能建议如何继续排除这些问题吗?我很乐意通过电子邮件提供源代码、原理图等。
谢谢,
凯文
设备:
嗨hughesk,
如果您尝试在没有睡眠模式的情况下运行，设备是否可运行，或何时取消定义看门狗?还可以尝试在开发套件上运行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
硬故障处理程序:看起来像smpc。Obj在0x20004002298(链接在0x200002280-
这只会发生在我的板子上，当DA14580是用吹风机手暖的时候;如果冷静下来，问题就解决了。引脚复位或上电复位都不能可靠地恢复，尽管上电复位有时会恢复。我将重新访问SDK5的后期版本。
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度)而不是凉爽会增加电源应用故障的频率。有时设备永远不会出现硬故障，代码甚至不能被分级，但运行调试会话当然会影响行为。
关于你提到的Bootloader使用的ADC和温度测量，我没有看到任何关于Bootloader测试和随后采取的行动的文档。有时间吗?我看到几个可能正在测试的值:
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_ClearPendingIRQble_rxdesccnt.getf
我将继续测试-谢谢您对这个问题的帮助。
嗨nzbackpackers,
的ADC functionallity是ROM引导装载程序的一部分,不可用,就像我说的虽然不应影响设备的操作,因为温度的变化影响的次数,引导装载程序将执行顺序启动过程,而不是引导装载程序本身。因为设备运行和在某个点上，当代码已经启动，我不认为这是你的问题。
我不知道如果锅的内部连接模块可用,但自从崩溃是随机的,据我理解你有时失去连接与调试器也许你应该检查你的电源(应该很稳定没有涟漪)或有电路板的组装的问题,我正在和松下核实，当我对你的要求有一些反馈时我会让你知道，但是最合理的解释是PCB组装的问题。
由于MT_dialog
我终于能够在SDK5上使用Dialog empty_peripheral_template软件重现这个问题;冷却时运行良好，但加热到手热(小于65度)时，代码就失效了。代码只有在冷却和重置后才能恢复。我正在嗅探数据包使用北欧部分。我将尝试捕捉故障的失速点，目前看起来像一个nmi。
电力是干净的，我不认为这有什么问题;供应是一个独立的LDO是干净的输入和输出。
一旦运行温度不再是问题，即使在相当热的时候——至少65度。
对话框empty_peripheral_template软件
从我的测试温度敏感的组件是PAN1740模块，因为通过接触加热模块而没有提高周围组件的温度，我得到了故障。在使用Keil SDK5 v5.22.0.0构建的Dialog empty_peripheral_template软件上，我从位于0x200004B2的NMI_Handler中获得一个位于0xFFFFFFFE的可重复中断，它似乎起源于DA14580 ROM。调用地址指示为0x40FFFFFC。直到电源循环发生，简单的复位即使在冷却模块后也会重复故障。经过一个稍微冷却后的电源循环，故障被排除。然而在Dialog empty_peripheral_template软件中，boot_vectors中的NMI_Handler()代码。s不调用NMI_HandlerC()，因此堆栈跟踪不会被捕获到0x81850的STATUS_BASE中。Keil指示NMI_Handler称为0xFFFFFFFE，这可能意味着一个硬故障，尽管HardFault_Handler()似乎没有到达，所以HardFault_HandlerN()没有被调用，并且再次没有信息被复制到STATUS_BASE(这次是0x81800)。定义了DEVELOPMENT_DEBUG，但是堆栈信息显然没有保存在Dialog代码中(NMI all = 0)。手动预先编写的测试值不会改变。除非像之前的文章中提到的那样稍微加热，否则这段代码工作得很好，并且像预期的那样广播广告包，一旦成功启动加热，没有观察到失败。
客户的应用程序代码
在客户机的应用程序代码上，会到达HardFault_HandlerN()，但是没有真正的调试工具出现。
堆栈跟踪:
0 xfffffffeNMI_Handler位置/值0x200004B2
0 x00000000
定义了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