PIC32MZ问题

你好！我有一个问题，已经成为压倒性的。经过三个星期的努力解决问题后，我筋疲力尽了。我使用的是PIC32 MZ2048 EFH处理器。我的问题是：我有很多模块，如SPI、UART、PWM、定时器ADC等。每个模块都通过每个模块的测试框架工作进行了广泛的测试。有些模块甚至一起测试过。这很好。这些模块已经放在了库中。现在，我正在构建一个PID调节器应用程序。我把所有的模块放在一起。我使用独立的解决方案，不使用RTOS。应用程序的时序和内存需求非常适中。我使用MPLAB IDE的所有最新版本XC32。大多数模块如SPI、UART等都使用带有回调函数的中断。但大部分时间都在“等待中断”循环中。现在，我运行应用程序，得到完全随机的异常。它可以在一秒钟之内或几分钟之内。我得到所有类型的异常，包括应用程序完全崩溃和异常处理程序未被触发的情况。在这种情况下，恢复的唯一方法是重新启动应用程序。如果我得到一个异常，对于异常给出的地址也是完全随机的。我不能在行为中得到任何模式。当然，我通过控制台终端（UART6）进行跟踪，并直接尝试到内存区域来掌握发生的事情。但是，根本不可能得到关于这个根本问题的任何明智的信息。跟踪日志为最后已知的执行点提供了或多或少的随机位置。现在，如果我举例注释一个模块，例如UART1，它就可以工作。我仔细检查代码中的一些指针错误和常见错误，但什么也找不到。因此，我评论了对PWM库调用的调用，并取消了对UART 1代码的注释。现在它也起作用了！我也找不到PWM代码中的蚂蚁缺陷。现在我决定恢复UART1和PWM代码，并删除对SPI的调用。现在代码又如预期般工作了。这就好像这些模块不喜欢一起工作。所以，我怀疑基本处理器设置（初始化）的错误。一个更为可疑的原因是中断的设置。我仔细检查，设置正确的向量，优先级等。我仔细检查文档，确保我做的正确，但是找不到任何错误。问题是，如果中断设置有什么问题，为什么不同的模块组合应该与中断一起工作。我现在甚至开始认为这是HW错误，但似乎不太可能。在过去的15年中，我从来没有出现过故障PIC芯片。为什么应用程序可以与模块的一部分一起工作，而没有问题，包括不同的配置，包括中断，如果这是一个错误的芯片？我甚至花了一天的时间来解决这个问题，这通常是有帮助的，你在一个小时左右解决问题。但10个小时后，我撞上了石墙，并没有取得任何进展。甚至连一英寸也没有。我甚至做了一个记忆练习程序，试图找出任何错误的记忆位置。这个程序也许不考虑所有的可能性，但是做一些基本的测试。没问题。如果我有内存问题，为什么要在调用模块时工作呢？我在同一个空间内，在不同的配置，当它工作的正确或崩溃。任何想法或建议，将不胜感激！问候，博城，SM6FIE
                    
                    
               
                                                                                      以下为原文

                                                                            Hi! I have a problem that has become overwhelming. After more or less three week trying to crack the problem I’m exhausted. I’m using a PIC32MZ2048EFH processor.

My problem is the following: I have a number of modules like SPI, UART, PWM, timers ADC etc. Every module has been tested extensively via a test frame work for each module. Some of the modules have been tested even together. This works fine. These modules have been placed in libraries.

Now, I’m building a PID regulator application. I put all the modules together. I use a standalone solution and no RTOS. The timing and memory demands are very moderate for the application. I use all the latest releases of MPLAB IDE an XC32. Most of the modules like SPI, UART etc. use interrupts with callback functions. But most of the time is in the main “waiting for interrupt” loop.

Now then I run the application I get totally randomly exceptions. It could be within a second or within minutes. I get all types of exceptions including cases where the application totally crashes and the exception handler is not triggered. In this case the only way to recover is to restart the application. If I get an exception the address given for the exception is also totally random. I cannot get any pattern in the behavior.

Of course I put in tracing via a console terminal (UART6) as well as trying directly to a memory area to get a grip of what is happening. But is has been impossible to get any sensible information about the fundamental problem. The trace log gives more or less random locations for the last known execution point.

Now if I for example comment one module, for example UART1, it works. I examine the code closely for some pointer errors and the usual mistakes but can’t find anything. So I comment out the calls to the PWM library calls and uncomment the UART 1 code. Now it also works! I can’t find ant flaws in the PWM code either. Now I decide to reinstate the UART1 and PWM code and remove the calls to SPI. And now the codes work as expected again. It’s like the modules don’t like to work together so to speak.

Then I suspect something wrong with the basic processor settings (initialize) no problem there either as far as I can see. An even more suspected cause is the setup of the interrupts. I check this very carefully that correct vector, priorities etc. are set. I double check the documentation to make sure I do it correctly but can’t find anything wrong. And the question arises why different combinations of modules should work with interrupts if something was wrong with the interrupt setup.

I now even start to think this is HW error but it seem very unlikely. I have never ever had a malfunction PIC chip during the last 15 years.  Why can the application work with parts of the modules without problem with different configuration including interrupt if this is a faulty chip?

I even took a day off to get some distance to the problem, usually this helps, and you fix the problems within an hour or so. But after 10 hours I hit the stone wall and hadn’t done any progress. Not even an inch.

I even did a memory exercise program to try to find any faulty memory location. This program does perhaps not taking all possibilities into account but doing some basic test. No problems. And if I had a memory problem why should it work when I remove calls to a module. I’m well within the same space in different configurations when it works correct or crashes.

Any thought or advices would be much appreciated!

Regards, Bo, SM6FIE