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.
- Description
- Hardware Requirements
- Software Requirements
- Notes
- Documentation
- Examples and Exercises
- Final Project
- Sample Evidences
<-- 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:
- Introduction to AUTOSAR MCAL and EB Tresos.
- PORT driver.
- DIO driver.
- MCU driver.
- GPT Driver.
- Platform Driver.
- ADC driver.
- PWM driver.
- SPI driver.
- I/O Hardware Abstraction.
- CAN driver.
- CANIF driver.
- Final Project.
What it's covered from the Classic AUTOSAR layers perspective:
<-- 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:
<-- 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.
<-- 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.
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. These files after generated were modified to be portable (using $(ProjectDir)), hence no need to be modified again and are ready to be executed.
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/DIO_Example4_Reading_channel", "$(ProjectDir)");
Project.AddPathSubstitute ("c:/eb/tresos/workspace/dio_example4_reading_channel", "$(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/DIO_Example4_Reading_channel/S32K144.svd");
Project.AddSvdFile ("$(ProjectDir)/S32K144.svd");
//
// User settings
//
File.Open ("$(ProjectDir)/Build/temp.elf");
}<-- Back to Table of Contents
You can find here Documentation all reference documents regarding:
- AUTOSAR MCAL drivers.
- Compiler Manuals.
- NXP S32K144 Board.
- Modular S-1 Board.
- SEGGER Tools.
<-- 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.
- Templates: Tresos Project and Ozone Semihosting RTT.
- DIO and PORT driver.
- MCU driver.
- GPT Driver.
- Platform Driver.
- ADC driver.
- PWM driver.
- SPI driver.
- I/O Hardware Abstraction.
- CAN driver.
- CANIF driver.
<-- 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 2 Events:
Button 3 Events:
Back to Final Project
- Shall toggle ON/OFF RGB_LED_BLUE (D0) and C10_LED2 (as SINGLE_CLICK visual indicator).
Button_1_Single_click.mp4
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).
Button_1_Double_click.mp4
Back to Final Project
- Buzzer shall start to beep and play Tone 1, then stop.
Button_1_Hold_Release.mp4
Back to Final Project
- Shall toggle ON/OFF RGB_LED_RED (D15) and C9_LED1 (as SINGLE_CLICK visual indicator).
Button_2_Single_click.mp4
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).
Button_2_Double_click.mp4
Back to Final Project
- Buzzer shall start to beep and play Tone 2, then stop.
Button_2_Hold_Release.mp4
Back to Final Project
- Shall toggle ON/OFF RGB_LED_GREEN (D16) and C8_LED0 (as SINGLE_CLICK visual indicator).
Button_3_Single_click.mp4
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).
Button_3_Double_click.mp4
Back to Final Project
- Buzzer shall start to beep and play Tone 3, then stop.
Button_3_Hold_Release.mp4
<-- 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.
Back to Sample Evidences
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.
DIO_Exercise8_Rotate_LEDs_Left_Right_Buttons.mp4
Back to Sample Evidences
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.
GPT_Exercise1_2Timers_OneShot_FIRC_2LEDs.mp4
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).
GPT_Exercise3_3Timers_FTM_RGB_DiffClkRef.mp4
Back to Sample Evidences
Vary the rotation speed of eight LEDs C8 to C15 using one of the potentiometers on the board.
ADC_Exercise1_Rotate_Speed_8LEDs_Potentiometer.mp4
Display the values of the two potentiometers in Ohms and Volts.
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:
Back to Sample Evidences
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.
Generate two complement PWM signal with dead time insertion of around 1% of the period of the signal.
PWM_Exercise2_2CH_Complementary_DeadTime_Insertion.mp4
'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:
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.
PWM_Exercise4_ADC_Pot_DutyCycle_RGB_LED.mp4
Back to Sample Evidences
Read and display the first 32 bytes of an Eeprom in different formats using Semihosting with RTT.
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 );
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 );
Back to Sample Evidences
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.
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.
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.
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.
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.
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.
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.
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.
Back to Sample Evidences
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.
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.
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.
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.
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.
