Posted on August 11, 2017 at 12:49
Hello David,
1.)
Node B should be
integration_listen
state just like you said. I think you left the part in your code for Node B which set the controller into POC:allow coldstart.
Example:
/***********************************************/
// flexray_allow_coldstart(&Flex1);
sysWaitMilliseconds(90UL);
flexray_start_communication(&Flex1);�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?If I dont include the allow_coldstart part the POC ends in the
integration_listen state:
2.)
Could that be that the
FID and HCRC are from different frames sent by different nodes? You should try to configure to usethe keyslot as a startup / sync frame so you know what do you need to see on the scope.
3.)
Accordint to the specification: A TT-L coldstart node always finishes the startup after six cycles. What I still dont know how the controller knows that he is a TT-D or a TT-L coldstart node. I think the reason that your Noda A does not stop transmitting his sync frames is because he think that he is a TT-D cs node. Here is the image of the TT-D coldstart startup:
I will give you an update if I find anything out.
As for the rest I am still trying to get the node to send some sync frames soI havent had the chance to test the rest of the protocol
Regards,
Marcell
Ps: Alternatively, I cluster with two coldstart nodes also should be able to start the communication completely. Pay attention to the correct configuration of the startup frames to avoid collisions.
Edit:
Just guessing but it might work:
Set thegClusterDriftDamping to 0 (zero)
A TT-L coldstart node needs to act like the cluster contains two coldstart nodes -> a non-sync node shouldnt recognise the difference between a TT-D and a TT-L cluster. So your coldstart nodes need to transmit two startup frame in each cycle so it would look like there is two coldstart node on the channel. For this you should:
SetpTwoKeySlotMode to TRUE
Set the ID for the second keyslot (Assuming your first keyslot id's is 1, setting it to 2 shall work)
And the action point offset need to calculate in a different way. What is your value for the action point offset?
Edit 2:
It looks like only FlexRay Protocol Specification 3.0 supports the TT-L cluster type and the SPC56xx microcontroller series implements the 2.1 version so you should ignore what i said about the single node startup.
From the spec.:
In clusters consisting of less than three nodes, each node shall be a coldstart node. Each startup frame shall also be a sync frame; therefore each coldstart node will also be a sync node. The parameter gColdStartAttempts shall be configured to be at least two. At least two fault-free coldstart nodes are necessary for the cluster to start up.
Posted on August 16, 2017 at 09:57
Hello David,
Yes I mixed up a little bit the version numbers and I wrote a few false thing about the startup, so to clear it up:
- The nxp and st controllers (as far as I know, even the new ones) implements the 2.1 version of the protocol, NOT the 3.0 so everything I said about the TT-L and TT-D clusters is not implemented and should be ignored. Here is a if you want to read about it (from page 29 and 176).
- The startup needs at least two coldstart nodes, one leading and one following. The following coldstart node should be able to see that the coldstart process has been started on the channel. (maybe delay a bit the transition to the startup state on the following node should work?) The following node should end in the Coldstart Join state before reaching the normal active state
- The two nodes need to have different key slot IDs obviously so they would not be transmitted in the same slot. Keep in mind that what you see on the scope is containing the coding sequences (TSS, FSS, BSS), so if you want to decode the frame segments exclude those.
- For the configuration I use a sample from the Nxp guys as well.
Best Regards
Marcell
