AUTOSAR-MCAL-Embedded-Upskilling-Bootcamp

AUTOSAR MCAL Embedded Upskilling Bootcamp

This repo contains the projects, codes, examples, exercises and results for the “AUTOSAR MCAL Embedded Upskilling Bootcamp” by Modular MX.

Date: July, 2024.

• The Certificate and Badge are available.

Table of Contents

<-- Back to Top of Page

1. Description
2. Hardware Requirements
3. Software Requirements
4. Setup Notes
5. Documentation
6. Examples and Exercises
7. Final Project
8. Sample Evidences

1. Description

<-- Back to Table of Contents

This AUTOSAR Upskilling Bootcamp, focused on MCAL layer, shows how to configure multiple peripherals that can be found in the microcontroller hardware by making use of Automotive industry tools. This Upskilling consists on 6 weeks, where 10% is theory and the 90% remaining is practice and hands-on.

By working through examples and exercises that use the NXP S32K144 board, the Modular MX Modular-S1 board and tools like Elektrobit Tresos, SEGGER Ozone debugger, and SavvyCAN, you’ll gain an understanding on configuring, generating, and developing highly efficient low-level drivers and analyze their utilization in Classic AUTOSAR.

The Upskilling Bootcamp covers:

1. Introduction to AUTOSAR MCAL and EB Tresos.
2. PORT driver.
3. DIO driver.
4. MCU driver.
5. GPT Driver.
6. Platform Driver.
7. ADC driver.
8. PWM driver.
9. SPI driver.
10. I/O Hardware Abstraction.
11. CAN driver.
12. CANIF driver.
13. Final Project.

What it’s covered from the Classic AUTOSAR layers perspective:

2. Hardware Requirements

<-- Back to Table of Contents

NXP S32K144-Q100 Evaluation Board for Automotive General Purpose - Based on the 32-bit Arm® Cortex®-M4F S32K14 MCU, this is the base board used in this bootcamp.

Modular-S1 Board - Board developed by Modular MX, comes with a whole new layer of additional peripherals customized specifically for NXP S32K144. Contains 2 potentiometers, 1 buzzer, 3 push buttons, 8 leds, general purpose inputs-outputs, USB Hub, CAN analyzer, 24 MHz logic analyzer, SPI display, 2 SPI Eeproms, and external CAN & LIN analyzer connectors.

NXP S32K144 Board + Modular-S1 Board:

3. Software Requirements

<-- Back to Table of Contents

EB Tresos Studio - Tool environment for electronic control unit (ECU) development with AUTOSAR. EB tresos Studio lets you configure, validate, and generate your ECU basic software (BSW). EB tresos Studio is the industry-standard tool for microcontroller abstraction layer (MCAL) development by semiconductor suppliers such as NXP, STM, and Infineon. Works on Windows and is free.

SEGGER Ozone - Full-featured graphical debugger for embedded applications. It is possible to debug any embedded application on C/C++ source and assembly level, as well as loading applications built with any tool chain / IDE or debug the target’s resident application without any source. Ozone includes all well-known debug controls and information windows and makes use of the best performance of J-Link and J-Trace debug probes. Works on Windows/Linux/Mac and is free.

SavvyCAN - It is a CAN bus reverse engineering and capture tool. SavvyCAN can use any CAN interface supported by QT’s SerialBus system (PeakCAN, Vector, SocketCAN, J2534, etc). It can capture and send to multiple buses and CAN capture devices at once. Works on Windows/Linux/Mac and is free.

4. Setup Notes

<-- Back to Table of Contents

You can find here Setup AUTOSAR Tools the section where Modular MX explains the right procedure to download, install and configure all needed tools, including its dependencies, how to import the template project file and flash it to the device.

Same information is presented here, with the steps to follow in order to have the environment set up with all tools FREE of charge:

• NXP / EB Tresos tools installation.
• SEGGER tools installation.
• Importing the EB Tresos template project file.
• Compiling and flashing the project to the device.
• Ozone .jdebug portable files for running debugger.
• Configuring SavvyCAN.

NXP / EB Tresos tools installation:

Back to Setup Notes

1. Create your own NXP account.
2. Go to Real-Time Drivers RTD. You should scroll until you reach the Download section for the Real-Time Drivers for S32K1. Click on Download and will open a new website that asks to log-in using your account.

3. You should have reached this area called Product Information: Automotive SW - S32K1 - Real-Time Drivers where we will download the Real-Time Drivers for S32K1 as well as EB Tresos Studio

4. First let’s download EB tresos Studio / AUTOSAR Configuration Tool. Click on the second option and then click on EB tresos Studio 29.0.0 which as of now is the latest version.

5. You will see Software Terms and Conditions, click ‘I Agree’ and then we will see the main Product Download section. Download EBTresosStudio_EBTresosStudio.uip, EB_Client_License_Administrator_1_5_1_Setup.exe and setup.exe. Place all the files in a folder, the EBTresosStudio_EBTresosStudio.uip might be downloaded automatically as a .zip file. In case it is not, change the file extension from .uip to .zip, then extract. Execute setup.exe and click Install.

6. Once the EB Tresos tool is installed, notice that in the website there was a text highlighted in yellow that contains the chain of characters for the license code. Input that in the EB Client License Administrator.

7. Now let’s download S32K1_S32M24x - Real-Time Drivers for Cortex-M. Go back and click on the first option and then download latest version which at the moment of writing this is S32K1-S32M24X Real Time Drivers AUTOSAR R21-11 Version 2.0.0 P04.

8. VERY IMPORTANT: At the moment of installing it do not forget to point it out to the EB Tresos install path!

9. Now we need a compiler, let’s download the GCC NXP. Scroll down until you reach the Downloads section and there look up for this item as in the image: NXP Embedded GCC 10.2 Compiler Tools for ARM v7 Embedded, build 1728 - Windows. Proceed to install. (Only the compiler is needed, not the S32 Design Studio.)

SEGGER tools installation:

Back to Setup Notes

1. For the Debugger, the hardware board provided by Modular MX is programmed with SEGGER J-Link to flash and debug the microcontroller. In case you acquire separately the NXP S32K144, you need to switch from OpenSDA for J-Link. Go to Setup AUTOSAR Tools and perform the steps in section Switching OpenSDA for J-Link.

2. After that, drivers are needed so go to SEGGER J-Link official page and download and install the latest version of J-Link Software and Documentation Pack.

3. For SEGGER Ozone Debugger download and install the latest version.

Importing the EB Tresos template project file:

Back to Setup Notes

1. Git clone the project (that also comes with a makefile to compile the basic example in there and run it into the hardware board).

2. Open EB Tresos, go to File → Import…, then select General → Existing Projects into Workspace, then Next and Browse… the project folder (the cloned repository), click check on the ‘template-s144’ project and Finish.

3. Select the project and double click in template-s144 → template-s144 (CORTEXM, S32K14X) to display all the modules in use, then just click the hammer icon ‘Generate code for the currently selected project’.

4. Might see a warning dialog box regarding Module Configurations. Just ignore, those are not required due to the license type.

Compiling and flashing the project to the device:

Back to Setup Notes

1. You can work your code using VS Code, open the terminal and select bash as the shell (please avoid powershell). Type ‘cd’ then leave an empty space ’ ’ and then drag and drop your project folder to insert the path and then Enter. You should be ready to start compiling. Type ‘make’ and wait for it to finish, should see something like this:

renatosoriano@RENATOSORIAD632 MINGW64 /c/EB/tresos/workspace/template-s144 (master)
$ make
...
...
/c/NXP/gcc-10.2-arm32-eabi/bin/arm-none-eabi-objcopy -Oihex Build/temp.elf Build/temp.hex
/c/NXP/gcc-10.2-arm32-eabi/bin/arm-none-eabi-objdump -S Build/temp.elf > Build/temp.lst
/c/NXP/gcc-10.2-arm32-eabi/bin/arm-none-eabi-size --format=berkeley Build/temp.elf
   text    data     bss     dec     hex filename
  31384      40    2464   33888    8460 Build/temp.elf

2. After compiling we can flash the microcontroller using Ozone. Open the program and click in File → New → New Project Wizard.

3. Configure the fields Device, Register Set and Peripherals as in the image below and then clik Next two times.

4. Then in the following page select the .elf file that was generated after Build, then Next and Finish.

5. Go to File → Save Project as… and select a name for your .jdebug file (recommend the same name as the Tresos project). Then go to File → Edit Project File… and a window should open with the .jdebug file code configuration. Reference the note below Ozone .jdebug portable files for running debugger to make sure you are configuring correctly and portable your file.

6. Click the first green icon (that looks like a ‘Power ON/OFF’ icon) to download the binary into the microcontroller. You might see some pop-up small dialog windows while loading, just click ‘Yes’ and the initial Green icon now should be Red. The program execution is now halted and ready to begin, so click the second icon (currently a ‘Play’ icon) to Resume program Execution and see the hardware board working by blinking an LED.

7. And that’s it! Don’t forget to read Ozone documentation to get familiar with all the amazing functions it provides (call stack, disassembly, registers, memory), it is really powerful.

Ozone .jdebug portable files for running debugger:

Back to Setup Notes

1. After generating MCAL source files with EB Tresos Studio IDE and building the project, we need to make use of the .jdebug files that I’m providing in order to be capable or flashing the board with Ozone as well as for debugging.

2. These files after generated were modified to be portable (using $(ProjectDir)), hence no need to be modified again and are ready to be executed.

3. Below you can see an example of the snippet for the .jdebug configuration file for any given project.

/*********************************************************************
*                                                                     
*       OnProjectLoad                                                 
*                                                                     
* Function description                                                
*   Project load routine. Required.                                   
*                                                                     
**********************************************************************
*/                                                                    
void OnProjectLoad (void) {
  //
  // Dialog-generated settings
  //
  Project.AddPathSubstitute ("C:/EB/tresos/workspace/template-s144", "$(ProjectDir)");
  Project.AddPathSubstitute ("c:/eb/tresos/workspace/template-s144", "$(ProjectDir)");
  Project.SetDevice ("S32K144");
  Project.SetHostIF ("USB", "");
  Project.SetTargetIF ("JTAG");
  Project.SetTIFSpeed ("4 MHz");
  Project.AddSvdFile ("$(InstallDir)/Config/CPU/Cortex-M4F.svd");
  //Project.AddSvdFile ("C:/EB/tresos/workspace/template-s144/S32K144.svd");
  Project.AddSvdFile ("$(ProjectDir)/S32K144.svd");
  //
  // User settings
  //
  File.Open ("$(ProjectDir)/Build/temp.elf");
}

Configuring SavvyCAN:

Back to Setup Notes

1. SavvyCAN is an open source project that allows to send, receive and decode CAN messages. It does not require specific installation or driver, just unzip and run the corresponding executable for your OS. (For this software I used MacOS but is exactly the same for Windows).

2. Once the software is open, plug the board and we should be able to see a new COM port in your computer. The software has several options for connection types, in this case the one used is very common and easy to configure. Once the program in the hardware board is running, go to menu bar and click Connection → Open Connection Window, then click in Add New Device Connection.

3. A new window will pop up and select LAWICEL / SLCAN Serial, then select the corresponding serial port of the device just connected and the following settings: Serial Port Speed: 115200 and CAN Bus Speed: 100000 (this CAN speed can be changed later on once the CAN exercises are executed with the corresponding baudrate configuration in EB Tresos).

MacOS perspective:

Windows perspective:

4. After setting up connection the new device should be added to the list with status Connected.

5. Close connection window and go back to he main interface. If hardware board is running a CAN Tresos project (example or exercise) then CAN traffic should be seen immediately.

MacOS perspective:

Windows perspective:

6. To be able to send CAN messages go to Send Frames → Custom. There we can customize the frames we need as for the Bus, ID, Length, Data, and even Trigger periodicity. Once it is configured we can Start/Stop sending each message by checking/unchecking the box in the first column or use the Enable/Disable All buttons at the bottom.

7. And that’s it! Now you can play with CAN communication by Transmitting (Tx) and Receiving (Rx) data between the hardware board and the host PC. If you want to dive deeper into this tool you can watch these videos:

• SavvyCAN Walkthrough Part 1
• Fuzzing and CAN sending with SavvyCAN
• CAN Bus Interface & Logger + SavvyCAN [USB | SD | Free Software]

5. Documentation

<-- Back to Table of Contents

You can find here the Documentation reference regarding:

• AUTOSAR Driver Specification.
• NXP EB Tresos MCAL drivers Integration/User Manuals.
• NXP EB Tresos S32K144 MCAL drivers Project Examples.
• Compiler Manuals.
• NXP S32K144 Board.
• Modular S-1 Board.
• SEGGER Tools.

6. Examples and Exercises

<-- Back to Table of Contents

You can find here Tresos Workspace the base template file as well as all the examples and exercises created for this Upskilling Bootcamp. It is divided in folders for each of the MCAL drivers worked, and inside you will find 2 folders, Examples and Exercises.

1. Templates: Tresos Project and Ozone Semihosting RTT.
2. DIO and PORT driver.
3. MCU driver.
4. GPT driver.
5. Platform driver.
6. ADC driver.
7. PWM driver.
8. SPI driver.
9. I/O Hardware Abstraction.
10. CAN driver.
11. CANIF driver.

For easier understanding using EB Tresos, when doing each of the MCAL Modules Examples and Exercises, highly recommend going to Documentation and read NXP EB Tresos MCAL drivers Integration/User Manuals, they explain how to configure each MCAL from the EB Tresos GUI perspective. Here is an example:

Even more interesting, NXP provides within the RTD driver installation a series of NXP EB Tresos S32K144 MCAL drivers Project Examples that can be used as reference for each of the MCAL Modules in EB Tresos. These are located in:

C:\NXP\SW32K1_S32M24x_RTD_R21-11_2.0.0_P04\eclipse\plugins\<Driver>_TS_T40D2M20I0R0\examples\EBT\S32K1

where ‘Driver’ can be any of the MCAL modules like ‘Dio’, ‘Port’, ‘Spi’, etc.

To use them copy the project example folder of interest and paste it into the workspace folder, for instance:

C:\NXP\SW32K1_S32M24x_RTD_R21-11_2.0.0_P04\eclipse\plugins\Can_43_FLEXCAN_TS_T40D2M20I0R0\examples\EBT\S32K1\Can_example_S32K144

Copy to:

C:\EB\tresos\workspace\Can_example_S32K144

After that and similar to any other project, follow the already explained import process by opening EB Tresos, cliking on File → Import → General → Existing Projects into Workspace, then Next and Browse… the project folder of the NXP example just copied, click check on the project and Finish.

Once the project is imported now is time to build it. CLOSE EB TRESOS and open the project in VS Code since there are a few modifications that need to be done.

Proced to open the file readme.txt and read the general instructions for configuration. What those instructions say is to open project_parameters.mk and update the following variables with the correct paths: ‘TRESOS_DIR’, ‘GCC_DIR’, ‘PLUGINS_DIR’ as well as comment out ‘T32_DIR’ since it will not be used. The image below shows an example on how the file must be in the end:

Now open check_build_params.mk and comment the last lines because TRACE32 will not be used.

After modifying and saving the changes, open the terminal and select bash as the shell (please avoid powershell). Type ‘cd’ then leave an empty space ’ ’ and then drag and drop your project folder to insert the path and then Enter. You should be ready to start compiling. Do not forget to CLOSE EB TRESOS otherwise the following ‘make generate’ will fail.

First type ‘make clean’ and wait for it to finish, after that type ‘make generate’ and wait for it to finish, lastly type ‘make build’ and wait for it to finish. Should see something like this:

renatosoriano@RENATOSORIAD632 MINGW64 /c/EB/tresos/workspace/Can_example_S32K144
$ make clean
======================================================================
Removing files and directories from the compliation output

renatosoriano@RENATOSORIAD632 MINGW64 /c/EB/tresos/workspace/Can_example_S32K144
$ make generate
C:/EB/tresos/bin/tresos_cmd.bat generate Can_example_S32K144 2>&1
EB tresos Studio 29.0.0 b220329-0119
Copyright 2003-2022 Elektrobit Automotive GmbH
Current workspace: C:\EB\tresos\workspace
Generating project Can_example_S32K144
INFO 24-07-31,23:47:00 (12145) Using a shortened feature name ("EB_TS_MOD_USPlatform_TS_T40D2M" instead of "EB_TS_MOD_USPlatform_TS_T40D2M20I0R0") for license check.
INFO 24-07-31,23:47:00 (12145) Using a shortened feature name ("EB_TS_MOD_USPlatform_TS_T40D2M" instead of "EB_TS_MOD_USPlatform_TS_T40D2M20I0R0") for license check.
INFO 24-07-31,23:47:00 (12145) Using a shortened feature name ("EB_TS_MOD_USPlatform_TS_T40D2M" instead of "EB_TS_MOD_USPlatform_TS_T40D2M20I0R0") for license check.
...
...
INFO 24-07-31,23:48:11 (13030) Running generator "EcuC_TS_T40D2M20I0R0_UniqueNGGeneratorId" in mode "generate" for module "EcuC_TS_T40D2M20I0R0"
INFO 24-07-31,23:48:11 (13030) Running generator "Can_43_FLEXCAN_TS_T40D2M20I0R0_UniqueNGGeneratorId" in mode "generate" for module "Can_43_FLEXCAN_TS_T40D2M20I0R0"
INFO 24-07-31,23:48:12 (13030) Running generator "Mcu_TS_T40D2M20I0R0_UniqueNGGeneratorId" in mode "generate" for module "Mcu_TS_T40D2M20I0R0"
Errors "0" Warnings "0"

renatosoriano@RENATOSORIAD632 MINGW64 /c/EB/tresos/workspace/Can_example_S32K144
$ make build
======================================================================
Creating directory for object files
Compiling src/main.c
Compiling generate/src/CanIf_Cfg.c
Compiling generate/src/CanIf_PBcfg.c
Compiling generate/src/Can_43_FLEXCAN_Ipw_PBcfg.c
Compiling generate/src/Can_43_FLEXCAN_PBcfg.c
...
...
Compiling C:/NXP/SW32K1_S32M24x_RTD_R21-11_2.0.0_P04/eclipse/plugins/Rte_TS_T40D2M20I0R0/src/SchM_Can_43_FLEXCAN.c
Compiling C:/NXP/SW32K1_S32M24x_RTD_R21-11_2.0.0_P04/eclipse/plugins/Platform_TS_T40D2M20I0R0/startup/src/m4/gcc/Vector_Table.s
Compiling C:/NXP/SW32K1_S32M24x_RTD_R21-11_2.0.0_P04/eclipse/plugins/Platform_TS_T40D2M20I0R0/startup/src/m4/gcc/startup_cm4.s
Linking main.elf
c:/nxp/gcc-10.2-arm32-eabi/bin/../lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/bin/real-ld.exe: warning: c:/nxp/gcc-10.2-arm32-eabi/bin/../lib/gcc/arm-none-eabi/10.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libg_nano.a(lib_a-memset.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail

If your output is same as above that means the build was successful. The main.elf file can be found in the ‘Driver’_example_S32K144\out directory. Now is just a matter of doing the same process with Ozone in order to flash the project to the hardware board.

And that’s it! You can now open EB Tresos and explore the configuration, parameters, containers and properties of all NXP project examples to see what is going on, to analyze and compare with the examples and exercises of this Upskilling Bootcamp.

7. Final Project

<-- Back to Table of Contents

You can find here the Final Project created for this Upskilling Bootcamp. It consists on an AUTOSAR I/O Hardware Abstraction for the on board Buttons and LEDs (PORT and DIO Drivers), Potentiometers (MCU and ADC Drivers), and Buzzer (PWM Driver), all together with the Scheduler and a state machine with specific application tasks requirements and the following events, each with particular peripheral behaviors:

Button 1 Events:

• Button 1 Single Click Event
• Button 1 Double Click Event
• Button 1 Hold and Release Event

Button 2 Events:

• Button 2 Single Click Event
• Button 2 Double Click Event
• Button 2 Hold and Release Event

Button 3 Events:

• Button 3 Single Click Event
• Button 3 Double Click Event
• Button 3 Hold and Release Event

Button 1 Single Click:

Back to Final Project

• Shall toggle ON/OFF RGB_LED_BLUE (D0) and C10_LED2 (as SINGLE_CLICK visual indicator).

https://github.com/user-attachments/assets/7e254285-5b00-4ca3-b0b7-083ebd013bfa

Button 1 Double Click:

Back to Final Project

• Shall display (SEGGER_RTT_printf) Pot 1 ADC0 value in ohms, toggle C13_LED5 (as DOUBLE_CLICK visual indicator), and toggle C14_LED6 (as Pot 1 visual indicator).

https://github.com/user-attachments/assets/9f66e0b6-36a8-45d1-8fdf-4e0b84e6d62f

Button 1 Hold and Release:

Back to Final Project

• Buzzer shall start to beep and play Tone 1, then stop.

https://github.com/user-attachments/assets/b3b2fbca-c40f-4838-b6ee-8cbb92740021

Button 2 Single Click:

Back to Final Project

• Shall toggle ON/OFF RGB_LED_RED (D15) and C9_LED1 (as SINGLE_CLICK visual indicator).

https://github.com/user-attachments/assets/b4d3c5dc-a298-42aa-b5f8-e419363fc6f3

Button 2 Double Click:

Back to Final Project

• Shall display (SEGGER_RTT_printf) Pot 2 ADC0 value in ohms, toggle C12_LED4 (as DOUBLE_CLICK visual indicator), and toggle C15_LED7 (as Pot 2 visual indicator).

https://github.com/user-attachments/assets/9eea159c-86a7-4f8a-8b8b-228dc2623305

Button 2 Hold and Release:

Back to Final Project

• Buzzer shall start to beep and play Tone 2, then stop.

https://github.com/user-attachments/assets/41513747-1fff-478c-84a3-2e4da0ab3ca1

Button 3 Single Click:

Back to Final Project

• Shall toggle ON/OFF RGB_LED_GREEN (D16) and C8_LED0 (as SINGLE_CLICK visual indicator).

https://github.com/user-attachments/assets/2ae425f0-8526-4a7d-ba0b-80b507f2b16e

Button 3 Double Click:

Back to Final Project

• Shall display (SEGGER_RTT_printf) Pot 1 and Pot 2 ADC1 alternate values in ohms, toggle C11_LED3 (as DOUBLE_CLICK visual indicator), toggle C14_LED6 (as Pot 1 visual indicator), and toggle C15_LED7 (as Pot 2 visual indicator).

https://github.com/user-attachments/assets/2bfb6ac9-46a6-4cf8-8ef3-cd11ad5b9d95

Button 3 Hold and Release:

Back to Final Project

• Buzzer shall start to beep and play Tone 3, then stop.

https://github.com/user-attachments/assets/0583da24-9d69-4de4-affc-c40bbd631f13

8. Sample Evidences

<-- Back to Table of Contents

You can find here captures and media, relevant to examples and exercises, visible output in communication (software) or physical world (board).

• DIO-PORT Evidences.
• GPT Evidences.
• ADC Evidences.
• PWM Evidences.
• SPI Evidences.
• CAN Evidences.
• CANIF Evidences.

DIO-PORT Driver Evidences

Back to Sample Evidences

• DIO Exercise 8: Rotate LEDs Left-Right using Buttons

Pressing 1st button will rotate the LEDs from right to left, and pressing 2nd button will rotate them from left to right. 3rd button activates a different speed.

https://github.com/user-attachments/assets/80e7ae72-599a-454c-8cb2-881933acbc30

GPT Driver Evidences

Back to Sample Evidences

• GPT Exercise 1: Two Timers in OneShot mode using FIRC clock to toggle Two LEDs

Using two different timers (FTM1 and FTM2) to toggle two pairs of leds (1st pair: normal led C8 and Blue RGB led, 2nd pair: normal led C9 and Green RGB led) at 100ms and 300ms, both timers use notifications in one shot mode, plus been feed by FIRC clock at 12MHz.

https://github.com/user-attachments/assets/193ff80f-5500-420f-af6e-2be51721c8a4

• GPT Exercise 3: Three FTM Timers to toggle all RGB at different Frequencies

Using three FTM timers with one channel each, toggle the three RGB leds at different values (100ms, 400ms, and 800ms), the most important is that each FTM timer is feed by a different clock reference (12MHz, 4MHz, and 8MHz).

https://github.com/user-attachments/assets/51c8bdf2-141e-4744-be3b-26aa9c43fdc1

ADC Driver Evidences

Back to Sample Evidences

• ADC Exercise 1: Rotate Speed of Eight LEDs with Potentiometer

Vary the rotation speed of eight LEDs C8 to C15 using one of the potentiometers on the board.

https://github.com/user-attachments/assets/52fb87fa-588e-4ca8-92fe-8630d8d8d1d9

• ADC Exercise 2: Two Potentiometers, display Volts and Ohms

Display the values of the two potentiometers in Ohms and Volts.

• ADC Exercise 6: Four Channels in ADC0 using Two Potentiometers

Using a jumper wire to connect other channels available from ADC0 to have four channels to sample:

• Pot 1: pin PTB1->CH5 connected to pin PTB0->CH4 (Blue jumper wire).
• Pot 2: pin PTB13->CH8 (Interleaved, by default ADC0-CH8 is connected to PTC0 but changed to PTB13 using interleave function in code) connected to pin PTC1->CH9 (Purple jumper wire).

Also configure the hardware average sample with a value of 8, and calculate the total timing conversion for the entire group of channels.

ADC0 and ADC1 Interleaved Channels diagram from NXP S32K1xx Reference Manual Rev. 13, page 1194 and 1195:

PWM Driver Evidences

Back to Sample Evidences

• PWM Exercise 1: Two Channels, Two FTM Timers with SIRC Clock

A program that generates two PWM channels but using two different timers, must see which pins are available with FTM functionality. Feed those timers with a SIRC clock.

• Timer 1: FTM0, Channel: CH0, Pin: RED RGB LED.
• Timer 2: FTM2, Channel: CH0, Pin: BLUE RGB LED.

Both RGB LEDs working, hence the purple color.

• PWM Exercise 2: Two Complementary Channels with DeadTime Insertion

Generate two complement PWM signal with dead time insertion of around 1% of the period of the signal.

https://github.com/user-attachments/assets/dade5bbc-cec0-4004-9f04-f78ad7fcd22b

‘Paired channel enable’ Tresos feature: The channels n and n+1 will be used as a channel pair. In this case the pair is Red RGB Led (FTM0-CH0) for ‘channel n’ and Green RGB Led (FTM0-CH1) for ‘channel n+1’.

‘Complementary channel enable’ Tresos feature: Enable the complementary mode for Ftm channel. In Complementary mode, the channel (n+1) output (Green RGB Led) is the inverse of the channel (n) output (Red RGB Led).

‘Complementary mode’ Tresos feature: Selects complementary mode of the Ftm channel n+1. Here we confirm that the desired mode is ‘Invert Output’. Hence when one RGB Led goes OFF the other goes ON and viceversa.

‘Deadtime enable’ Tresos feature: Enable the deadtime delay for Ftm channel. The deadtime delay insertion ensures that no two complementary signals (channels n and n+1) drive the active state at the same time.

‘Phase Shift (Ticks)’ Tresos feature: Define the offset value (in tick) from 1 that the leading edge of pulse signal will start. In this case it is wanted to be 1% of the period, so the 375 ticks value is the 1% of the 37500 period value configured for the channels.

Channel (n+1) output in Complementary mode diagram from NXP S32K1xx Reference Manual Rev. 13, page 1448:

• PWM Exercise 4: ADC Potentiometer modifies PWM DutyCycle of RGB LED

Used a potentiometer to variate the PWM duty cycle, connected to Blue RGB led, from 10% to 90% in steps of 10%. Two available methods, with and without steps, can be found in code with algorithm explained.

https://github.com/user-attachments/assets/a163665e-de78-469f-a384-a67201327c4e

SPI Driver Evidences

Back to Sample Evidences

• SPI Exercise 1: Read and Print 32 bytes from EEPROM

Read and display the first 32 bytes of an Eeprom in different formats using Semihosting with RTT.

• SPI Exercise 4: Create Two Functions to Write and Read a Byte

Wrote two functions that allow to write and read a byte to any valid memory address in the Eeprom memory, functions shall have the following prototypes:

• void write_byte( uint16 addr, uint8 data );
• uint8_t read_byte( uint16_t addr );

• SPI Exercise 5: Create Two Functions to Write and Read Data from an Array of any Size of Bytes

Wrote the following functions to allow to write a given array of n number of bytes starting at any address of the eeprom:

• void write_data( uint16 addr, uint8 *data, uint8 size );
• void read_data( uint16 addr, uint8 *data, uint8 size );

CAN Driver Evidences

Back to Sample Evidences

• CAN Example 3: Transmission using Interrupts (ISRs)

Hardware board transmits (Tx) an 8-byte single message with ID 0x123 and specified Data payload: 01 02 03 04 05 06 11 12. Savvy CAN receiving (Rx) the data, everytime having byte 1 and 8 increased by value of 0x1 as per the example intentional behavior.

• CAN_Example 4: Reception using Interrupts (ISRs), Dataset 1

Hardware board receives (Rx) an 8-byte single message with ID 0x010 and specified Data payload: 32 01 01 01 01 01 01 01. Savvy CAN transmits (Tx) the data. Notice how in code we can establish a condition, in this case where the first byte must be 0x32 and once that is confirmed, can proceed and receive the rest of the data.

• CAN_Example 4: Reception using Interrupts (ISRs), Dataset 2

Similar as previous, hardware board receives (Rx) an 8-byte single message with ID 0x010 and specified Data payload: 32 08 07 06 05 04 03 02. Savvy CAN transmits (Tx) the data. Notice how in code we can establish a condition, in this case where the first byte must be 0x32 and once that is confirmed, can proceed and receive the rest of the data.

• CAN Example 5: Transmission Mailboxes Buffers

Hardware board transmits (Tx) three 8-byte messages with ID 0x123, 0x133 and 0x143, all having the same specified Data payload: 01 02 03 04 05 06 11 12. Savvy CAN receiving (Rx) the data, everytime having byte 1 and 8 increased by value of 0x1 as per the example intentional behavior.

• CAN Example 6: Reception with Filters, ID 0x1EF

Hardware board receives (Rx) every second an 8-byte single message with ID 0x1EF and specified Data payload: 32 00 00 00 01 02 03 04. Savvy CAN transmits (Tx) the data. Notice how in code we can establish a condition, in this case where the first byte must be 0x32 and once that is confirmed, can proceed and receive the rest of the data.

• CAN Example 6: Reception with Filters, ID 0x022

Hardware board receives (Rx) every second an 8-byte single message with ID 0x022 and specified Data payload: 32 00 00 00 05 06 07 08. Savvy CAN transmits (Tx) the data. Notice how in code we can establish a condition, in this case where the first byte must be 0x32 and once that is confirmed, can proceed and receive the rest of the data.

• CAN Exercise 3: Button Transmits Messages

Program that, upon pressing the button on the board, transmits a message with identifier 0x001 to the CAN bus, and upon releasing it, transmits a message with an identifier of 0x002. Hardware board transmits (Tx) two 8-byte messages with ID 0x001 and 0x002, all having the same specified Data payload: 01 02 03 04 05 06 11 12. Savvy CAN receiving (Rx) the data, everytime having byte 1 and 8 increased by value of 0x1 as per the exercise intentional behavior.

• CAN Exercise 4: Three Buttons, Transmits a Message with Three Different Datasets

A program that senses three buttons and, upon pressing each one, sends a message indicating which button was pressed. Interrupts used in this program. Hardware board transmits (Tx) an 8-byte message with ID 0x154, having the default Data payload: 00 00 00 00 00 00 00 00 that then will have the last byte changed to 01, 02 or 03 depending on which button is pressed. Savvy CAN receiving (Rx) the data.

• CAN Exercise 5: Three Buttons, Transmits Three Message with Three Different Datasets

Previous program modified (Exercise 4) so that each message is sent with a different CAN-ID. Hardware board transmits (Tx) three 8-byte messages with ID 0x154, ID 0x233 and ID 0x382, having all default Data payload: 00 00 00 00 00 00 00 00 that then will have the last byte changed to 01, 02 or 03 depending on which button is pressed. Savvy CAN receiving (Rx) the data.

• CAN Exercise 7: Three LEDs, Receives Three Message with Three Different Datasets

A program that receives three CAN messages, each with a different CAN-ID, and where the first 2 bytes (for two messages) and 3 bytes (for third message) indicate the time for an LED to blink. Use a separate LED for each message. Hardware board receives (Rx) three 8-byte messages with ID 0x154, ID 0x233 and ID 0x382, having all default Data payload except for the first 2 to 3 bytes that change to an specific value that represents the time in ms for the LEDs to toggle. Savvy CAN transmits (Tx) the data, with each message configured in the Frame Sender window.

https://github.com/user-attachments/assets/0d01ac11-7a19-4fc8-977a-b5de0ad759e0

CAN Interface (CANIF) Driver Evidences

Back to Sample Evidences

• CANIF Example 1: Transmission single PDU

Hardware board transmits (Tx) an 8-byte single message with ID 0x123 and specified Data payload: 01 02 03 04 05 06 11 12. Savvy CAN receiving (Rx) the data, everytime having byte 1 and 8 increased by value of 0x1 as per the example intentional behavior.

• CANIF Example 2: Two PDUTx, one single HOH

Hardware board transmits (Tx) two 8-byte messages with ID 0x123 and 0x124, all having the same specified Data payload: 01 02 03 04 05 06 11 12. Savvy CAN receiving (Rx) the data, everytime having byte 1 and 8 increased by value of 0x1 as per the example intentional behavior.

• CANIF Example 3: Two PDUTx, Two HOH, Two Notifications

Hardware board transmits (Tx) two 8-byte messages with ID 0x123 and 0x124, all having the same specified Data payload: 01 02 03 04 05 06 11 12. Each message has its own interrupt callback function to indicate that the message was transmitted. Savvy CAN receiving (Rx) the data, everytime having byte 1 and 8 increased by value of 0x1 as per the example intentional behavior.

• CANIF Example 4: Reception single PDU, single Hrh, ID 0x1EF

Hardware board receives (Rx) every second an 8-byte single message with ID 0x1EF and specified Data payload: 32 00 00 00 01 02 03 04. Savvy CAN transmits (Tx) the data. Notice how in code we can establish a condition, in this case where the first byte must be 0x32 and once that is confirmed, can proceed and receive the rest of the data.

• CANIF Example 4: Reception single PDU, single Hrh, ID 0x010

Hardware board receives (Rx) every second an 8-byte single message with ID 0x010 and specified Data payload: 32 08 07 06 05 04 03 02. Savvy CAN transmits (Tx) the data. Notice how in code we can establish a condition, in this case where the first byte must be 0x32 and once that is confirmed, can proceed and receive the rest of the data.

• CANIF Exercise 3: Button Transmits Messages

Same exercise and output as CAN Exercise 3: Button Transmits Messages but this time configured and implemented using CAN Interface module from the Communication Hardware Abstraction layer.

• CANIF Exercise 4: Three Buttons, Transmits a Message with Three Different Datasets

Same exercise and output as CAN Exercise 4: Three Buttons, Transmits a Message with Three Different Datasets but this time configured and implemented using CAN Interface module from the Communication Hardware Abstraction layer.

• [CANIF Exercise 5: Three Buttons, Transmits Three Message with Three Different Datasets](https://github.com/renatosoriano/AUTOSAR-MCAL-Embedded-Ups

README 内容过长，已截取前 64 KB。完整内容请前往 GitHub 仓库查看。