This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: Running FreeRtos-EarlyCAN in MCU1_1 and MCU1_0 only running sciServer

Part Number: TDA4VM

Hello TI.

Some time ago, TI proposed to run sciServer in MCU1_0 as a task in RTOS environment because of:

1.- We wanted to boot from SBL

2.- SCIServer must be running in MCU1_0

3.- Best performance in terms of early CAN is running on MCU domain.

Here we are thinking in alternative because on restrictions in development. If we are debugging/pausing in this situation the MCU1_0, then other cores will be afected because SciServer will not provide services to the Sciclients running on them.We suspect that this could cause some crashes, that maybe won't be solved unless whole system reset is gerenerated.
Please, we would appreciate your impressions on this situation.

Then the alternative that we are thinking is runninng the SCIserver in MCU1_0, and Autosar/Freerots-EarlyCAN in MCU1_1. Could TI claify what disvavantages could have this approach vs the ones TI proposed? How would the performance be affected (in terms of Early CAN availability) with this solution?

Thanks

  • Hi Pablo,

    Here we are thinking in alternative because on restrictions in development. If we are debugging/pausing in this situation the MCU1_0, then other cores will be afected because SciServer will not provide services to the Sciclients running on them.We suspect that this could cause some crashes, that maybe won't be solved unless whole system reset is gerenerated.

    This is correct understanding, if sciserver is not running, nothing else will work and pausing the MCU1_0 can definitely lead to crash.

    Could TI claify what disvavantages could have this approach vs the ones TI proposed?

    The only concern is that you won't be able to run MCU1_0 in lockstep mode and also we have not tested this on our end. Some MCU1_1 dependencies might be missing in SDK which we are not building yet.

    Regards,
    Parth

  • Thanks. 

    What kind of dependencies? Is it planned to have them solved in next release SDK 9.0?

  • Hi Pablo,

    What kind of dependencies? Is it planned to have them solved in next release SDK 9.0?

    There could be some libraries that not built properly for MCU1_1. We are not testing this in SDK so not really sure if it work seamlessly. 
    This is not planned as well so it won't be available in 9.0.

    Regards,
    Parth

  • Hello Parth.

    Sorry for insist you, what libraries will be affected? Could you elaborate it?

    We are thinking to run AUTOSAR in MCU1_1, then we would need details about issues or resctrictions we could find in that solution that would impact in our development.

    We should evaluate the risks and advantages in both solutions (splitting and not), and if we would find some dependencies not covered, may be splitting would not be recomended.

    Does TI recomend splitting? 

    Many thanks

  • HI Pablo,

    Is this still open or has this been answered as part of our other discussions?

    Regards,
    Parth

  • Hi Parth,

    No, we are still waiting from your answers

    Thanks,

    Mònica

  • Hello Mònica, Pablo,

    Sorry for the delay in responding.

    About your question "what libraries will be affected? Could you elaborate it?", Parth only made a general statement. We have not tried to run Autosar on MUC1_1 and have no plan to do so, so Parth's point was just to highlight that something may go wrong, though that could simply be a missing .h file or similar.

    So you would have to assess this feasibility yourselves. We would support you the best we can, but our support would be limited there as it is not a use case that's supported on TDA4VM.


    Best regards,
    François.