For a (custom developed) S32K148 based board. there are two choices for drivers in the 'Peripherals' view: 'MCAL' and 'Drivers'. For a bare-metal software project (i.e. NOT using the Autosar OS (or any OS), which is the right choice?
It seems most of the functionality of the chip is duplicated in these two choices. What is confusing to me is that choosing mutually contradictory choices in the two ways does not result in an error. For example, disabling cache support in 'Mcl' in the 'MCAL' menu and enabling it in 'Cache_Ip' in the 'Drivers' menu does not result in an error, as shown below. Is this how it is supposed to be, and in that case, which of the two configurations has priority?
Hi @durga_choudhury,
However, based on what I can see from the included examples, the 'BaseNXP' driver from the Non-Autosar layer is required in all cases. Is that right?
Yes, the BaseNXP module includes general AUTOSAR and hardware specific register files. Inside its user manual (RTD_BASENXP_UM.pdf), you can find the driver's deviations from requirements, driver limitations, and some other useful information:
Given that, would you still recommend the non-Autosar drivers?
None of our chips are specifically made for aerospace. S32K1x covers up to Functional Safety ISO 26262 compliant ASIL-B with RTD AUTOSAR drivers. So, I guess I would recommend AUTOSAR drivers in this case.
ASIL-B has an approximate cross-domain to DAL-C. If the standard you are following fits to ASIL-B/DAL-C, then it may be easier to fulfill the requirements. PL-IVN products are AEC-Q100 automotive certified at component level.
Just keep in mind that it is up to our customers to perform an assessment, and related certifications meet their aerospace requirements.
If you are looking for some sort of qualification kit, you might check with IAR or GreenHills, they would have something for this family of devices. You can also refer to this page for partners and some applications: Avionics | NXP Semiconductors.
Another aspect of this is that we are porting an existing codebase that was created with 'Processor Expert' in the legacy S32DS for ARM. I understand that the non-Autosar drivers are more fine grained. Do you think the Autosar drivers provide enough features to port from PE generated code?
I think there should be no issue porting over PE generated code, as RTD should cover full functionality for the devices. You may have to examine which functions are the correct fit for the old code, but you can use the following application note as a guide for structure changes, migration guidelines, etc: AN13435: SDK/MCAL to Real-Time Drivers - Application Note.
Hope this is clear enough.
Best regards,
Julián
Hi @durga_choudhury,
For a bare-metal implementation, my suggestion is the "Drivers" layer. The RTD package include two interfaces MCAL (HLD) & IP/Drivers (LLD). These can be chosen depending on your goals.
- AUTOSAR by creating a rich ecosystem, considering Complex Device Drivers (CDD) and a wide range of standard drivers
- Non-AUTOSAR applications for low-level drivers for highly optimized code
You can find further information in this training presentation: 02: S32K3xx Real-Time Drivers (RTD) Installation Guide - Training.
As for the two configurations, if you decide to mix MCAL and Drivers, please keep in mind some considerations:
1. It is forbidden to use the same hardware instance in HLD and LLD. For example, I've configured both SPI0 in MCAL and Drivers. This pops an error between the containers:
2. IP layer does not provide a Tresos configuration (AUTOSAR schema XML format). It can be configured only on Design Studio (CT).
3. IP layer cannot be used in AUTOSAR applications, as it does not satisfy ASR compliance constraints (DEM, DET, Multicore). IP layer should not be seen as a CDD.
I think that Enable CACHE support option does not create an error since it does not directly affect the hardware, rather the “Enable Cache” just enables the support for cache in Mcl module. This option does not enable the cache directly:
Best regards,
Julián
Hi @durga_choudhury,
However, based on what I can see from the included examples, the 'BaseNXP' driver from the Non-Autosar layer is required in all cases. Is that right?
Yes, the BaseNXP module includes general AUTOSAR and hardware specific register files. Inside its user manual (RTD_BASENXP_UM.pdf), you can find the driver's deviations from requirements, driver limitations, and some other useful information:
Given that, would you still recommend the non-Autosar drivers?
None of our chips are specifically made for aerospace. S32K1x covers up to Functional Safety ISO 26262 compliant ASIL-B with RTD AUTOSAR drivers. So, I guess I would recommend AUTOSAR drivers in this case.
ASIL-B has an approximate cross-domain to DAL-C. If the standard you are following fits to ASIL-B/DAL-C, then it may be easier to fulfill the requirements. PL-IVN products are AEC-Q100 automotive certified at component level.
Just keep in mind that it is up to our customers to perform an assessment, and related certifications meet their aerospace requirements.
If you are looking for some sort of qualification kit, you might check with IAR or GreenHills, they would have something for this family of devices. You can also refer to this page for partners and some applications: Avionics | NXP Semiconductors.
Another aspect of this is that we are porting an existing codebase that was created with 'Processor Expert' in the legacy S32DS for ARM. I understand that the non-Autosar drivers are more fine grained. Do you think the Autosar drivers provide enough features to port from PE generated code?
I think there should be no issue porting over PE generated code, as RTD should cover full functionality for the devices. You may have to examine which functions are the correct fit for the old code, but you can use the following application note as a guide for structure changes, migration guidelines, etc: AN13435: SDK/MCAL to Real-Time Drivers - Application Note.
Hope this is clear enough.
Best regards,
Julián
