CAN bit timing with a dsPIC33

[labviewman]

I have struggled with CAN on a dsPIC33 for about 8 hours today and have been able to determine it does attempt to send a msg on the bus (by stepping thru the code I can see it reaches the point of requesting sending of the msg (C1TR01CON.txreqm=1) and simultaneously seeing an error-code on my National Instruments bus monitor), but the bit timing must be totally wrong since I don't see the msg (delivered w/o errors) on my bus analyzer.

I used MBTime from http://www.intrepidcs.com/support/mbtime.htm as suggested from this forum about 100x today but with no luck. I don't have a scope to see what the actual baud rate is, but I followed the suggested values (from MBTime) to no avail.

The values I used are CICFG1=0x000, and CICFG2=0x07BA

[Ttelmah]

Step back.

Have you actually verified that your processor is running at the frequency you think it is?.
The simple 'flash an LED' test.

It is very common with the PIC33, and some of the later PIC16's/18's, where they 'FSCM', to find that you have an error in your clock settings, and you 'think' the chip is running at 20MHz (for example), and it is actually 'failing' and dropping to the internal oscillator at (perhaps) 16MHz. Result, screwy timings with everything.....

It is a fundamental part of starting with any PIC, to do a basic test, and verify that the chip is actually running, and running exactly at the frequency you expect.

So, have you done this?. Are you sure the timing is right?.
Until the answer to both these is 'yes', forget CAN.....

[labviewman]

I am absolutely 100% sure the code is executing at the expected clock frequency by:

a) verifying the blink frequency of a LED driven by the uC is almost exactly as calculated (2 methods: via simple delay_ms and via timer ISR); almost in regards within 0.005 Hz as expected
b) sending serial data out of the serial port (RS32)...always works at the expected baud rate
c) changing the clock frequency to 50 and then 80 MHz and watching the LED flash rate change as expected (#use delay(clock=80MHz,crystal=10MHz)).

Believe me, I have spent hours confirming the code is executing with the expected clock frequency...you are right, this is the very first thing that should be done, but been there...done that.

[RF_Developer]

OK, so what CAN bit rate do you expect and what is the processor clock rate you are using? I don't have an "Inverse MBTime" to work it backwards from you code snippet. BRG Prescaler of 0 suggests to me a slow processor clock or a very fast bit rate, which is unusual.

[labviewman]

Duh, sorry I didn't include that!

I have a 10 MHz crystal (#use delay(crystal=10MHz)) and am trying to get HS CAN at 250 Kbps.

I'm taking the board to work today to see what bit rate I actually get...I don't have a scope at home.

Thanks,

Todd

[RF_Developer]

[labviewman]

It has been a while since I have looked at a CAN waveform, but when I send 0xAA (no bit stuffing will occur), I get a period of 16 usec between rising edges, which if I'm thinking correctly would be 2x the actual bit period (since sending 10101010b), thus, it looks like the actual baud rate is 125Kbps.

So, I connected a bus analyzer to verify and sure enough, it's 125 Kbps.

So, why am I off by a factor of 1/2 in setting the baud rate?

[labviewman]

Ha, I submitted that and didn't realize you had responded.

I will try changing the clock speed and baud rate when I get home to verify it's always 1/2 (we don't have the same compiler version at work, but besides, I barely do anything personal at work). Regardless, if I can get my project working (I actually need a lower-bit rate for GMLAN on a different CAN bus), even if it's a kludge, I will definitely something your way (will need your mailing address, which you can PM me).

[Ttelmah]

That is exactly what I'd expect.....

Case of 'poor documentation' on the generator, and 'read the data sheet'.....

On the PIC18, the clock feeding the CAN BRG, is from Fosc. If you look at the BRGCON1 defines, the baud rate prescaler, is all done by division from Fosc.
"000000 = TQ = (2 x 1)/FOSC" (note Fosc)

However on the PIC33, the clock feeding the CAN brg, is 1/Fcy (processor cycle time,not oscillator frequency....). So in the data sheet the timings, the same value refers you to Fcan, and in the more complete 'overview' documents, this is given as selectable from Fcy/1, or Fcy/4. Note Fcy, not Fosc.
"FCAN is FCY or 4 FCY depending on CANCKS bit" (note Fcy)

On the PIC24, Fcan, is selectable between Fosc (the default), and Fcy.
"CANCKS: CAN Master Clock Select bit
1 = CAN FCAN clock is FCY
0 = CAN FCAN clock is FOSC" (note Fosc on the faster setting)

So on both the PIC18, and PIC24, inputting the 'oscillator' frequency will give the correct result (with CANCKS=0). However on the PIC33, you need to input the oscillator/2....

The calculator ought to refer you to using the Fcan on the different chips, rather than Fosc, or allow you to specify the chip family involved.

[labviewman]

Thank you RF_Developer for testing on your equipment and telling me the bit rate and thank you Ttelmah for explaining why this is happening.

I said I would reward who ever helped so I'd like to mail each of you a VISA gift card...if interested, pm me (if possible here) your mailing address.

Thanks,

Todd

[Ttelmah]

For myself, I'd say give a little donation to a local hospice or something similar.

Best Wishes