I am reporting a bug in S32K3 Safety Peripheral Drivers (SPD) version 1.0.3, specifically in the eMcem module's XDM configuration file which prevents it from being imported into Elektrobit (EB) Tresos Studio.
Environment
┌───────────────────┬─────────────────────────────────────────┐
│ Item │ Version / Path │
├───────────────────┼─────────────────────────────────────────┤
│ MCU │ S32K344 (S32K3XX) │
├───────────────────┼─────────────────────────────────────────┤
│ SPD │ S32K3_SPD 1.0.3 (S32K3_SAF_1.0.3_D2306) │
├───────────────────┼─────────────────────────────────────────┤
│ RTD │ SW32K3_RTD 4.4 R21-11 3.0.0 P01 │
├───────────────────┼─────────────────────────────────────────┤
│ EB Tresos │ 29.0.0 (installed at C:\EB\tresos) │
├───────────────────┼─────────────────────────────────────────┤
│ S32 Design Studio │ 3.6.0 │
└───────────────────┴─────────────────────────────────────────┘
Issue Description
When attempting to import the eMcem module (eMcem_TS_T40D34M10I3R0) into an EB Tresos project, the XDM parser throws the following error:
▎ "Invalid Attribute 'a' for tag 'a'" at line 717 of config/eMcem.xdm
This prevents the eMcem module from being imported into any EB Tresos project entirely.
Root Cause Analysis
The file C:\NXP\S32K3_SPD_1.0.3\eclipse\plugins\eMcem_TS_T40D34M10I3R0\config\eMcem.xdm contains an invalid XDM schema structure at lines 715–718,in the RecoveryTimeoutEnabled parameter block:
Buggy code (lines 715–718):
The problem is the nested inside the element. According to the XDM schema (http://www.tresos.de/_projects/DataModel2/08/attribute.xsd), an element cannot
contain another element as a child.
The correct structure used by all other occurrences in the same file (e.g., the ReactionType parameter at lines 684–687)is:
Correct code:
This is the only occurrence of this malformed nesting in the entire eMcem.xdm file (20+ other IMPLEMENTATIONCONFIGCLASS blocks are correctly formed). It is clearly a copy-paste error during the SPD packaging process.
Verification
- The Bist module (Bist_TS_T40D34M10I3R0) and SafetyBase module (SafetyBase_TS_T40D34M10I3R0) from the same SPD 1.0.3 package do not have this bug —their .xdm files are correctly structured and import into EB Tresos without any
errors.
- I confirmed that the Bist.xdm file has zero occurrences of nested inside .
Why This Is a Deadlock
The META-INF/CRYPTOMANIFEST.MF and META-INF/CRYPTOMANIFESTSIG.MF files in the eMcem plugin contain DSA cryptographic signatures (Key ID: Freescale, Provider: dreisoft.tresos.launcher2.CryptoKeyProvider) for key plugin files including
config/eMcem.xdm. Any modification to the .xdm file —even a single-line fix —breaks the DSA signature verification, causing EB Tresos to reject the module with a license/integrity error.
This creates an irrecoverable deadlock:
- Cannot import with the bug —XDM schema validation fails
- Cannot fix the bug —DSA signature verification fails →license error
- Cannot remove the signatures —EB Tresos fails to start (plugin integrity check)
Request
Please provide one of the following:
1. A hotfix release of SPD (or at minimum, a corrected eMcem.xdm file with updated CRYPTOMANIFEST signatures) compatible with our environment
2. An updated SPD version (e.g., 1.0.4 or newer) that includes this fix
3. A license re-activation or workaround that allows us to apply the necessary one-line fix to eMcem.xdm without triggering the DSA signature validation failure
4. Confirmation of whether a newer SPD version exists that resolves this issue, along with download/upgrade instructions
This issue is blocking our S32K344 safety software integration, specifically the eMcem (Extended Microcontroller Error Manager) module configuration in EB Tresos.
Additional Note
The SPD 1.0.3 Release Notes state compatibility with RTD 3.0.0 / 3.0.0 P07. We are using RTD 4.4 (SW32K3_RTD_4.4_R21-11_3.0.0_P01). Could you also confirm the compatibility status between SPD 1.0.3 and RTD 4.4, and advise if a newer
SPD version is required for RTD 4.x integration?
---
Thank you for your assistance. Please let me know if you need any additional information or logs.
Best regards.
Hello @WuDiDi,
The issue is also present in SPD 1.0.4.
I can see that it has been fixed in SPD 1.0.5 and SPD 1.0.6:
SPD version 1.0.5 is compatible with S32K3_S32M27x Real-Time Drivers ASR R21-11 Version 5.0.0 and 4.0.0.
Version 4.0.0 is supported for all derivatives except S32K3E ones (S32K39x and S32K36x).
SPD version 1.0.6 is compatible with S32K3 Real-Time Drivers Version 7.0.0 + 6.0.0.
Could you update to a newer RTD/SPD version?
Many RTD, SPD bug has been fixed since version 1.0.3.
Please note that NXP does not provide hotfixes for outdated software versions.
Regarding SPD 1.0.3 compatibility, we can only guarantee functionality with the RTD version explicitly specified in the release notes. Compatibility with other RTD versions is not guaranteed.
Regards,
Daniel
Thank you for the clarification. I am already using SPD 1.0.5 (D2503) with RTD 4.0.0 P01 for S32K342, so the version compatibility should be fine.
I have a specific question about implementation scope: the SPD 1.0.5 Demo project (S32_SPD_Demo) only provides TresosProject configurations for S32K344/S32K358/S32K388/S32K396, not S32K342. I am adapting it to S32K342.
Could you confirm the following for S32K342:
1. Lockstep fault injection: Does S32K342 support lockstep fault injection via the DCM/EIM mechanism? The S32K342 is a single-core lockstep device —I see EMCEM_DCM_NCF_3_LC_ERR and EMCEM_DCM_NCF_0_PLTFRM_CM7_0_LUP in the DCM fault
list. Are those the correct injection points?
2. LBIST/MBIST: The Bist_TS_T40D34M10I5R0 plugin has S32K342 EPD variants. Are the LBIST MISR golden signatures and MBIST partition tables in Bist_SpecificTables_S32K3XX.c already correct for S32K342 silicon? Do we need any
S32K342-specific adjustments?
3. Is there an application note or reference manual specifically for S32K342 safety verification (LBIST/MBIST/lockstep FI) that you can share?
Hi @WuDiDi,
The follow-up questions are not related to the original topic.
Could you please create a new thread for them?
Thank you.
BR, Daniel