PIC32MZEF上的I2C驱动程序异常

这个bug听起来像是一个非常古老的bug，在调用之前I2CYMeMeuleSyk参数被破坏了。当bug出现时，你能得到I2CXRCV的值吗？



      以下为原文

    That bug sounds like a very old bug where the I2C_MODULE_INDEX parameter was being corrupted before the call.  Can you get the value of I2CxRCV when the bug occurs?

让我再次运行，直到异常发生，我将看到I2C1RCV和I2C5RCV，并查看当异常停止调试时，是否可以获得值。当处于运行模式（不调试）时，MPU重置。这次你还有其他的测试吗？有什么特殊的原因使得I2C*MeuleEx索引参数被破坏吗？有什么办法吗？



      以下为原文

    Let me run again until the exception occurs, I will get in Watch both I2C1RCV and I2C5RCV and see If I can get the values when the debug is halted from the exception. When in run mode (no debug) the MPU reset. Is there any other test that you suggest this time?
 
Is there any particular reason that makes the I2C_MODULE_INDEX parameter to be corrupted? Any workaround?

嗯，是的。周围的工作不是破坏它。当然，我在做一些假设。如果我是对的，那么你会看到类似于0或1的（基本上是你使用的I2C外围设备的数量）而不是I2C模块的SFR寄存器的地址。我可以推荐的唯一的另一个测试是使用异常处理程序并在其中设置断点。在那里，一些寄存器应该提供关于特定异常的更多信息。您可以查找如何在MyPLAB®XC32用户指南中重写异常处理程序。但是，如果您在调试模式下运行，则应该在异常处理程序中获得断点。



      以下为原文

    Well, yes.  The work around is not to corrupt it.  ;)
 
I am making some assumptions, of course.  If I am right, then you will see something like a 0 or perhaps a 1 (basically the number of the I2C peripheral you are using) rather than the address to the SFR registers of that I2C module.
 
The only other test I can recommend is to use an exception handler and set a break point there.  In there, some registers should give you more information about the specific exception.
 
You can look up how to overwrite the exception handler in the MPLAB® XC32 User's Guide.
 
You should, however, get a breakpoint in the exception handler if your running in debug mode.

在调试模式下运行时，我在变量窗口中看到这个（见图）。当异常发生时，调用堆栈窗口显示异常发生的地址，并指向II2CyReaveByTigGyDebug。



      以下为原文

    I'm getting this in the variable windows (see the pics) when running in debug mode. When the exception happens the Call Stack windows shows the address where the exception happened and is pointing to I2C_ReceivedByteGet_Default.
   Attached Image(s)

正如您所看到的，索引变量确实包含0xbf82000值。所以，它并没有腐败。对不起，这是一个红鲱鱼。我认为是时候在异常处理程序中设置一个断点，看看什么样的异常正在发生。如果让调试器从这里开始，会发生什么？同样，如果你能准确地确定驾驶员中的哪一行调用I2CyReaveByTigGET可能会有帮助。让我检查一下我的其他假设：1）我假设当你说它运行一小时，它会与所有的奴隶通信吗？失败的沟通并不是第一次尝试和某个奴隶或类似的人交谈，对吧？2）在初始化驱动程序和I2C外围设备后发生错误。这不是在睡眠或类似的事情之后发生的吗？



      以下为原文

    As you can see, the index variable does contain the 0xBf82000 value.  So, it is not getting corrupted.  Sorry that was a red herring.
 
I think it is time we set a break point in the exception handler and see just what kind of an exception is happening.  What happens if you let the debugger step from here?
 
Also, it might help if you could determine precisely which line in the driver is calling I2C_ReceivedByteGet.
 
Let me check my other assumptions:
 
1) I assume that when you say it runs for an hour, that it communicates with all of the slaves?  The communication which is failing is not the first time it is attempting to talk to a particular slave or anything like that, right?
 
2) the error occurs long after the driver and I2C peripheral are initialized.  This does not happen after a sleep or anything like that?
 
 

谢谢你的GDA。我将在异常处理程序中设置一个BP，然后启动它。一旦异常发生，就会让你知道。假设1和2是正确的。MPU与I2C总线和所有的Popopeles一起连续化，没有排除。每一个受试者在同一时间间隔进行轮询。2）是的，错误发生在驱动程序和I2C外围设备被初始化后很久，我既不使用睡眠也不使用类似的东西来阻止/延迟I2C总线传输。



      以下为原文

    Thank you GDA. I will set a BP in the exception handler and launch it now. Will let you know as soon as the exception happen.
 
The assumpions 1 and 2 are correct
 
1) The MPU comunicates continuolsy with both I2C buses and with all peropherals, none excluded. Each pheripheral is polled at the same time interval.
 
2) Yes, the error occurs long after the driver and I2C peripheral are initialized, I'm not using neither sleep or anything like that that may stop/delay the I2C bus transfer.

你使用的是什么外围设备。我可能需要去更远的地方看看。PMP？SPI？DMA？



      以下为原文

    What other peripherals are you using.  I might need to look further afield for possibilities.
 
UARTS?  PMP?  SPI?  DMA?

EHH，除了I2C之外还有很多外设！2XARTS1XSPI1XI2S5XDMA（4带有ADC和1个带I2S）4xTimeRI也可以尝试运行仅使用I2C的应用程序，避免其他外围设备。调试模式中的程序停止显示堆栈调用，但异常处理程序中的断点未被触发。这听起来怪怪的。



      以下为原文

    Ehhh, a lot of peripherals other than I2C!
 
2xUARTS
1xSPI
1xI2S
5xDMA (4 with ADC and 1 with I2S)
4xTIMER
 
I can also try to run only the Apps that are using I2C avoiding other peripherals.
 
Program in Debug Mode stops showing the Stack Call, but the break point in the exception handler is not fired. This sound strange to me..
   Attached Image(s)

下一次你有机会，看看异常寄存器，让我们看看状态是否在那里。



      以下为原文

    The next time you get a chance, take a look at the exception register and lets see if the status is in there.
 
 

我回到这个问题，试图找出发生在我的PIC32 MZ中的事情，我有以下新的元素：1）我把I2C总线的时钟频率增加到400 kHz，希望有更频繁的异常（以前是50千赫，每6/8小时得到一个异常），和N我在不同的地址得到例外。例外情况下的屏幕截图是附件。我可以读取EPC，状态和原因寄存器的值：异常1 -状态既有Erl和EXL位集-原因似乎是TLB异常（负载或指令提取），此外，在400 kHz的I2C之一被卡住。我已经把频率降低到100千赫，我还在等待下一个例外：



      以下为原文

    I'm back on this issue, trying to figure out what is happening inside my PIC32MZ, I have the following new elements:
 
1) I've increased the clock frequency of both I2C buses to 400 Khz hoping to have more frequent exceptions (it was 50 Khz before, and was getting one exception every 6/8 hours), and now I'm getting exceptions at different addresses. Screen shots of the exception is in attachment. I can read the values of EPC, Status and Cause registers:
 
EXCEPTION 1
- Status has both ERL and EXL bit set
- Cause seems to be TLB exception (load or instruction fetch)
 
Furthermore, at 400 Khz one of the I2C was stuck. I've decreased the frequency to 100 Khz and I'm still waiting for next exception :-)
   Attached Image(s)

现在调试器停止，没有关于调用堆栈的信息，也没有到达异常处理程序的断点。这些是异常寄存器：EPC:0x9D0120 A0At: 0x000 800 000状态：0x00？



      以下为原文

    Now debugger halted with no information on Call Stack neither breakpoints on exception handler was reached. These are exception registers:
 
EPC: 0x9D0120A0
Cause: 0x00800000
Status: 0x00400005
 
How to debug this?
 

另一个例外：EPC:0x9D09009DCase:0x09000cLead堆栈：运行时异常@ PC地址0x9D089DC在函数中：A/O-BMPD2（）/AT /Bug／Brime/XML数据/构建DIR/XC32-TBC-BLD/BuuDIR/PIC32 M源/SRC48 x/GCC／LIGBGCC／LIGBGC2. C：1193有人有类似的异常吗？如何处理？



      以下为原文

    Another exception:
 
EPC: 0x9D0389DC
Cause: 0x00400006
Status: 0x0080000C

Call Stack: Runtime exception @ PC address 0x9d0389dc in function: __cmpdi2 ( )  at  /build/bamboo/xml-data/build-dir/XC32-TBC-BLD/builddir/pic32m-source/src48x/gcc/libgcc/libgcc2.c : 1193
 
Does someone had similare exception? How to handle it?

刚才我得到另一个例外（同一个旧的）：调用堆栈指向此处：PLBIB模板uInt8yt I2CyEngEdibGeTyGueLead（I2CyMeuleSodeID索引）{易失性I2CyReStRySt*t*ReSs=（I2CyReavestyT**）索引；返回（UInt8}t）ReSGS & Gt；I2CXRCV；}原因＝0x00 800TUC= 0x000 4000（EXL和Erl都设置为BEV＝1）GDA，有什么想法？



      以下为原文

    Just right now I'm getting another exception (the same old one): 

Call stack is pointing here: 

PLIB_TEMPLATE uint8_t I2C_ReceivedByteGet_Default( I2C_MODULE_ID index ) 
{ 
volatile i2c_register_t *regs = (i2c_register_t *)index; 

return (uint8_t)regs->I2CxRCV; 
} 

Cause = 0x0080000C - TLB exeption (store) 
Status = 0x00400006 (both EXL and ERL are set and BEV = 1) 
 
GDA, any idea?
 
   Attached Image(s)