I am using an LPC2378 (MCB2300 demo board) in a CAN communication setup to a single node. The other node is using proven code (on a LPC2129), I am just trying to talk to it using my own code. I'm using the CAN library built into the RTX, which seems pretty simple.
I perform a successful send:
message.id = CANid_getinfo|1; //CAN board id#1 message.data[0] = 0x01; //get info from sensor #1 CAN_send(1,&message,0);
This is followed by:
while(1){ manifest = CAN_receive(1,&message,0xffff); //0xfff = wait indefinitely for msg if(manifest == CAN_OK){ //do stuff here
The message is received properly and the other board begins transmitting. The problem is I never get out of my CAN_receive function - the system then hangs forever in the os_idle_demon task (note the calling task for the above code IS still running).
OK, maybe the CAN bus has an issue - but if I change the timeout (RTX is using 10msec ticks)
manifest = CAN_receive(1,&message,0x10)
it STILL freezes. The RTX timeout won't work for any value! Only by changing the timeout to zero does the code continue - but I never get CAN_OK, only CAN_TIMEOUT_ERROR.
I am convinced this is something stupid I'm missing, not being too familiar with using the RTX kernel...
Thanks for any help
*bump* Anybody?
I use all-own code for my CAN communications - but does the driver code perform the proper isr_xxx() calls so the RTX scheduler knows that it should wake up any CAN listener to process received data? The RTX scheduler doesn't care that the ISR might be trigged - it needs the ISR to perform any action that motivates any scheduling operation. So the ISR needs to signal an event, send a message or similar.
I ended up solving this issue - I agree that writing your own code is probably the way to go, but I was just trying to prove out my hardware at this point. I've found that CAN lends itself to using seperate tasks, as in Keil's included example program, for sending and receiving. I abandoned the earlier code for this setup. This likely helped with the other problem I had, which was - Stack size. By increasing the User/System stack size it helped get me out of some further hangups. I was stuck when os_dly_wait decided to hang up shortly thereafter. Hope this helps someone else someday...