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.

TMS570LS1227: EB Tresos v21.0.0 is not compatible with our 02.22.03 MCAL package due to a different signature type expectation

Part Number: TMS570LS1227

Hello,

Our project uses the 02.22.03 MCAL package for the TMS570LS1227 micro, which have always been configured using EB Tresos v14.3.2 - with TI providing us valid Tresos licences throughout our development. However, following the most recent licence expiry we were told that the licensing model had changed and that we could no longer be provided with a licence for this version of Tresos. We were advised to update to the more recent v21.0.0 of EB Tresos, and were provided with a valid licence for this newer tool.

However, we have been able to configure & generate the MCALs using this newer v21.0.0 EB Tresos. A support request opened directly with Elektrobit appears to have established that this newer version of EB Tresos is not compatible with our MCAL package - specifically that the licensed version of EB Tresos v21.0.0 uses a newer type of signature for working with MCALs (EB_TS_MOD_SGNTI), whereas our MCAL package supports an older type (EB_TS_MOD_SGNTexas_Instruments). See below for detailed information from Elektrobit.

This issue is now critical and is holding up further development of our project, so we would like to see it resolved in one of two ways:

- Allow us to continue to use v14.3.2 EB Tresos as we have done previously by providing a suitable licence

- Provide us with an MCAL package compatible with v21.0.0 EB Tresos that we have been instructed to move to for licensing reasons (note that this is not an ideal solution as we would then be unable to reconfigure & regenerate MCALs from frozen codebase snapshots that are currently in production)

Many thanks.

[DETAILED ERROR INFORMATION FROM ELEKTROBIT]:

as the provided signature key "EB_TS_MOD_SGNTexas_Instruments" will belong to an older ACG version than the EB tresos Studio 21.0.0 you are using, please check with TI to provide you some consistent package to solve your current issue.

this issue occurs as MCAL module will require "EB_TS_MOD_SGNTexas_Instruments" license but your license will provide "EB_TS_MOD_SGNTI". Please check with MCAL vendor if they can provide you a package with current signature"

  • Hello Adam,

    The latest MCAL driver for LS1227 is Rev6.0. Can you try this new version on V21.0.0 EB tresos?

  • Hello, thank you for your response.

    Could you please tell me how I can download Rev6.0 of the LS1227 MCAL?

    Many thanks,
    Adam

  • Hello,

    Your access to the MCAL for TMS570LS1227 is enabled. You should receive an email from the TI mySecureSW system with a link to the installer soon.

  • Thank you. I have downloaded the latest MCAL and will now attempt to integrate it and test its configuration via Tresos.

  • The integration of MCAL 06.00.00 has resolved almost all of the licensing issues with EB Tresos v21.0.0, but I am still seeing an issue with the Pwm MCAL (see below).
    I am using the EB Tresos licence ending -1F5D as provided by you, and while I can now configure & validate the other MCAL drivers I still get the following errors reported for Pwm:

    PWM12120 No valid license found for module "Pwm_TI_TMS570LSx"

    PWM19015 Illegal signature key for file {path_removed}\Tresos\plugins\Pwm_TI_TMS570LSx\META-INF\CRYPTOMANIFEST.MF

  • Please make sure that this folder in plugins has the files for the latest MCAL driver.

    I use EB Tresos 21 and MCAL 6.0, and didn't see this kind of issue. 

  • The Tresos plugins directory did have all of the latest MCAL files, and Tresos was happy with all other modules apart from Pwm (see the attached screenshot). However, on inspection of each MCAL driver's CRYPTOMANIFEST.MF files I observed that all but the Pwm file ended with two line feed characters (0x0A) - and the Pwm CRYPTOMANIFEST.MF had only a single 0x0A. This was observed immediately following installation of the MCAL, and the running of the 4.0.3 batch file.

    After manually adding a second 0x0A to the Pwm driver's CRYPTOMANIFEST.MF this issue was resolved, and Tresos was then happy with the Pwm module.

    Incidentally there were two further manual edits needed to the Port & Spi driver's generate_swcd/swcd_definitions/*_definition_bswmd.arxml files, which after installation each contained a trailing 0x1A byte after the closing </AUTOSAR> tag. The Da Vinci Configurator tool refused to even open the configuration until these bytes had been deleted.

    I am now able to continue my assessment of the new Tresos/MCAL solution.

  • Thanks Adam for the information.

    I checked the Pwm CRYPTOMANIFEST.MF, but could not see the 0x0A at the end of the file. Can you please post a screenshot to show me where the 0x0A is located. Thanks

  • The 0x0A characters at the end of the CRYPTOMANIFEST.MF files can be seen when the file is viewed in hex form. When the file is viewed in a text editor they are seen as new-lines, as 0x0A is the ASCII code for a line-feed.

    This is the Pwm CRYPTOMANIFEST.MF directly after installation viewed as hex, and you can see a single 0x0A at the end:

    This corresponds to a single new-line at the end of the file when viewed in a text editor:

    However, all other drivers have two 0x0A bytes at the end of the file - this is the Adc file as an example:

    Which corresponds to two new-lines at the end of the file when viewed in a text editor:

    Tresos complains of a signature error for the Pwm module after MCAL installation, but the error is resolved when an extra 0x0A is added to the end of its CRYPTOMANIFEST.MF file to match the others.

  • Hello,

    Unfortunately the suggestion of updating to the Rev6.0 MCAL drivers and the latest EB Tresos is not a workable solution for us. We have been informed by our AUTOSAR BSW provider that we cannot update to later versions of the TI MCALs without considerable expense, time & effort.

    The only option left to us therefore is to be able to continue using the MCALs we currently have integrated (v02.22.03) with the version of EB Tresos that can configure & generate them (v14.3.2), as we have been doing since our project began. This is our preferred solution for a number of reasons.

    The inability to configure & generate our MCAL drivers is now causing serious issues with our delivery schedule. Please could TI provide us a licence to continue to use the software & tools that we have been using now for a number of years, or perhaps we would be able to discuss this separately with the relevant parties in order to get this issue resolved as soon as possible.

    Many thanks.

  • Hello Adam,

    TI only provides one-year EBTresos evaluation license for the MCAL configuration. Now we provide one-year license to use v21.0.0 EB Tresos, and I don't think TI will buy another license for v14.3 EB tools. 

  • Hi QJ,

    I work with Adam on this project. We need to understand this in more detail, this issue presents a serious problem for us and we need the resolution Adam describes. Can you get us in contact with someone that can assist further please? 

    regards,

    Gummi

  • Hello Gummi,

    I just made a friend request, lets talk offline. Thanks

  • working on this issue offline.