|
|
View previous topic :: View next topic |
Author |
Message |
mglsoft
Joined: 18 Feb 2008 Posts: 48
|
PIC24HJ : ECAN Module problem (Solved) |
Posted: Wed Mar 06, 2013 12:29 pm |
|
|
I am programming on a PIC24HJ128GP504, the truth is my first experience with PIC24 and really am amazed how well and fast I'm going.
That is until today, where I try to communicate via CAN bus, using the ECAN module that has this micro.
To use the module pin to reconfigure ECAN RB10 and RB11, thus:
Code: | //Seleccion de pines a usar en CAN1
#pin_select C1TX=PIN_B11
#pin_select C1RX=PIN_B10 |
And as the xtal is 10 Mhz, configure it as follows:
Code: |
#FUSES HS //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES WPRES32 //Watch Dog Timer PreScalar 1:32
#FUSES WPOSTS1 //Watch Dog Timer PostScalar 1:1
#FUSES PROTECT_HIGH //General Segment Code Protect High Security
#FUSES CKSFSM //Clock Switching is enabled, fail Safe clock monitor is enabled
#FUSES NOJTAG //JTAG disabled
#use delay(crystal=10 MHZ) //clock=10000000) // |
250K need to transmit therefore MBtime software calculates the following values:
Code: | can_init(); //inicializa el modulo CAN
// Con los valores de libreria es para 125K y reloj de 20Mhz....
can_set_mode(CAN_OP_CONFIG);
// Reloj a 10Mhz, velocidad a 250Kbps, extendido.
C1CFG1.brp=1; // Valor de calculo 2, se resta 1 para el registro
C1CFG1.sjw=0; // Valor de calculo 1, se resta 1 para el registro
C1CFG2.prseg=0; // Valor de calculo 1, se resta 1 para el registro
C1CFG2.seg1ph=4; // Valor de calculo 5, se resta 1 para el registro
C1CFG2.sam=FALSE;
C1CFG2.seg2phts=TRUE; //FALSE;
C1CFG2.seg2ph=2; // Valor de calculo 3, se resta 1 para el registro
C1CFG2.wakfil=FALSE; //TRUE;
can_set_mode(CAN_OP_NORMAL);
//********* fin init can |
Now my problem wont.
It just does not fit the transmission routine, because it's never CAN_TBE TRUE value.
Code: | //Envia por CAN el conteo de los sensores 1 al 16
if (Can_tbe()&&(ms > 250))
{
ms=0;
//Envia por CAN el conteo de cada entrada de sensores 1 al 8
can_putd(CONTEOS_SENSORES_1A8_ID, &Mi_buffer[0], 8, 1, 1, 0);
delay_ms(125);
//Envia por CAN el conteo de cada entrada de sensores 9 al 16
can_putd(CONTEOS_SENSORES_9A16_ID, &Mi_buffer2[0], 8, 1, 1, 0);
} |
I do not understand what is happening, it may be something about the xtal??
The bus baudrate calculation right??
My previous experience with PIC18F (the last one PIC18F26K80) were always successful on the first attempt, but in this case took two days looking for the problem.
Can anyone help me?
Thanks in advance ... _________________ MGLSOFT
Last edited by mglsoft on Fri Mar 08, 2013 12:05 pm; edited 1 time in total |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1346
|
|
Posted: Wed Mar 06, 2013 5:51 pm |
|
|
I don't know much about ECAN, so I cannot comment on that, but I would check your fuses for your oscillator config.
On most PIC24 chips, 10 MHz would be an XT fuse, not an HS. There are exceptions to that rule (the PIC24F32KA304 for example uses the same rules as a PIC18 for fuse selection), but you should verify with your data sheet that HS really should be used for the 10MHz.
Also, most PIC24 chips require at least 2 fuses set for the oscillator. One of them is a choice between:
HS,XT,EC,NOPR
The other fuse has choices like:
PR, FRC, LPRC, SOSC, PR_PLL, etc. (actual options vary by chip)
I'm not 100% sure that is your problem, but something to check and should be checkable via the datasheet. |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Thu Mar 07, 2013 4:26 am |
|
|
Is there another CAN node operating at the right speed on the bus? Maybe a CAN monitor, or any other known working node?
The problem is that the CAN peripheral requires acknowledgement of transmission.Any working node operating at the right speed will do, it doesn't have to do anything with the messages, and its filters don't have to accept the messages. A node all by itself wont see an acknowledgement and will resend until its error count exceeds the limit (I think 128 errors) and it will declare a bus fault; bus passive I think.
The CAN and ECAN can buffer at least three messages. If there's no other node, the first attempt gets resent continuously, the second and third are buffered, to be sent once the first has got through. Then the CAN peripheral is full and the fourth can_putd() will hang waiting for a CAN peripheral transmit buffer, and can_tbe() will always be false (it is a macro not a true function).
This sorts itself out once another working node is connected to the CAN bus.
I have tried to detect and deal with this error condition. Detecting it is not a problem, but I've never been able to reliably bring the CAN peripheral back online. Some sort of hard reset is required, but I've never managed to get anything to work reliably. The ECAN seems to work for a while, then starts loosing/ignoring some incoming messages.
There has to be two working nodes on any CAN bus for the peripheral to be able to send messages.
RF Developer |
|
|
mglsoft
Joined: 18 Feb 2008 Posts: 48
|
|
Posted: Thu Mar 07, 2013 5:36 am |
|
|
Jeremiah:
One thing I am sure, the xtal works and is properly configured, and that routine time timer2 Interruption, delivery 1 millisecond me perfectly.
So discard that part.
RF Developer:
The tests are made against at least one node in the other end of the cable and the CAN monitor also connected.
If the bus nodes connect two more, with PIC18F26K80, these tear immediately (after initialization breaks) to transmit on the bus, connected at the same point where I test the same node in development.
I think that rules out the possibility that no one answers with ack.
I read the macro Can_tbe () and ensures that only one is free transmicion buffer to receive the message, and thus able to transmit.
The funny thing is that doing debug, I realize that even goes there three times, but immediately the first attempt long passes, as the return value and is false.
That baffles me ...
News
I was reading in the microchip forum, and I think I have the same case, my PIC24 works at 3.3 V, while the MCP2551 works at 5V, so I'll change it to one of TI (SN65HVD235D) of 3.3 V to see if improvement.
Still do not understand because it does not make an attempt to communicate.
Just make the change, I will put the result.
I hope to be successful.
Thanks for answering. _________________ MGLSOFT |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Thu Mar 07, 2013 7:14 am |
|
|
mglsoft wrote: | I realize that even goes there three times, but immediately the first attempt long passes, as the return value and is false.
|
That is the behaviour that happens when no other node ACKs, just as I described - three messages buffered, first is sent over and over, lock-up with can_tbe() false on attempt to send forth message. This suggests that something else is wrong, like CAN-hi and CAN-Lo swapped somewhere, or its going at the wrong speed.
Your CAN timing set-up looks good for 250kbps from 10MHz clock. Maybe the crystal fuses are wrong.
I suspect the problem might be the pin_selects. I don't use the 24series PICs, so I'm sorry I can't help much, but I know this sort of problem - getting the pin functions wrong - happens quite often.
RF Developer |
|
|
mglsoft
Joined: 18 Feb 2008 Posts: 48
|
|
Posted: Thu Mar 07, 2013 2:26 pm |
|
|
News, bad of course ...
I change the MCP2551 for 3.3V transceiver , the IT I wrote before, and the result is the same, does not communicate in CanBus ...
No longer do, I hope to be enlightened, because this really killing me. _________________ MGLSOFT |
|
|
mglsoft
Joined: 18 Feb 2008 Posts: 48
|
|
Posted: Thu Mar 07, 2013 9:53 pm |
|
|
Now I put leds to visualize whether transmitted or received between the PIC24 and the CAN transceiver.
No light ever (seen from the oscilloscope), so just as I need not set, the pins of transmission and reception of CAN.
PPS is the [spam] which is killing me, and in my case, I have configured the UART pins from PPS and work, but in the case of CAN does not happen.
Someone who support me regarding the use of PPS??
Thanks in advance !! _________________ MGLSOFT |
|
|
mglsoft
Joined: 18 Feb 2008 Posts: 48
|
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1346
|
|
Posted: Fri Mar 08, 2013 7:45 am |
|
|
If you are running the most recent version of the compiler, you should alert CCS support so they can fix it. That's an old thread, so if no one ever reports that bug, then it will probably stay. |
|
|
mglsoft
Joined: 18 Feb 2008 Posts: 48
|
|
Posted: Fri Mar 08, 2013 7:52 am |
|
|
Even I could not test this solution, this day dawns complicated for me, but as soon as I do, I can report it.
Who to write??, Never report a bug, so do not know how ...
You do not know how to document it, if you can help me, will certainly result in improvements for all.
The new 4141 version I have it, but I'm still using the 4140. _________________ MGLSOFT |
|
|
mglsoft
Joined: 18 Feb 2008 Posts: 48
|
|
Posted: Fri Mar 08, 2013 12:05 pm |
|
|
With help, I could make a program that only test the functionality of the CAN Bus, using the instructions provided by CCS Pin_select.
Works fine, thus ruling out the possibility of problems in routing pin.
I'll take my code now, and debug it to make it work as I hope, in this case I am assured that no hardware problems.
I solved the issue by, when I have the code developed 100% working properly and put here the tips for those who are in a similar problem will be easier to get out of trouble.
Thanks to all who contributed with their ideas, part of the solution, I will be attentive to your consultations to help restore, if within my knowledge to. _________________ MGLSOFT |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|