CAN bus speed on dsPIC33EP512GM710

[lexicon]

Having configured the CAN interface at 500kbs on the dsPIC33EP512GM710, I'm finding that the actual transmission speed is more like 400kbs and I'm not sure why.
This is part of the same project as referred to in this thread viewtopic.php?f=69&t=19842 regarding the ADC behaviour.
Along the same lines, I have stripped back the program to just a heartbeat and CAN transmission.
Scoping both the heartbeat and CAN output, the heartbeat is the expected 10ms but the CAN is about 20% slow.

Again, any insights will be gratefully received.
My test program is attached.

[QMESAR]

Hi
In my opinion in both your issue is related to the speed of your Oscillator settings.
In your Flow chart you set up 16Mhz Oscillator however in FC you need to use a C Icon and configure the Oscillator speed according to your needs by setting the N and M dividers which is part of the EP device.

2.jpg (61.45 KiB) Viewed 10263 times

Here is an example for the OSC config settings in a C Icon in FC (This is for a dsPIC33EP512MU810) running 70MIPS and use 8MHZ Crystal as clock

1.jpg (119.21 KiB) Viewed 10263 times

Regarding the ADC problem I would advise you to check the datasheet what is the recommended TAD then calculate the TAD and then setup the acquisition parameters FC as per your TAD calculation-

I do not have such a device to actually run your FC Chart so my comments are in general form

Ben will give us a hand here

[lexicon]

Hi QMESAR and thanks for your input.

I agree oscillator config would be the first candidate and that was the reason I included a timed heartbeat.
My heartbeat pulse scopes at the expected 10ms which implies to me that the clock speed is correct.

Are you sure you have to manually code the oscillator settings?
I'm using an external 16MHz oscillator (so no scalers or PLL) and configuring with the Build/Project Options/Configure screen, which resulted in FC generating this code snippet:

#define MX_CLK_SPEED 16000000
.
.
_FICD(65503);
_FPOR(65527);
_FWDT(65375);
_FOSC(65434);
_FOSCSEL(65530);
_FGS(65535);

[lexicon]

I'm still struggling with the CAN bus speed.

You'll have to bear with me here on what seems like a complicated test, but I have to use the hardware project I've got - I've cut out the extraneous stuff as much as possible.

I have an RF transceiver chip that reads a keyfob and sends the received key id and checksum as serial data at 15.625kbs.

In the attached code I'm doing the following:
Trigger the RF module by pulsing the control line with G2 (also flash the LED on B10 but that's just to verify it's running).
Receive the key data via interrupt on UART1 and verify the structure as <start byte> <8 key data bytes+2 CRC bytes> <end byte>. The key data & CRC are stored in the array 'key[]'.
Transmit the two CRC bytes (key[8] & key[9]) out through UART1 @ 15.625kbs.
Transmit the 8 key data bytes (key[0] to key[7]) in a single CAN msg with ID 0x201 @ 500kbs.

The attached scope capture, UART.jpg, shows the re-transmitted CRC which is 0xFB 0x0A.
This is the correct CRC for the actual RF key being used and shows the UART is correctly configured @ 15.625kbps

The other capture is the CAN bus and you can see the ID is correct (0x201) and the key data should be: 0x35 0x41 0x50 0x5B 0xB2 0x6D 0x11 0x07
The last two bytes are correct but the rest are pretty meaningless.
The main issue here is that this capture & decode is actually at 200kbps, so nothing like the 500kbps it's supposed to be.

So it appears my general config is correct as the UART works fine but the CAN is way off.
I did think this might be similar to the issue reported in this thread:
viewtopic.php?f=69&t=19898
so I tried using the PIC16BIT_CAL_CAN.c file providedthere but it then doesn't work at all.

[Jay Dee]

Hi, with the ECIO40P16 (dsPIC33EP256MU806) some time ago I had an issue setting the CAN baud rate.
"Using standard setting the CAN transmits at half the required speed.
To make it work on the bench I changed Register CxCTRL1 from 0x0800 to 0x0000
bit 11 = 0 //FCAN is equal to Fp,
For that specific PIC see Datasheet page 362."
At that time Kersing pointed out "has a silicon issue which reverses that particular bit. "

This may or may not relate to your specific issue but it could be common to this PIC family.
The issue was also back in 2016 so it could also have been resolved.
J.

[lexicon]

Hi J,
Yes I had seen that but, according to the errata sheet, this device doesn't have that issue.

[lexicon]

I've had time to have another look at this, so I wrote my own bit of config code which I call after the FC CAN init macro.
The speed is now correct at 500kbps using 16MHz clock (although the first time it was half speed and I had to change the CANCKS bit, so maybe this device does have that issue after all).
Without my config routine the bus speed is about 420kbps.


C code:

/* Set the ECAN module for Configuration Mode before writing into the Baud Rate Control Registers */
C1CTRL1bits.REQOP = 4;
/* Wait for the ECAN module to enter into Configuration Mode */
while(C1CTRL1bits.OPMODE != 4);
/* FCAN is selected to be FP by clearing the CANCKS bit
/* FCAN = FP = 16 MHz */
C1CTRL1bits.CANCKS = 0x1;
/* Phase Segment 1 time is 6 TQ */
C1CFG2bits.SEG1PH = 0x5;
/* Phase Segment 2 time is set to be programmable */
C1CFG2bits.SEG2PHTS = 0x1;
/* Phase Segment 2 time is 5 TQ */
C1CFG2bits.SEG2PH = 0x4;
/* Propagation Segment time is 4 TQ */
C1CFG2bits.PRSEG = 0x3;
/* Bus line is sampled three times at the sample point */
C1CFG2bits.SAM = 0x1;
/* Synchronization Jump Width set to 4 TQ */
C1CFG1bits.SJW = 0x3;
/* Baud Rate Prescaler bits set to 1:1, (i.e., TQ = (2*1*1)/FCAN) */
C1CFG1bits.BRP = 0x0;
/* Put the ECAN Module into Normal Operating Mode */
C1CTRL1bits.REQOP = 0;
/* Wait for the ECAN module to enter into Normal Operating Mode */
while(C1CTRL1bits.OPMODE != 0);