Our Electronic Control Unit (ECU) is based on Renesas RH850F1L Microcontroller. We basically have closed loop control system. Outputs of this ECU power DC Motors to move Third-Row Minivan Seats. ECU inputs are coming from DC Motor. This feedback signal is hall pulses indicating whether motor is turning or not or whether seat is moving or not. The software running in the ECU talks to PC Based CAN tool. They talk over simple proprietary protocol. They basically talk over 11-bit CAN. When the seat is moving, every 10ms, software running in the ECU sends seat position message to PC Based CAN Tool. When seat is at position 1, position 1 message is sent to the tool. After 10ms, position 2 message is sent to the tool. After next 10ms, position 3 message is sent to the tool, and so on. If everything is working correctly, over 1000 consecutive position messages will be sent to the tool. Time between these messages will be about 10ms. The problem is that from time to time messages are getting missed. The message that don't make it to the tool also don't show up in the CAN log. First 80 position CAN messages are correctly sent by ECU and correctly received by the tool. Position messages 81 through 84 don't show up in the tool. Also, they don't show up in the CAN log. Position messages 85 to 122 are correctly sent by ECU and correctly received by the tool. Position message 123 doesn't show up in the tool. Also, it's missing from the CAN log. Position messages 124 to 177 will be correctly sent by ECU and correctly received by the tool. Position message 178 to 181 don't show up in the tool. Also, they don't show up in the CAN log. And so on. I'm using very complex CANoe Configuration File that was created by someone else. It's overwhelming. There are so many nodes, so many message in CAN Trace. From where do I begin to debug this problem. 11-bit proprietary protocol messages are exchanged between ECU and tool. Also, CANoe is sending so many messages. I don't even know what all these messages are. I have a hint as follows: Hint: CANoe sends messages to ECU in bursts. Instead, it needs to send them at slower rate. This might be the reason low priority position messages are missed from ECu. Turn off some nodes in CANoe. This shouldn't be ECU software problem because it's not sending messages in bursts. This is challenging problem for me because I don't have sufficient CANoe knowledge. Please help debug this problem. --------------------------------------- Posted through http://www.EmbeddedRelated.com
How to gain deep knowledge of Vector CANoe to solve missed CAN messages problem ?
Started by ●December 4, 2015
Reply by ●December 4, 20152015-12-04
Am 04.12.2015 um 22:21 schrieb learn:> The problem is that from time to time messages are getting missed. The > message that don't make it to the tool also don't show up in the CAN log.If that poses a serious problem to your usage of those data, that means that proprietary protocol of yours is ill-suited for use over CAN. CAN, like any multi-master shared-medium protocol, cannot guarantee successful delivery of every single message. That means protocols that are run across it must be able to tolerate the occasional missed message, and either request a re-transmission, or just cope with not having that particular packet at all.> I'm using very complex CANoe Configuration File that was created by > someone else. It's overwhelming. There are so many nodes, so many > message in CAN Trace.So, given you a) neither know nor care what all those message are for, and b) you're only interested in those few message of your own protocol, why are you even using that big simulation? I'll assume you do that because the real work environment of your ECU has all those nodes, too, sending just as many messages. So turning off some of the simulated nodes is not going to actually solve anything. It'll just make the simulation lose some similarity to the real environment. Unless you have some way of guaranteeing that similar message burst patterns cannot ever happen in real life, with multiple real ECUs on the bus instead of a single CANoe simulating them all, your problem is _not_ how to keep CANoe from producing those message bursts --- it's how to keep your protocol from breaking apart if they do happen. In a nutshell: this test run has exposed a flaw in your proprietary little protocol. You need to repair that flaw, not the test run.
Reply by ●December 5, 20152015-12-05
>Am 04.12.2015 um 22:21 schrieb learn: > >> The problem is that from time to time messages are getting missed.The>> message that don't make it to the tool also don't show up in the CANlog.> >If that poses a serious problem to your usage of those data, that means >that proprietary protocol of yours is ill-suited for use over CAN. > >CAN, like any multi-master shared-medium protocol, cannot guarantee >successful delivery of every single message. That means protocols that >are run across it must be able to tolerate the occasional missed >message, and either request a re-transmission, or just cope with not >having that particular packet at all. > >> I'm using very complex CANoe Configuration File that was created by >> someone else. It's overwhelming. There are so many nodes, so many >> message in CAN Trace. > >So, given you a) neither know nor care what all those message are for, >and b) you're only interested in those few message of your own protocol,>why are you even using that big simulation? I'll assume you do that >because the real work environment of your ECU has all those nodes, too, >sending just as many messages. So turning off some of the simulated >nodes is not going to actually solve anything. It'll just make the >simulation lose some similarity to the real environment. > >Unless you have some way of guaranteeing that similar message burst >patterns cannot ever happen in real life, with multiple real ECUs on the>bus instead of a single CANoe simulating them all, your problem is _not_>how to keep CANoe from producing those message bursts --- it's how to >keep your protocol from breaking apart if they do happen. > >In a nutshell: this test run has exposed a flaw in your proprietary >little protocol. You need to repair that flaw, not the test run.Thank you for steering us in the correct direction. How to find out what is ill suited about our protocol? And then how can we make it robust so messages aren't missed. What source(s) will provide me more information on lack of CAN robustness (missed messages can occur)? Yes, I'm using complex CAN configuration because it simulates real world environment. --------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●December 5, 20152015-12-05
On 5.12.15 20:33, learn wrote:>> Am 04.12.2015 um 22:21 schrieb learn: >> >>> The problem is that from time to time messages are getting missed. > The >>> message that don't make it to the tool also don't show up in the CAN > log. >> >> If that poses a serious problem to your usage of those data, that means >> that proprietary protocol of yours is ill-suited for use over CAN. >> >> CAN, like any multi-master shared-medium protocol, cannot guarantee >> successful delivery of every single message. That means protocols that >> are run across it must be able to tolerate the occasional missed >> message, and either request a re-transmission, or just cope with not >> having that particular packet at all. >> >>> I'm using very complex CANoe Configuration File that was created by >>> someone else. It's overwhelming. There are so many nodes, so many >>> message in CAN Trace. >> >> So, given you a) neither know nor care what all those message are for, >> and b) you're only interested in those few message of your own protocol, > >> why are you even using that big simulation? I'll assume you do that >> because the real work environment of your ECU has all those nodes, too, >> sending just as many messages. So turning off some of the simulated >> nodes is not going to actually solve anything. It'll just make the >> simulation lose some similarity to the real environment. >> >> Unless you have some way of guaranteeing that similar message burst >> patterns cannot ever happen in real life, with multiple real ECUs on the > >> bus instead of a single CANoe simulating them all, your problem is _not_ > >> how to keep CANoe from producing those message bursts --- it's how to >> keep your protocol from breaking apart if they do happen. >> >> In a nutshell: this test run has exposed a flaw in your proprietary >> little protocol. You need to repair that flaw, not the test run. > > > > Thank you for steering us in the correct direction. > > How to find out what is ill suited about our protocol? And then how can > we make it robust so messages aren't missed. > > What source(s) will provide me more information on lack of CAN robustness > (missed messages can occur)? > > Yes, I'm using complex CAN configuration because it simulates real world > environment.CAN is a broadcast datagram protocol. It in the nature of such protocols that messages occasionally get lost. Even UDP in the TCP/IP protocol suite has to accept lost datagrams, although it does not always use broadcast addressing. -- -TV
Reply by ●December 5, 20152015-12-05
Tauno Voipio wrote:> On 5.12.15 20:33, learn wrote: >>> Am 04.12.2015 um 22:21 schrieb learn: >>> >>>> The problem is that from time to time messages are getting missed. >> The >>>> message that don't make it to the tool also don't show up in the CAN >> log. >>> >>> If that poses a serious problem to your usage of those data, that means >>> that proprietary protocol of yours is ill-suited for use over CAN. >>> >>> CAN, like any multi-master shared-medium protocol, cannot guarantee >>> successful delivery of every single message. That means protocols that >>> are run across it must be able to tolerate the occasional missed >>> message, and either request a re-transmission, or just cope with not >>> having that particular packet at all. >>> >>>> I'm using very complex CANoe Configuration File that was created by >>>> someone else. It's overwhelming. There are so many nodes, so many >>>> message in CAN Trace. >>> >>> So, given you a) neither know nor care what all those message are for, >>> and b) you're only interested in those few message of your own protocol, >> >>> why are you even using that big simulation? I'll assume you do that >>> because the real work environment of your ECU has all those nodes, too, >>> sending just as many messages. So turning off some of the simulated >>> nodes is not going to actually solve anything. It'll just make the >>> simulation lose some similarity to the real environment. >>> >>> Unless you have some way of guaranteeing that similar message burst >>> patterns cannot ever happen in real life, with multiple real ECUs on the >> >>> bus instead of a single CANoe simulating them all, your problem is _not_ >> >>> how to keep CANoe from producing those message bursts --- it's how to >>> keep your protocol from breaking apart if they do happen. >>> >>> In a nutshell: this test run has exposed a flaw in your proprietary >>> little protocol. You need to repair that flaw, not the test run. >> >> >> >> Thank you for steering us in the correct direction. >> >> How to find out what is ill suited about our protocol? And then how can >> we make it robust so messages aren't missed. >> >> What source(s) will provide me more information on lack of CAN robustness >> (missed messages can occur)? >> >> Yes, I'm using complex CAN configuration because it simulates real world >> environment. > > > CAN is a broadcast datagram protocol. It in the nature of such > protocols that messages occasionally get lost. Even UDP in the > TCP/IP protocol suite has to accept lost datagrams, although > it does not always use broadcast addressing. >The addressing in CAN is about what's in the PDU, not where it's going or who it's from. -- Les Cargill
Reply by ●December 5, 20152015-12-05
On Fri, 4 Dec 2015 23:44:03 +0100, Hans-Bernhard Br�ker <HBBroeker@t-online.de> wrote:>Am 04.12.2015 um 22:21 schrieb learn: > >> The problem is that from time to time messages are getting missed. The >> message that don't make it to the tool also don't show up in the CAN log.The problem with the OP's case seems to be that the messages are lost somewhere between the receiver station terminal and the final application.>If that poses a serious problem to your usage of those data, that means >that proprietary protocol of yours is ill-suited for use over CAN.That is the real issue.>CAN, like any multi-master shared-medium protocol, cannot guarantee >successful delivery of every single message.Sorry to be pedantic but as you know that CAN is actually only one of the few protocols in which the transmitting station knows when the correct signal is delivered to each receiving station terminals. The other question is can that signal be transferred to the application.>That means protocols that >are run across it must be able to tolerate the occasional missed >message, and either request a re-transmission, or just cope with not >having that particular packet at all.As I have said many times regarding real time control systems: 1.) you can have some time specific unreliable information transfer (e.g. UDP) 2.) you can have reliable connections but no real time predictability (e.g.. TCP) There is no "correct" solution, but you have to select case by case what to use.
Reply by ●December 6, 20152015-12-06
On 05/12/15 23:00, upsidedown@downunder.com wrote:> On Fri, 4 Dec 2015 23:44:03 +0100, Hans-Bernhard Br�ker > <HBBroeker@t-online.de> wrote: > >> Am 04.12.2015 um 22:21 schrieb learn: >> >>> The problem is that from time to time messages are getting missed. The >>> message that don't make it to the tool also don't show up in the CAN log. > > The problem with the OP's case seems to be that the messages are lost > somewhere between the receiver station terminal and the final > application. > >> If that poses a serious problem to your usage of those data, that means >> that proprietary protocol of yours is ill-suited for use over CAN. > > That is the real issue. > >> CAN, like any multi-master shared-medium protocol, cannot guarantee >> successful delivery of every single message. > > Sorry to be pedantic but as you know that CAN is actually only one of > the few protocols in which the transmitting station knows when the > correct signal is delivered to each receiving station terminals. >That's not /quite/ true. CAN can see that the telegram has been successfully transmitted to at least one other node - but you have no guarantee that it is received by /all/ nodes. It takes an unusual bad bus topology to get a situation where some nodes can receive a telegram correctly while others get errors, but it is possible - and may be worth considering if there are lots of nodes on the bus, or it is poorly terminated, or laid out in something other than a linear bus. Also note that all CAN controllers on the bus will send an acknowledge bit if the telegram is seen in the correct format, with the correct CRC check - it says nothing about the CAN controller being set up correctly to receive the message.> The other question is can that signal be transferred to the > application.Indeed.> >> That means protocols that >> are run across it must be able to tolerate the occasional missed >> message, and either request a re-transmission, or just cope with not >> having that particular packet at all. > > As I have said many times regarding real time control systems: > > 1.) you can have some time specific unreliable information transfer > (e.g. UDP) > > 2.) you can have reliable connections but no real time predictability > (e.g.. TCP) > > There is no "correct" solution, but you have to select case by case > what to use. >Yes.
Reply by ●December 6, 20152015-12-06
>> In a nutshell: this test run has exposed a flaw in your proprietary >> little protocol. You need to repair that flaw, not the test run.> How to find out what is ill suited about our protocol?I already told you that: it's the fact that it appears to assume that every single message will successfully make it onto the bus. That assumption has turned out to be incorrect.> And then how can we make it robust so messages aren't missed.The point I was explaining to you is that you _can't_ make messages not be missed. You'll have to build a protocol that can withstand missed messages to some extent, or at least notice that messages didn't arrive.
Reply by ●December 6, 20152015-12-06
Am 05.12.2015 um 21:03 schrieb Les Cargill:> Tauno Voipio wrote:>> CAN is a broadcast datagram protocol. It in the nature of such >> protocols that messages occasionally get lost. Even UDP in the >> TCP/IP protocol suite has to accept lost datagrams, although >> it does not always use broadcast addressing.> The addressing in CAN is about what's in the PDU, not where it's going > or who it's from.It has to imply who it's from, if only because otherwise there would be unresolved collisions between two nodes sending messages bearing the same ID, and starting simultaneously.
Reply by ●December 6, 20152015-12-06
Am 05.12.2015 um 23:00 schrieb upsidedown@downunder.com:> On Fri, 4 Dec 2015 23:44:03 +0100, Hans-Bernhard Br�ker > <HBBroeker@t-online.de> wrote:>>> The problem is that from time to time messages are getting missed. The >>> message that don't make it to the tool also don't show up in the CAN log. > > The problem with the OP's case seems to be that the messages are lost > somewhere between the receiver station terminal and the final > application.I don't think so. If they had gotten lost inside the receiver, they would at least have shown up in the CAN log, which I'm assuming is made by CANoe, separate from the receiver itself.>> CAN, like any multi-master shared-medium protocol, cannot guarantee >> successful delivery of every single message.> Sorry to be pedantic but as you know that CAN is actually only one of > the few protocols in which the transmitting station knows when the > correct signal is delivered to each receiving station terminals.Except that it doesn't, for at least two reasons: 1) The CAN ACKknowledge field is essentially a wired OR, i.e. the transmitter gets a successful ACK if any other active node saw a correctly formed message --- there's no requirement for every node to agree on that. 2) ACK does not depend on actual delivery of the received message. Even if a message is blocked by a node's input filters, it will still be ACKed by that node.
