- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2301564_en-US
2301564_en-US
2301564_en-US
2301564_en-US
I pulled the S32K344 svd file ( S32K344.svd ) from the S32DS and I'm attempting to use it, but there appear to be hundreds of bugs in how the file is constructed.
For example, in the MUXSEL registers (from section 62.8.10 in the Reference Manual) are defined in the SVD file like so:
But the name field for all the enumerated values (LU_IN0 to LU_IN11) are all "lu_in" which causes errors when storing them as enumerations (multiple definitions of the symbol "lu_in"). Additionally - the enumeration doesn't even correctly cover the space. LU_IN should have values between 1 and 12 (0x1 to 0xC) and instead the enumeration only goes up to 0x9.
As another example, register MDACFG0 field NMDAR has an enumeration which essentially serves no purpose except to be broken.
Similar to the lu_in example, the enumerations all list "NUMBER" as the name of every enumeration.
Register RRCR0 has field RR_INITMOD which has essentially the same issue with an enumeration MOD_1_63 which also only covers a portion of the possible enumerated values.
Is there anyone I can reach out to in order to get this corrected? These issues are a pretty major impediment to our ability to use S32K3XX chips.
Hello @kscz ,
Unfortunately, at this time, there is no official NXP Rust support for S32K3.
You can create a small script to remove/rename duplicities before feeding the SVD to svd2rust.
Best regards,
Pavel
I'm a little confused - you are correct that I would like to use Rust with this chip, but the issues I've laid out here are fundamental to how anyone would use this SVD file - whether for CMSIS or Rust.
The enumerations for things like MUXSEL and RR_INITMOD only covering some of the possible values seems like a bug. The name field being the same for all the enumerations of any field seems like a bug.
I'm not trying to ask for explicit support from NXP for Rust, I'm asking for the SVD file to be fixed!
Hello @kscz ,
I see your point. I reported your query to the software team.
Thank you for reporting that.
Best regards,
Pavel
Any word on how long I should wait for an update?
Hello @kscz ,
I haven't received an update from development team yet. I increased the priority.
Since the svd file is a part of RTD, I would expect the fix in the next RTD release.
Best regards,
Pavel
The S32K388 SVD file has many, many more bugs - do I need to document these as well? Are there plans to update this one like the S32K344 as well?
Hello @kscz ,
Thank you for reporting the issue. I forwarded it to the SW team and increased the priority.
Best regards,
Pavel