Harmony产生的CANBUS时序偶尔会出错

1。你读了CAN寄存器来验证它们是否有正确的值？3、Dd你检查一个作用域上的时间。



      以下为原文

    1. What Version of Harmony.
2.Did you read back the CAN Registers to verify they have the correct Values?
3.Dd you check the Timing on a scope.

正在使用的和声版本是V2Y02YY0B，我首先使用示波器发现问题，并且附加了范围拍摄。有人会认为，如果帧不正确，设备将不确认，但ACK只是晚了。在图中，黄色轨迹是接收，蓝色轨迹是从PIC32引用时的传输。另一个设备是一个传感器，并且我有一个点对点连接通过MPC2561收发器。还有一点值得注意的是，由于我可以让我的传感器在我们这里的另一个CPU和CAN扫描仪上工作，这个问题似乎不能延迟。我看到以下几点：我使用的是通过SK开发板的PIC32 MZ2048 EFH144，以及我的时钟设置。晶体振荡器为24MHz。PLLIDIV是3，给出8MHz。PLLMULT为50，为400兆赫，PLLUDIV为2，提供200兆赫。PB DIV 5为1，无效（明显），但从未发出警告。（我在写时发现这一点）来检查差异，我把除法器改为4，这将PBCK5的输出变成了50MHz。我相信这是一个有效的值；然而，在ACK被断言的范围内，我仍然看到一个相同的行为。在这种情况下，配置位是：C1CON 0x800 0C1CFG 0x39 809i，几乎不知道如何在点到点连接上获得无效ACK信号。就像在某个地方有一个平凡的细节，任何能引起延迟的ACK的想法都会得到极大的赞赏。



      以下为原文

    The version of harmony that is am using is v2_02_00b, and I first found the issue using the oscilloscope, and the scope shot is attached.  One would think that the device would not ACK if the frame wasn't correct, but the ACK is just late.  In the picture, the yellow trace is the receive and the blue trace is the transmit when referenced from the PIC32.  The other device is a sensor, and i have a point-to-point connection  via a MPC2561 transceiver.  It's also of note that the issue does not seem to be CAN delay due to the fact that I can get my sensor to work on another CPU we have here, as well as the CAN scanner.
 
After dumping the registers, I see the following:
C1CON 0x00008000
The C1CON bit breakdown:
0000         unimplemented
0                 ABAT
000                REQOP: set normal operation
000                OPMOD: module in normal operation mode
0                CANCAP: disable CAN message time stamp
0000        unimplemented
1                ON: CAN On bit
0                unimplemented
0                SIDLE: CAN continues operation on idle
0                unimplemented
0                CANBUSY: can module disabled
000000        unimplemented
00000        DNCNT: do not compare devnet byttes

C1CFG 0x00029031
The C1CFG bit breakdown:
0000000000 unimplemented
0                WAKFIL: do not wake up
000                unimplemented
010                SEG2PH: 3
1                SEG2PHTS: freely programmable
0                SAM: bus line is sampled once
010                SEG1PH: 3
000                PRSEG: 0
00                SJW: 0
110001        BRP: 49
 
I am using a PIC32MZ2048EFH144 via the SK development board, and my clock settings are 24MHz for the crystal oscillator. PLLIDIV is 3, to give 8Mhz. PLLMULT is 50 to give 400MHz, and PLLODIV is 2 to give 200MHz. PB DIV 5 was 1, which was invalid (apparently) but never threw an warning. (I discovered this while writing)

To check for a difference, I changed divider to be 4, which changed the PBCLK5 output to be 50MHz. Which I believe to be a valid value; however, I still see an identical behavior on the scope with the ACK being asserted late. In this case, the configuration bits are:
C1CON 0x8000
C1CFG 0x39809
 
I'm pretty much out of ideas how I can get an invalid ACK signal on a point-to-point connection.  It's like there's a mundane detail somewhere.
 
Any ideas of what could cause a delayed ACK would be greatly appreciated.
 
 
 
 
 
 
   Attached Image(s)

由于不清楚的原因，MCP2651和CAN设备是不兼容的。我用较新的MCP2551取代了新的IC，一切都有效。



      以下为原文

    For reasons that are not clear at all, the MCP2651 and the CAN device were not compatible.  I replaced that newer IC with the older MCP2551 and everything worked.  

几个星期前我们也搬到了新的地方。它似乎有点“挑剔”，特别是在它的需要侧& 5T，如果MCU侧是电源@ 3.3…



      以下为原文

    We moved to the new part as well some weeks ago. It seems to be a little more "picky", especially in that it needs >=5V at the CAN side, if the MCU side is powered @3.3 ...