CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC24HJ : ECAN Module problem (Solved)

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
mglsoft



Joined: 18 Feb 2008
Posts: 48

View user's profile Send private message

PIC24HJ : ECAN Module problem (Solved)
PostPosted: Wed Mar 06, 2013 12:29 pm     Reply with quote

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: 1321

View user's profile Send private message

PostPosted: Wed Mar 06, 2013 5:51 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Mar 07, 2013 4:26 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Mar 07, 2013 5:36 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Mar 07, 2013 7:14 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Mar 07, 2013 2:26 pm     Reply with quote

News, bad of course ...Embarassed Embarassed

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

View user's profile Send private message

PostPosted: Thu Mar 07, 2013 9:53 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Mar 08, 2013 6:51 am     Reply with quote

The solution here >>> http://www.ccsinfo.com/forum/viewtopic.php?t=39189&highlight=pinselect
_________________
MGLSOFT
jeremiah



Joined: 20 Jul 2010
Posts: 1321

View user's profile Send private message

PostPosted: Fri Mar 08, 2013 7:45 am     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Mar 08, 2013 7:52 am     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Mar 08, 2013 12:05 pm     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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