FlexRay SPC56EL70L5

[David Staffenberger]

Posted on August 08, 2017 at 08:29

Hello community,

I am asking myself if there is actually anyone running FlexRay on the SPC56EL70L5 Board?

I am currently stuck in the wakeup process (I think that is where I am stuck), because the wakeup pattern does not get send. Does anyone have any experience with that?

Thanks in advance.

Best Regards,

David

[Erwan YVIN]

Posted on August 09, 2017 at 11:39

Hello David ,

Did you enable in Global Interrupt Flag and Enable Register (FR_GIFER) ?

WUPIE

Wakeup Interrupt Enable �? This flag controls if the Wakeup Interrupt line is asserted when theWUPIF flag is set.0 Disable interrupt line1 Enable interrupt line

  Best regards

   Erwan

[David Staffenberger]

Posted on August 09, 2017 at 12:01

Hello Erwan,

thank you for your answer, no I did not activate it but I think I ran into a different kind of problem in the meantime.

When I am starting the wakeup procedure I end up with having the wakeupstatus as transmitted although I cannot measure anything on the oscilloscope. Do you have any ideas what the problem might be?

I already tried to activate the interrupts but it didn't chance anything, but I will have a more detailed look into that.

Thanks in advance.

[Erwan YVIN]

Posted on August 09, 2017 at 17:16

Hello David ,

Did you configure the flexray pads ?

by Pinmap Wizard (SPC5Studio 5.5) or manually.

/* FlexRay Ports */
#define TXEA_PCR 47 /* MM.CON1:58 PC15 (MB.J3-N/C9) */
#define TXDA_PCR 48 /* MM.CON1:61 PD0 (MB.EMIOS0 ) */
#define RXDA_PCR 49 /* MM.CON1:62 PD1 (MB.EMIOS2 ) */
#define TXEB_PCR 52 /* MM.CON1:65 PD4 (MB.EMIOS9 ) */
#define TXDB_PCR 51 /* MM.CON1:64 PD3 (MB.EMIOS8 ) */
#define RXDB_PCR 50 /* MM.CON1:63 PD2 (MB.EMIOS4 ) */
#if 0
#define TXEA_PCR 13 /* MM.CON1:58 PC15 (MB.J3-N/C9) */
#define TXDA_PCR 12 /* MM.CON1:61 PD0 (MB.EMIOS0 ) */
#define RXDA_PCR 14 /* MM.CON1:62 PD1 (MB.EMIOS2 ) */
#define TXEB_PCR 16 /* MM.CON1:65 PD4 (MB.EMIOS9 ) */
#define TXDB_PCR 15 /* MM.CON1:64 PD3 (MB.EMIOS8 ) */
#define RXDB_PCR 17 /* MM.CON1:63 PD2 (MB.EMIOS4 ) */
#endif
/******************************************************************************/
/* Initialize the SIU */
/* - configure the flexray pads */ 
/* - configure the led pads */ 
/******************************************************************************/
void initSIU(void)
{
 
#if 0
 /* FlexRay Channel A */
 SIU.PCR[TXEA_PCR].R = 0x0A03; 
 SIU.PCR[TXDA_PCR].R = 0x0A03; 
 SIU.PCR[RXDA_PCR].R = 0x0903;
/* SIU.PCR[TXEA_PCR].R = 0x100C; 
 - SIU.PCR[TXDA_PCR].R = 0x100C; 
 - SIU.PCR[RXDA_PCR].R = 0x100C; */
#endif
 
#if 1
 /* FlexRay Channel A */
 SIU.PCR[TXEA_PCR].R = 0x0604; 
 SIU.PCR[TXDA_PCR].R = 0x0604; 
 SIU.PCR[RXDA_PCR].R = 0x0104;
 /* FlexRay Channel B */
 SIU.PCR[TXEB_PCR].R = 0x0604; 
 SIU.PCR[TXDB_PCR].R = 0x0604; 
 SIU.PCR[RXDB_PCR].R = 0x0104;
#endif
#if 0
 /* FlexRay Channel B */
 SIU.PCR[TXEB_PCR].R = 0x0A03; 
 SIU.PCR[TXDB_PCR].R = 0x0A03; 
 SIU.PCR[RXDB_PCR].R = 0x0903;
#endif
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

Best regards

Erwan

[David Staffenberger]

Posted on August 10, 2017 at 09:14

Hello Erwan, 

thank you again for your reply.

Yes I did configure them through the Pinmap Wizard. 

I just checked the indexes of each pin and they seem to be correct.

But the configuration of the mode seems to be wrong. I will try your configuration and come back with an update.

But assuming that it will not work I have some other questions.

How often does the wakeup signal get sent? Is it even possible to measure it on the oscilloscope?

Furthermore, does the controller even send the wakeup signal when there is just one controller? Or do I have to connect the second one aswell, because I am not quite sure yet about the second configuration.

Thank you in advance.

Best regards,

David.

[David Staffenberger]

Posted on August 10, 2017 at 12:52

So what I now experienced was the following.

First of all, it made no difference if I configured the pads manually or with the Wizard, although the mode is different (maybe that is going to be an issue later on, idk).

When debugging step by step through the program:

So when I send the wakeup signal, the wakeup status goes to TRANSMITTED, I don't measure anything, but it could be that I am just missing the signal since it is just transmitted once. I try to believe that I am seeing something on the oscilloscope, but somehow I am unable to trigger on that signal.

Then when I enable the coldstart possibility - nothing happens - but that is to be expected. Next step is to issue the RUN command by writing 5U into POR.PCCMD, after that the startup state goes to  POC:coldstart collision resolution and the Protstate to POC:startup and I am able to measure some frames. I think these are sync frames or something like that because the FID or HCRC is not something I configured.

Normally the PROTSTATE should to go POC:normal_active or POC:normal_passive as far as I know, but it stays at POC:startup.

The funky part starts when I do not debug the program but just let it run. Then I am not able to see anything on the bus. I am suspecting that there is some operation that needs more time to complete but I am waiting until the POCR.BSY bit is 0 again before every new bet I am setting.

Any suggestions/ideas on that 'case'?

Every idea I can try is appreciated.

Best regards,

David.

[Marcell Daniel]

Posted on August 10, 2017 at 14:02

Hello David,

If you set the protocol to Wakeup (POCCMD to wakeup in POCR) repeatedly with your while loop for example, the controller should send a wake up pattern each time. You can set the length of the low bits and the idle bits in the wake up symbol in the PCR registers. You can also set the wake up pattern which defines how many wake up symbol should the pattern contains. If you set it high it should be easier to measure with the scope. Note that depending on your configuration, the wakeup  pattern can be really short and hard to catch.

You should be able to see the wakeup pattern on both Tx and TxEN pin. Configuring the pins with the wizard worked for me. 

Regarding the startup, i suspect two nodes is needed to successfully start a cluster, but i am at the same state with my driver (only 1 node) so i cannot help you with that.You should be see one CAS symbol and few Startup/Sync frame.  You will find more information about the startup in the Protocol Specification chapter 7.2. 

Regarding the time, i experienced the same. Even though i wait the BSY flag to clear, sometimes the first few (5-10) PCR register remained unwritten. Temporarily I solved the problem with a sysWaitMilliseconds(50) command before my set_configuration function. You should check if the PCR registers are set in a normal run.

Edit:

I have also some questions about the FlexRay transceiver maybe you can help me out with. I am workig on an SPC560P disc board which has a TJA1080 transceiver. I power the board through USB (debug) but both BP and BMs voltage stay at zero. If I understand it correctly the bus should be in Idle state and I should be able to measure something on both BP and BM. BGE, STBN and EN are connected to VDD_HV. Do I need to connect an external power supply (12V) to the board to get the transceiver working?

Thanks for your help!

Regards,

   Marcell

[David Staffenberger]

Posted on August 10, 2017 at 14:53

Hello Marcell,

thank you for your answer, I was now able to measure the wakeup pattern, at least I think I did.

The PCR registers were set correctly, but I realized that I needed the delay before starting the communication so I put a delay in front of both functions. It does not hurt me since this is still just an example.

So when I am running the program I am seeing sync-frames on the scope (they are not ending, is that a problem?). Which is not too bad, but I am still in POC:startup. Since you suggested that I need a second node to get into POC:normal_active I need to implement something that would react on the wakeup pattern that is being sent, am I correct?

Thank you very much for your answers, they helped me alot.

EDIT:

I am not 100% sure about your board, I can only speak about mine. But what I have experienced is that I just have to power one board with the power supply and the other one can be powered by the FlexRay. Not sure if this is intended or how many boards you can power that way. 

Best regards,

David.

[Marcell Daniel]

Posted on August 10, 2017 at 16:12

Hello David,

The purpose of the wake up pattern is to wake up the nodes on the cluster from Standby or Sleep modes, if the node is already in normal mode i dont think it needs to react to the wakeup event. A start up process looks like this:

So as long as the second node didnt reach the normal active state, only the first node will transmit its sync frames. The sync frames should be send in every cycle in the specific slot.

Did you manage to send sync frames without connecting the nodes together (without connecting anything to the board)?

If you use 2 nodes you should read about:

• TT-L cluster
• Wake up, Start up process

About my question: So if you power your first board, both BP and BM are show some voltage (differ from zero)?

Just tested it, powering the board from an external supply (12V) solved the problem. The 5V from my laptops USB port wasnt enought for the transceiver for some reason.

Regards,

Marcell

[David Staffenberger]

Posted on August 11, 2017 at 07:26

Hello Marcell, 

thank you for clearing that up for me, I think I got the procedure now.

So I am sending the sync frames from my 'coldstart' controller, and I am able to see them on the scope.

I think my next step will be getting the other controller to send the sync frames as well and then see if both controller get into POC:normal_active state. And yes, I just checked, I do receive the sync frames on the scope when the bus is not connected to the controller.

I hope I understood that correctly now.

I really appreciate your help, it does help me a lot, thank you.

And I am really glad that you figured your problem out.

EDIT:

But I just realized that the FID and HCRC of the sync frames are now changing, yesterday they stayed the same through all tries. Now, when the bus is not connected, the FID and HCRC does not stay the same when I start it.

Could that be that these are just measuring errors? Because somehow I am dropping 60% of the incoming frames on the scope?

EDIT2:

I have a similar problem now with the power supply I think. When I measure the sync frames without the bus connected they have a range from 1.5V to 3.5V, but if I connect the bus the range drops down to 2V - 3V and the scope does not receive any frames anymore. Although both boards are connected to a 12V power supply.

EDIT3:

I resolved the problem with the voltage, it was just a bad cable.

EDIT4:

Yet another edit. I just took a more detailed look at the image you sent with your answer.

So from my understanding this means that actually node A (my coldstart controller) should come to POC:normal_active without node B sending anything right? Since this is not happening for me I am assuming that there is some sort of problem reaching the state because, as already mentioned, I am receiving the sync frames.

Furthermore node B (non coldstart) should be in either POC:integration_listen or POC:integration_consistency_check right? But it either resides in POC:coldstart_collision_resolution or POC:coldstart_listen (depending on wether the FR Pads are configured or not?). Those states should only be entered if coldstart node right? Am I missing something? Do I have to send the CAS by hand?

Best regards,

David.