 |
 |
| View previous topic :: View next topic |
| Author |
Message |
halibatsuiba
Joined: 12 Aug 2009
Posts: 30
|
|
 Posted: Fri Sep 18, 2009 7:45 am |
 |
|
| PCM programmer wrote: | I'll get a couple of 18F2580's and test it. It should work. I don't know
why it doesn't work for you. I won't have an answer until the middle
of next week. |
More observations:
I followed data signal from pic1 to pic2 with oscilloscope.
Oscilloscope shows data reaching pic2 but it does not cause anything in BnCON or RXBnCON registers.
So it looks like problem is not in between board 2 MCP2551 and PIC at all. Looks like problem is in board 2 PIC.
I checked the errata for silicon version I am using and there is nothing about CAN/ECAN. I am starting to believe that this is a sw problem after all. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Sep 18, 2009 12:22 pm |
|
|
Do you make local copies of the CCS CAN driver files (.c and .h)
and put them in your project directory ?
If you did, when you installed the new compiler, you would still be
using the old drivers, left over from your previous compiler version.
Make sure you're not accidently doing this. |
|
|
halibatsuiba
Joined: 12 Aug 2009
Posts: 30
|
|
| Posted: Fri Sep 18, 2009 7:26 pm |
|
|
| PCM programmer wrote: | Do you make local copies of the CCS CAN driver files (.c and .h)
and put them in your project directory ?
If you did, when you installed the new compiler, you would still be
using the old drivers, left over from your previous compiler version.
Make sure you're not accidently doing this. |
I never make local copies because it causes problems when updating tools.
And I also checked this to be sure. 
I don't have local copies of driver files.
Hardware issues are now confirmed not to be the cause of this problem. I bought another probe for my scope and now I can see PIC2 has exactly the same signal in RX pin what PIC1 sends.
"Screenshot" from scope screen.
So situation this far(my opinion):
- Loopback works = data PIC1 is sending is valid
- Signal in PIC1 Tx is exactly the same than in PIC2 RX
Problem is now officially isolated to PIC2's receiving functions. (Pcm? Do you agree?)
I will continue debugging tomorrow if I manage to escape from backyard work... |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Sep 18, 2009 7:28 pm |
|
|
I will receive the parts to duplicate your hardware, sometime next week.
I can't do too much on it until then. |
|
|
halibatsuiba
Joined: 12 Aug 2009
Posts: 30
|
|
| Posted: Fri Sep 18, 2009 8:16 pm |
|
|
| PCM programmer wrote: | I will receive the parts to duplicate your hardware, sometime next week.
I can't do too much on it until then. |
No problemo, I just post here my observations when I figure out something.
I have some ideas what to check tomorrow but more of that after I have done it.
Everybody have a nice weekend.  |
|
|
shashank27187
Joined: 28 Jul 2009
Posts: 13
|
| SAME HERE :) |
| Posted: Tue Sep 22, 2009 5:50 am |
|
|
actually.... i am also having the same problem...
I am using PIC 18f2585 for the two CAN nodes..
i have used pull ups and the termination resistors as well in the boards..
I used prototyping boards of CCS for CAN last week and got it done.... the programs worked very well.
The same programs after the desired modifications when used with pic 18f2585 gives problems.
The scope says that the receiver end does not receive anything and hence the program does not go inside the "can_kbhit()" part. My code is similar to the one posted here. The CANRX pin remains idle in the receiver whereas the transmitter actively keeps on sending the data.(these boards are connected to RS232 and are monitored in PC).
I think that the problem lies in the connection of the transceivers via CAN bus. I have used mcp2551 as well. Could you just let us know if we have done any mistake in the connection of transceivers, just tell us the best possible connection diagram or fwd the link pls.
I appreciate any valuable suggestions.
Thanks |
|
|
halibatsuiba
Joined: 12 Aug 2009
Posts: 30
|
| Re: SAME HERE :) |
| Posted: Tue Sep 22, 2009 9:28 pm |
|
|
| shashank27187 wrote: | actually.... i am also having the same problem...
I am using PIC 18f2585 for the two CAN nodes..
I think that the problem lies in the connection of the transceivers via CAN bus. I have used mcp2551 as well. Could you just let us know if we have done any mistake in the connection of transceivers, just tell us the best possible connection diagram or fwd the link pls.
|
In my case I don't think problem is in HW.
I captured data in PIC1's CANTX-pin and PIC2's CANRX-pin and they are identical.
I have been trying to "encrypt" said data with Bosch CAN specification v2.0 but no luck so far.
Either PIC1 sends some garbage (and PIC2 does not understand it, explaining why there is nothing in Rx buffers) or my capturing adds random bits there. 
Here is the schema of my connection. There is no mclr-circuit or filter caps in power pins but I think the connection between PIC and 2551 is ok.
My connection.
PCM programmer may have a different opinion when he gets back to this thread. Now we can just wait. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Sep 23, 2009 6:13 pm |
|
|
I built the circuits, compiled it with PCH vs. 4.099, and it all works
perfectly. I modified my two PicDem2-Plus boards to add sockets
for MCP2551 chips (with 120 ohm termination resistors). I have a
3-pin, 12 inch (30.5 cm) cable connected between the two boards
with wires for CANH, CANL, and GND. I have the Rs pin on each
MCP2551 connected to ground. The Vref pin is unconnected.
To test it, I started up a terminal program such as TeraTerm and typed in
some text (random asdf, followed by Hello There). It all works.
| Quote: | | asdfasdfadsffas Hello there |
Here's the code. This is the same as in the original post,
http://www.ccsinfo.com/forum/viewtopic.php?t=29627&start=6
except that the #include for the driver was changed to can-18F4580.c
because we are using the 18F2580, which is part of the 18F4580 family.
| Code: |
#include <18F2580.h>
#fuses HS, NOPROTECT, PUT, BROWNOUT, NOWDT, NOLVP
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
#include <can-18F4580.c> // Use correct driver
#define BOARD1_ID 24
#define BOARD2_ID 25
// Uncomment this line to compile code for Board #1.
// Comment it out to compile for Board #2.
#define BOARD1 1
//======================================
void main()
{
struct rx_stat rxstat;
int32 rx_id;
int32 tx_id;
int8 rx_len;
int8 buffer[8];
can_init();
#ifdef BOARD1 // For Board #1
while(1)
{
buffer[0] = getc(); // Wait for a character
// Transmit it to board #2.
can_putd(BOARD2_ID, buffer, 1, 1, 1, 0);
buffer[0] = 0; // Clear the buffer byte
// Wait for the char to be echoed back.
while(!can_kbhit());
if(can_getd(rx_id, buffer, rx_len, rxstat))
{
if(rx_id == BOARD1_ID) // Is it for this board ?
{
putc(buffer[0]); // If so, display the char
}
}
}
#else // For Board #2
while(1)
{
if(can_kbhit()) // Message available ?
{
// If so, get the message.
if(can_getd(rx_id, buffer, rx_len, rxstat))
{
if(rx_id == BOARD2_ID) // Is it for this board ?
{
// If so, echo back the character.
can_putd(BOARD1_ID, buffer, 1, 1, 1, 0);
}
}
}
}
#endif
}
|
My advice is:
1. Check your connections. Make sure there is a ground wire between
the two boards.
2. Make sure that you really are compiling two versions of the code,
one for Board #1 and another for Board #2. To compile for #1,
you use this line:
To compile for #2, you use this line:
| Quote: | | // #define BOARD1 1 |
Note that it's commented out for #2. The #define is not changed in any
way, except that it's commented out. It's not changed to '2', or 'FALSE'
or anything like that.
3. Final suggestion: Do it exactly like this, with the RS-232 terminal
for input and output. Don't use a debugger. Don't use a simulator.
Don't single-step through it or use breakpoints. Just run it. |
|
|
halibatsuiba
Joined: 12 Aug 2009
Posts: 30
|
|
| Posted: Wed Sep 23, 2009 8:24 pm |
|
|
| PCM programmer wrote: |
My advice is:
1. Check your connections. Make sure there is a ground wire between
the two boards.
2. Make sure that you really are compiling two versions of the code,
one for Board #1 and another for Board #2. To compile for #1,
you use this line:
To compile for #2, you use this line:
| Quote: | | // #define BOARD1 1 |
Note that it's commented out for #2. The #define is not changed in any
way, except that it's commented out. It's not changed to '2', or 'FALSE'
or anything like that.
3. Final suggestion: Do it exactly like this, with the RS-232 terminal
for input and output. Don't use a debugger. Don't use a simulator.
Don't single-step through it or use breakpoints. Just run it. |
1: Check
2: Check
3: Heh... I just realized I don't have serial port in any of my PCs(laptops). I guess I need to buy some kind of adapter for that.
In the meanwhile:
If I change the board #1 program slightly
| Code: | | buffer[0] = getc(); // Wait for a character |
Changed to
| Code: | delay_ms(1000);
buffer[0] = 'x'; |
and
| Code: | | putc(buffer[0]); // If so, display the char |
changed to
| Code: | | printf("%c",buffer[0]); |
With those changes board #1 sends character 'x' once a second and if board #2 responds, prints reply to serial LCD.
This should work too, right? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
halibatsuiba
Joined: 12 Aug 2009
Posts: 30
|
|
| Posted: Thu Sep 24, 2009 8:43 am |
|
|
I tested this with USB-serial-adapter I found behind my mythtv-box. 
If I test with both boards: nothing
If I put board#1 to loopback mode: nothing.
If I modify board#1 code so that it sends character to serial TX every time it receives character to serial RX, I get characters to terminal screen --> connection between PC and PIC works.
PCM: Can you post the schematics of your test circuit? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Sep 24, 2009 2:06 pm |
|
|
| Quote: |
Can you post the schematics of your test circuit?
|
It's the same as your schematic, except that I don't use a resistor on
the Rs pins. They are connected to ground. |
|
|
halibatsuiba
Joined: 12 Aug 2009
Posts: 30
|
|
| Posted: Thu Sep 24, 2009 10:12 pm |
|
|
| PCM programmer wrote: |
It's the same as your schematic, except that I don't use a resistor on
the Rs pins. They are connected to ground. |
So now our circuits are identical.
There must be something wrong in board#1 because loopback did not work.
I switched boards and now loopback works. Sort of.
Terminal (PC) sends character 'a' (0x61) to board, board sees it as 'O' (0x4F) and sends it to CAN loopback where putc-function sends it back to PC.
PC shows character 'X' (0x58).
PC terminal sw is using 9600 8N1, as well is Pic.
Can someone explain this to me?
I will build yet another board tomorrow and continue with it.
Edit: I just built a null-modem cable and verified connection between two PCs. Works just fine, all sent characters are received as expected.
Problem is not in PC side. Interesting.
Edit2:
When using just this simple loop:
| Code: | while(1)
{
buffer[0] = getc(); // Wait for a character
putc(buffer[0]);
} |
Sending 'a' from PC terminal produces 'X' to terminal.
Usually this kind of behaviour is caused by baudrate mismatch between devices but I don't think it is the case this time. I tested changing baudrates in terminal side and in PIC-side. No effect.
Definition in 18F2580.c line 105 says:
| Code: | | #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) |
Baudrate is 9600 and I suppose other parameters are 8-N-1 if they are not defined there? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Sep 25, 2009 12:08 pm |
|
|
| Quote: | When using just this simple loop:
while(1)
{
buffer[0] = getc(); // Wait for a character
putc(buffer[0]);
}
Sending 'a' from PC terminal produces 'X' to terminal. |
Post your complete test program, which has the code shown above in it.
Post the compiler version that you are using.
Post a description of your RS232 hardware on your board.
i.e., Are you using a Max232A or similar type of chip ? |
|
|
halibatsuiba
Joined: 12 Aug 2009
Posts: 30
|
|
| Posted: Sun Sep 27, 2009 8:59 pm |
|
|
| PCM programmer wrote: |
Post your complete test program, which has the code shown above in it.
Post the compiler version that you are using.
Post a description of your RS232 hardware on your board.
i.e., Are you using a Max232A or similar type of chip ? |
It is your test code with this modification:
| Code: |
#include <18F2580.h>
#fuses HS, NOPROTECT, PUT, BROWNOUT, NOWDT, NOLVP
#use delay(clock=20000000)
//#use rs232(baud=115200,xmit=PIN_C6, rcv=PIN_C7,ERRORS)
#include <can-18F4580.c> // Use correct driver
#define BOARD1_ID 24
#define BOARD2_ID 25
// Uncomment this line to compile code for Board #1.
// Comment it out to compile for Board #2.
#define BOARD1 1
//======================================
void main()
{
struct rx_stat rxstat;
int32 rx_id;
int32 tx_id;
int8 rx_len;
int8 buffer[8];
can_init();
//can_set_mode(CAN_OP_LOOPBACK);
printf("Starttaillaan...");
#ifdef BOARD1 // For Board #1
while(1)
{
buffer[0] = getc(); // Wait for a character
putc(buffer[0]);
}/*
// Transmit it to board #2.
can_putd(BOARD2_ID, buffer, 1, 1, 1, 0);
buffer[0] = 0; // Clear the buffer byte
// Wait for the char to be echoed back.
while(!can_kbhit());
if(can_getd(rx_id, buffer, rx_len, rxstat))
{
if(rx_id == BOARD1_ID) // Is it for this board ?
{
putc(buffer[0]); // If so, display the char
}
}
}*/
#else // For Board #2
while(1)
{
if(can_kbhit()) // Message available ?
{
// If so, get the message.
if(can_getd(rx_id, buffer, rx_len, rxstat))
{
if(rx_id == BOARD2_ID) // Is it for this board ?
{
// If so, echo back the character.
can_putd(BOARD1_ID, buffer, 1, 1, 1, 0);
}
}
}
}
#endif
}
|
Compiler version:
| halibatsuiba wrote: |
Allright. Now I have PCH version 4.099 but... |
Circuit is the same what you have, and now I have Rs tied to ground too.
| PCM programmer wrote: |
It's the same as your schematic, except that I don't use a resistor on
the Rs pins. They are connected to ground. |
About RS232 hw: I replaced MAX232 in my circuit and now code above echoes everything back properly. Looks like I had defective MAX232.
If I set Board #1 to loopback mode, everything is echoed back to terminal as well.
Still nothing if I try to communicate with board #2 over CAN.
I rebuilt board #2 with all new components.
Debugging continues... |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
