在DSSPICEV处理器上的通用硬陷阱的原因是什么？

在DSSPICEV处理器上的通用硬陷阱的原因是什么？一个简短的解释应用程序和我们遇到的问题：DSPIC32 EV32 GM00 4在工业环境中用于测量NTC远离主控制器的温度。DSPIC被用作一个串行（LIN）接口的奴隶，在大约5米的距离。未受管制的9V电源（VBAT为LIN接口）也通过该电缆提供，并在本地用于DSPIC。另一个DSPIC串行通道用于调试目的，通常不连接。在测试台上，处理器几乎按预期操作。然而，每天几次，处理器重置自身。调试表明，这源自于接收“通用硬陷阱”。一旦调试器（ICD3）被连接，就没有接收到更多的硬陷阱。当在实际环境中使用时，硬陷阱的数量要高得多，每分钟几次，以至于无法正常操作。在这里连接调试器也可以防止硬陷阱发生。用一个将MCLR线路短路到+5V电源的报头替换调试器与连接调试器是不一样的。我们已经使用一个8位PIC处理器从一个早期的项目中复制了部分示意图，它已经运行了好几年了，没有任何问题。现在我们已经尝试了几种可能的解决方案，增加了额外的解耦，增加了调试连接器的额外的上拉，但是没有这种工作。因此，这将有助于了解硬陷阱的可能原因。DSPIC的数据表提到了双配合闪存错误作为可能的原因，但没有检测到单个单位闪存错误（可以通过启用中断ECSBEE来计数）。是否有可能只有双位错误和根本没有一个比特错误？这对我来说似乎不合乎逻辑。



      以下为原文

    What is the cause of the generic hard trap on the dsPIC32EV processor?

A short explanation of the application and the problems we encounter:

The dsPIC32EV32GM004 is used in an industrial environment for measuring the temperature of NTC's remote from the main controller. The dsPIC is used as a slave over a serial (LIN) interface, at about 5 meters distance. Un unregulated 9V power supply (Vbat for the LIN interface) is also supplied by means of this cable and used locally for the dsPIC. Another dsPIC serial channel is used for debug purposes and normally not connected.
On the test-bench the processor operates nearly as expected. However a few time a day, the processor resets itself. Debugging has showed that this originates from receiving a "generic hard trap". Once the debugger (ICD3) is connected, no more hard traps have been received.
When used in the real environment, the number of hard traps is much higher, several each minute, so much that no normal operation is possible. Connecting a debugger here also prevents the hard trap from occurring. Replacing the debugger with a header shorting the MCLR line to the +5V power supply was not the same as connecting the debugger.
We have copied part of the schematics from an earlier project using a 8 bit PIC processor, which has been running for several years now without any problem.  

We have now tried several possible solutions

• added extra decoupling
• added extra pull-up to debug connector
  

but non of this worked.
Therefor it would help to know the possible causes of the hard trap. The datasheet of the dsPIC mentions double fit flash errors as a possible cause, but not a single single bit flash error has been detected (can be counted by enabling interrupt ECCSBEIE). Is it possible to have only double bit errors and no single bit errors at all? That doesn't seem logical to me.


   Attached Image(s)