@博斯科已经安装了自己的陷阱处理程序，用于调试目的，应该在串行调试端口上显示程序计数器。对于数学错误（可以很容易地生成），这很好。我也读了勘误表文件，并得出结论，24是不适用的，因为我这里的硅修订版是A7，勘误表只适用于A4。然而，它可能会使处理器速度降低到40 MHz，以防万一。我确实错过了36（ECCDBE位未设置）：从来没有发生过一个比特错误，为什么应该是双位错误？DU900010000我会尝试降低时钟速度，因为它可能会有帮助。我一直在使用微芯片组件足够长（近20年我认为）在使用组件之前读取ErATA，并且仍然可以预料到“惊喜”，因为勘误表只包含确认的问题，而不是那些问题。“正在调查中”。然而，我从未见过测试台性能和真实世界性能之间的差别。在所有其他情况下，微芯片组件的性能稳定，不易受环境影响。由于连接ICD3时问题已经解决，因此，通过将ICD2附加到调试连接器上，可以立即解决问题。我有几个ICD2还在这里，现在可以使用了。眨眼：
以上来自于百度翻译
以下为原文
@bosco
I already installed my own trap handlers for debugging purposes, which should display the program counter on the serial debug port. For the math error (that can be easily generated) this works fine.
I also read the errata file, and concluded that #24 was not applicable, because the silicon revision I have here is A7 and the errata only applies to A4. Nevertheless, it might make sence to reduce the processor speed to 40 MHz, just in case.
I had indeed missed #36 (ECCDBE bit not set): no single bit errors ever occured, why should be be double bit errors?
@du0000001
I'll try reducing the clock speed, since it might help.
I've been working with microchip components long enough (nearly 20 years I think) to read the erata before using the components, and still 'surprises' can be expected, since the errata only contains the confirmed issues, not the ones 'under investigation'. However, I've never seen this difference between test-bench performance and real world performance. In all other cases, the microchip components behaved stable, not easily influenced by the environment.
Since the problem was gone when connecting a ICD3, the problem might be solved for the moment by attaching a ICD2 to the debug connector. I've got a couple of ICD2's still laying around here, now the can be used. wink:
@博斯科已经安装了自己的陷阱处理程序，用于调试目的，应该在串行调试端口上显示程序计数器。对于数学错误（可以很容易地生成），这很好。我也读了勘误表文件，并得出结论，24是不适用的，因为我这里的硅修订版是A7，勘误表只适用于A4。然而，它可能会使处理器速度降低到40 MHz，以防万一。我确实错过了36（ECCDBE位未设置）：从来没有发生过一个比特错误，为什么应该是双位错误？DU900010000我会尝试降低时钟速度，因为它可能会有帮助。我一直在使用微芯片组件足够长（近20年我认为）在使用组件之前读取ErATA，并且仍然可以预料到“惊喜”，因为勘误表只包含确认的问题，而不是那些问题。“正在调查中”。然而，我从未见过测试台性能和真实世界性能之间的差别。在所有其他情况下，微芯片组件的性能稳定，不易受环境影响。由于连接ICD3时问题已经解决，因此，通过将ICD2附加到调试连接器上，可以立即解决问题。我有几个ICD2还在这里，现在可以使用了。眨眼：
以上来自于百度翻译
以下为原文
@bosco
I already installed my own trap handlers for debugging purposes, which should display the program counter on the serial debug port. For the math error (that can be easily generated) this works fine.
I also read the errata file, and concluded that #24 was not applicable, because the silicon revision I have here is A7 and the errata only applies to A4. Nevertheless, it might make sence to reduce the processor speed to 40 MHz, just in case.
I had indeed missed #36 (ECCDBE bit not set): no single bit errors ever occured, why should be be double bit errors?
@du0000001
I'll try reducing the clock speed, since it might help.
I've been working with microchip components long enough (nearly 20 years I think) to read the erata before using the components, and still 'surprises' can be expected, since the errata only contains the confirmed issues, not the ones 'under investigation'. However, I've never seen this difference between test-bench performance and real world performance. In all other cases, the microchip components behaved stable, not easily influenced by the environment.
Since the problem was gone when connecting a ICD3, the problem might be solved for the moment by attaching a ICD2 to the debug connector. I've got a couple of ICD2's still laying around here, now the can be used. wink:
举报
