Page 1 of 1
dsPIC 5.5 Internal CAN problem
Posted: Thu Mar 14, 2013 6:50 pm
by beambase
Hello
after upgrading to the latest dsPIC 5.5 version I was not able to compile my CAN projects created in 5.4. The CAN signal would be full of errors and I was not able to transmit anything that any other CAN diagnostic tool could read.
After going back to the old PIC16BIT_CAL_CAN.c file as supplied in this thred
http://matrixmultimedia.com/mmforums/vi ... bit#p40727
it was possible to get a useful hex file that my CAN tools could read.
This is maybe someting to look into. There seams to be a problem to use dsPIC 5.5 CAN component with a 30F6012A chip doing a fresh install or an upgrade.
Re: dsPIC 5.5 Internal CAN problem
Posted: Fri Mar 15, 2013 5:51 am
by Mikat
Hi.
The only difference between the fixed cal_can 5.4 and 5.5 is these two lines:
C1CTRL = C1CTRL_VAL;
C2CTRL = C2CTRL_VAL;
Ben, did you broke it again..

?
Did some more research, Ben, the code sets the CnCTRL register at the CnCTRL_VAL value, but where is the CnCTRL_VAL set? I can't find any place where those value is set (at least the notepad++ can't find anything else at C1CTRL_VAL, than those line above, neither at the can component or the can_cal file).
Mika
Re: dsPIC 5.5 Internal CAN problem
Posted: Fri Mar 15, 2013 10:00 am
by LeighM
Hi Mika
In the component file FC5_PIC16BIT_CAN.c you should see the defines …
#ifdef FC_CAL_PIC16BIT
#define C1CTRL_VAL 0x0800 // set CAN CKS
#define C2CTRL_VAL 0x0800 // set CAN CKS
#endif
Regards,
Leigh
Re: dsPIC 5.5 Internal CAN problem
Posted: Fri Mar 15, 2013 11:20 am
by Mikat
Ok.
I just used the notepad++ search function, and it didn't find that..
Is the baud rate calculation corrected, if the CAN CKS is set at 1, the whole can engine runs 1/4 speed of previous, so if the baud rate calculation is not corrected, the result is that if you set the baud rate at 500Kbs, the actual baud rate is 125Kbs..
Mika
Re: dsPIC 5.5 Internal CAN problem
Posted: Fri Mar 15, 2013 2:16 pm
by LeighM
Hi Mika,
Yes the component settings require the CANCKS bit to be 1 (Fcan = Fcy), if it is set to 0 then baud is x4 too high.
Leigh
Re: dsPIC 5.5 Internal CAN problem
Posted: Fri Mar 15, 2013 3:52 pm
by Mikat
Ok.
I was just thinking that the old component (ver 5.4) was designed at higher CAN engine clock..
Hard to say what is wrong, if I had time, I'll try to look what is wrong, but I an quite busy at my bachelor thesis..
Actually, I take quick look, and the baudrate calculation don't work..
When I set the chip clock at 100MHz, BRG1CON = 4, BRG2CON = 209 BRG3CON = 2, both versions (5.4.0.0 and 5.5.2.1) shows bus rate 1000Kbs, but the actual bus rate is 250Kbs, if the CANCKS = 1....
Mika
Re: dsPIC 5.5 Internal CAN problem
Posted: Fri Mar 15, 2013 4:14 pm
by Mikat
beambase wrote:Hello
after upgrading to the latest dsPIC 5.5 version I was not able to compile my CAN projects created in 5.4. The CAN signal would be full of errors and I was not able to transmit anything that any other CAN diagnostic tool could read.
Can you test that you set the CAN bus rate 4x higher than it should be?
Mika
Re: dsPIC 5.5 Internal CAN problem
Posted: Thu Mar 21, 2013 1:16 pm
by beambase
Hello,
sorry for the late reply but I've been away from home for a week so I had no possibility to test anything.
You are right.... by setting a CAN speed 4 times higher i.e. 500 kbps I get a true 125 kbps signal.
I wounder if this is only the 30F60XX chips or if it is all dsPIC?
Re: dsPIC 5.5 Internal CAN problem
Posted: Thu Mar 21, 2013 3:43 pm
by Mikat
beambase wrote:
I wounder if this is only the 30F60XX chips or if it is all dsPIC?
I am quite sure that it's same for all 30F chips, when when CANCKS is set at 1, the whole can engine runs a 1/4 speed, and that should notice when calculating the baud rate.. So in the flowcode, the bus rate should be divided by 4.
I had quite battle at this subject at year ago, first I wonder why the CAN don't work at 120MHz chip clock, and then why the CANCKS don't work.. Then I notice that when the Flowcode sets the tx address it request at config mode, and then back normal mode, it writes the whole CANCFG register, including the CANCKS bit... Now that is fixed...
Mika