We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I'm writting code for the above chip. I can receive messages into my application using the CAN simulator no problem. However, when I launch a message from my application, it is continuously re-transmitted (as seen on the can bus simulator). The TXOK flag is set OK and I get into my interrupt but, the only way I have been able to stop re-transmissions is by setting the CANCONCH register for the page to 0 and disabling the page. What am I doing wrong, should the simulator mimic a reply ACK to prevent multiple re-transmissions or is it my responsibility to disable further transmissions? Any clues? Regards Rob McKinley
You did not indicate is it data or remote frame we discuss about. Well, after a message object with data frame has been transmitted without errors then corresponding bit ENCHx of CANEN1/2 is cleared and CAN macro will not use this channel any more. Only one way to transmit it again is re-write CANCONCH of a message object. The strange thing I see is that TXOK bit has been set => so message object has been transmitted w/o errors. There are some possible reasons: - you re-enable transmission somewhere in your program yourself (check code again); - you do not clear TXOK flag before start transmission (you must do it each time to avoid dead loop on interrupt); - it is a bug in debugger/simulator. Please report result of your fix problem coz it is very interest problem for me (via private mail if so). Finally, as temporal workaroud: use TTC mode oc CAN macro - it will send a frame only one time even errors occur. Good days!
Agree with Oleg, also study aplication note 165 from Keil (a little hard to understand, but verry good) Example:
char CanSendIsr (unsigned char ch, unsigned char *p) { unsigned char i, typ; // check if CAN message object is defined for transmit if (ch >= sizeof (id_typ)) return (-1); typ = id_typ[ch]; if ((typ & CanCONCH) != CanTX) return (-1); i = typ & 0xF; // message length ECAN = 0; // disable CAN interupt CANPAGE = CanChannel(ch); // select CAN message object if ((CANCONCH & CanCONCH)) { // CAN channel busy? // yes copy to interrupt buffer memcpy (outbuf[ostart & (OLEN-1)], p, sizeof(outbuf[0])); ostart++; } else { // not, transfer to message object CANCONCH = 0; // reset previous status CANSTCH = 0; while (i) { // copy information to message buffer CANMSG = *p++; i--; } CANCONCH = typ; // send information } ECAN = 1; // enable CAN interupt return (0); }
Gentlemen, Thankyou for your replies, however, my main problem presists. How do I get the simulator to send an ACK back into my application? The simulator obviously knows a transmission has been send, because it registers it? As for how the simulator deals with the transmission, it does nothing with ENCHx, i.e it leaves it set and the CONCONCH still remains set for a transmission launch. When if forcefully reset these, in the TXOK interrupt, then the CAN simulator shows a second transmission has been started, then cancelled. Either, the simulator doesn't work or I am not setting it up correctly. For reference I am sending a simple 11bit identifier transmission - nothing fancy. Has anyone successfully got the simulator to correctly reply to a simple transmission launched from an application? Regards Rob McKinley
Hi, TTC (time-triggered communication) mode has been announced via ISO11898 standard. In this mode any node sends message(s) inside own time slot. In short, nodes listen for a sync message. When it has been detected, each node sets own delay (by your program - timer, cycle, etc) and after this pause sends a frame to the net. So by this method you may create a very stable net which will work even if alot of messages are transmitted there because the bus arbitration method will not block nodes with low priority identifiers (see: each node has own time slot). As side effect, if any error occurs then node cannot resend message itself because its time-slot has been gone. Instead it, software should wait till next sync message and resend a frame again inside own time-slot. Thanks for Temic/Atmel, the T89C51CC01 does support this method (TTC bit in CANGCON register). Manual says that CAN macro in TTC mode will send a frame only one time even errors occur. Hmm, my tests show that if no ACK bit detected then CAN macro try to send a frame again till TEC<127 even in TTC mode. Now I am clearing up this question with Atmel. Good days!
I had exactly the same problem with the same CAN message continually being sent due to no ack from a second CAN node. Recently this has gone away, I am pretty certain that it has been fixed in an update of the software in last few months. btw I am using 7.06a. Rob.
Cheers Rob, Good idea, I'll look into that one. RobMck
It is not a bug. Read Manual about CAN Data Layer again. Especially about Fault Confinement Rules. In short: CAN macro will resend a frame as long as it cannot be delivered to destination node without errors. If any error (include NO ACK error) occurs then CAN macro increases TEC (usualy by 8) and resends a frame. If TEC goes to Bus Off state then CAN macro waits for 11 consecutive recessive bits and goes back to Error Active state (here: retransmit a frame again). So I do not see what is the problem that a frame is resended and resended - it is just a work of CAN macro under Bosh CAN specification. The problem I told about is that in TTC mode CAN macro should not send a frame again, but it does... On my question Atmel tech says: > This is normal, it comes because you are in open loop so Rxd can not read Txd. Good days!
Oleg, I think you're missing the point to some extent. All that stuff you're writing about concerns the Atmel chip's end of the communication. The failure discussed by the original poster is on the other end of it. The problem at hand is that the destination node, in case of a programming running inside the Keil simulator, is really the simulator itself. The simulator would have to simulate the successful receipt of the message by at least one station on the CAN bus by generating the ACK condition. According to the OP, it fails to do that, and that would, indeed, constitute a bug. On at least one other CAN-enabled 8051 variant (the Dallas 80C390) I'm quite sure the simulator does that correctly --- I've been using that for about a year now. So it can be done, but the Atmel chip's simulation doesn't get it right. As to that comment about being in "open loop" from that Atmel technician: it cannot possibly apply to CAN bus transactions, ever. CAN is *always* in closed loop, in the sense that the receiver must watch the bus at all times, including those times when the chip itself is transmitting a message. That's part of the very definition of CAN bus.
I agree with you, Hans... Just one note: CAN is *always* in closed loop - try to pull out physical connector of the node and you have got open loop. Simulator does not know about has transmitter differencial line connected or does not. Realy, you should have this option in simulator otherwise you will not be able to simulate such situations when no node has received a frame from transmitter. Good days!
Dear Oleg Sergeev, Thank you very much for the superb explanations about TTC mode. Now i understund what this mode is and i will re-read the manual more carefuly. Also, if you have some news from Atmel regarding CAN macro problem in TTC mode, plz inform us: it's verry important. PS: Sorry to Robert for using his thread for a litte "of topic " subject, but Oleg's reply was so interesting that i must ask him some details. Cheers!!