Why to learn about SAR ADC? SAR ADC is a standard AUTOSAR opts for. That’s why you see most of the automotive microcontrollers can be observed having SAR ADC and SAR stands for Successive Approximation Register. You can see the below picture which I extracted for verification of this fact. Microcontrollers which are verified: NXP S32K1xx Series NXP MPC5xxx Series STMicroelectronics SPC5 Series Renesas RH850 Series Infineon AURIX TC3xx Series Microchip PIC32 Series Why AUTOSAR likes SAR ADC over others? SAR ADC working is most suitable due to three major factors mentioned below: High Conversion Speed with Accuracy: SAR ADCs are fast to handle conversion like real-time sensor data conversion while holding its precision as it is. This conversion can be like throttle control, battery management, and other critical functions. Power Efficiency: Power consumption is one of the most important factors in any automotive application especially electric vehicles. SAR ADC consumes comparatively less power rather than ADC like FLASH ADC.  Scalability: SAR ADCs offer a trade-off between speed, resolution, and area, which is crucial in automotive designs where space and performance both matter. Comparing SAR ADC with Flash and Sigma-Delta ADC Flash ADC: The fastest type of ADC, converting signals in just one clock cycle. This speed comes at the cost of power consumption and size, as it requires one comparator per bit of resolution. Given the complex needs of automotive systems, this increased power draw and large footprint make Flash ADCs impractical for most real-time automotive control systems. Sigma-Delta ADC: Offers exceptional accuracy by oversampling the input signal and using noise-shaping techniques. However, its conversion speed is much slower compared to SAR ADCs. This makes it unsuitable for fast, real-time sensor data processing, though it shines in applications where high precision is needed, such as audio or pressure measurement. SAR ADC stands between these two, offering sufficient speed, accuracy, and power efficiency. This balance makes it the top choice for most automotive microcontroller designs, especially in safety-critical applications like engine control, where both speed and accuracy matter. How SAR ADC Works Sample & Hold (S/H) Block: This block holds the analog input signal steady while the ADC performs the conversion. The process begins by capturing the input voltage and freezing it momentarily to allow precise comparisons during the conversion. Comparator: The comparator checks the DAC’s output against the input signal at every stage of the conversion. It decides whether the next bit in the SAR register should be a ‘1’ or a ‘0’ based on whether the input signal is greater or lesser than the DAC output. SAR Register: This is a shift register that stores the output bit by bit as the conversion proceeds. The SAR register’s value evolves with each step of the approximation process, eventually containing the final digital equivalent of the input analog signal. DAC (Digital-to-Analog Converter): The DAC generates a voltage based on the digital bits already stored in the SAR register. The comparator then compares this DAC output with the input signal. The DAC’s resolution is crucial since it must match the resolution of the SAR ADC. Step-by-Step Example: How SAR ADC Calculates an Input Signal Example Setup: Reference Voltage (Vref): 5V Resolution: 4 bits (for simplicity) Input Voltage (Vin): 2.6V Author: Rohan Singhal

Author: Kunal Gupta

Author: Kunal Gupta

API name: Adc_Init() void Adc_Init (const Adc_ConfigType* ConfigPtr) Role: Adc_Init() API initializes the ADC peripheral of the microcontroller. This API is universal and used across all automotive MCUs for initializing the ADC peripheral of the corresponding MCU. This API initializes the registers of ADC peripherals internally. So function definition of Adc_Init () would be different for different SoCs. But in applications across all automotive MCUs, this API name and syntax would be used to initialize the ADC peripheral according to the Adc_ConfigType structure. Working of this API:  This API calls the low-level functions that configure the ADC clock, prescaler, and trigger mode. This API initializes all the ADC instances, according to their configurations for ADC Hardware Unit. This API does not configure the pins of the MCU to analog pins. That part has to be done by the Port or MCU driver. Parameter passed: The parameter that is passed to this API is of Adc_ConfigType data type. Adc_ConfigType is a structure that contains the set of configuration parameters for initializing the ADC Driver and ADC HW units. The object of this data type is generated and defined by the configurator tool. We users don’t have to initialize this object. It is automatically configured based on the configuration we do on the GUI. We just have to send the object of Adc_ConfigType with ampersand (&) to this API. Chronology to use this API: This API is used in the beginning of main(). Just after the system clock and ADC pins are configured by their respective APIs. Return value: This function does not return anything. As it only initializes the internal peripheral registers. But just to check and verify the function, you can observe the changes in ADC HW unit registers just after executing this function. Syntax to use this API:  Adc_Init(&Adc_Config_VS_0); ADC Peripheral Registers affected by This API, with respect to S32K144 MCU using ElecronicsV3 Board:           API Name: Adc_EnableGroupNotification void Adc_EnableGroupNotification(Adc_GroupType Group) Role: This API, enables the notification feature when conversion of all channels of the ADC group is successfully converted.  Working of this API: After starting the ADC conversion either by software trigger or hardware trigger, the group notification function will be called only if its group notification is enabled. And that thing is done by this API. That’s why, in this API we just send one parameter, Group Number.  The ADC Group Notification callback function is called from the IRQ handler of ADC. ADC MCAL layer has a defined IRQ notification callback function, that is called when the IRQ handler of ADC is invoked upon successful conversion of ADC channels. And IRQ Notification callback function calls the group-specific notification callback and updates the Group Status to ADC Completed/ADC Stream Completed. For a single ADC hardware unit in a microcontroller, ADC IRQ is the same for all channels. So upon successful conversion of ADC of a channel IRQ handler notification is called, into which analysis is done that which channel of which group is completed and corresponding to that group notification callback is invoked. Parameter passed: The parameter that is passed to this API is of Adc_GroupType data type. Adc_GroupType is a typedef of uint16. It is just a numeric ID ( 1,2,3,4 etc), denoting the ADC group number. The values of Group IDs are generated and initialized by the code configurator tool. We users don’t have to initialize the group ID number. The group IDs are automatically macro-defined based on the GUI configuration tool. We just have to send the macro-defined group name in this API. Prerequisite: ADC should be used with Interrupts capability. If no interrupts are used, no notification capability will be invoked. The ADC Notification capability checkbox has to be checked in the AdcGeneral section of the ADC configurator tool. If this is not checked, the notification capability will not work. Make sure that we have configured the ADC Group Notification function in the configurator tool while configuring the ADC groups. // photo The name that would be written over here, the function of that name only will be created in generated files and we can define the function in the application code on how to use it and what to do. Chronology: This API is used just after the Adc_init () and before calling the application loop that involves the use of ADC conversion. Return value: This function does not return anything. As it only initializes the internal state to enable the notifications. Syntax to use this API: Adc_EnableGroupNotification(AdcGroup_0); API Name: Adc_StartGroupConversion() void Adc_StartGroupConversion(Adc_GroupType Group) Role: This API initializes the conversion of channels of the group which is triggered by software. This API starts the conversion of the ADC group which is configured to get triggered via a Software Trigger. Hardware Trigger ADC groups are not started via this API. After the usage of this API, the ADC conversion of channels that are referred by a single group would begin, and we can expect corresponding group notifications to be called. And to see the results of ADC conversion we can use the Adc_ReadGroup(). Working: This API initializes the internal ADC peripheral register of ADC channels of the group which has to be converted. It also writes on those peripheral registers which starts the ADC conversion by Software trigger. Parameters: The parameter that is passed to this API is of Adc_GroupType data type. Adc_GroupType is a typedef of uint16. It is just a numeric ID ( 1,2,3,4 etc), denoting the ADC group number. The values of Group IDs are generated and initialized by the configurator tool. We users don’t have to initialize the group ID number. The group IDs are automatically macro-defined based on the GUI configuration tool. We just have to send the macro-defined group name in this API. Prerequisite: The ADC module should be initialized with Adc_Init() API and ADC notifications of the group should be enabled. Syntax to this API: Adc_StartGroupConversion(AdcGroup_0); API Name: Adc_EnableHardwareTrigger() void Adc_EnableHardwareTrigger(Adc_GroupType Group) Role: This API initializes the conversion of channels of the group

What is BootLoader(BL)? The bootloader is a small chunk of code that gets executed when the MCU powers on or resets. Its main function is to manage the initial startup process, including any necessary checks or updates before the main application code runs. How BootLoader(BL) is different from Application Software? Application Software is the function-specific code that you program to perform an MCU-based task(like controlling the motor, displaying information, etc,). But you must be thinking or saying, that your application software also behaves pretty same as bootloader cause everytime you start/reset MCU, it will restart your application code from the beginning, right? But there’s a quite crisp gap between this BootLoader and Application Software which can broaden your understanding of bootloader and application software. Let’s divide this crisp gap into 3 sub-domains: Memory Allocation: If I talk about memory occupied by BL and Application Software. The first thing would be where are these two located and in which memory, answering that, BL is located at the beginning of FLASH memory and it always has some reserved space only which is also write-protected(Thinking why write-protected because to prevent accidental overwriting during normal operation) whereas application software is also stored in FLASH memory only but it’s below the space allocated to BL. Execution Flow: Upon power-on or reset, the microcontroller’s program counter starts executing code from the beginning of the flash memory, where the bootloader is located. After the bootloader completes its tasks (like, checking for updates, and validating the application), it will typically jump to the application’s start address (which is known and fixed in the bootloader code) to begin executing the application. Update Process: A well-developed bootloader can help you even in handling firmware updates. It can receive new application code, erase the old code, and write the new code to memory. The application cannot typically update itself. It relies on the bootloader to manage this process. The application’s major focus is on running the device’s features and does not deal with the update or integrity checks. Let’s understand with a analogy Taking an analogy with our expertise field of automotive embedded systems. Considering ourselves as an OEM, we have been reported a problem. A software bug is discovered in the ECU that controls the braking system. This bug causes the braking system to occasionally misbehave under specific conditions, such as when the vehicle is driving downhill. Diagnosing this issue requires an early solution because the bug needs to be fixed quickly to ensure the safety of the vehicles on the road. During the update of this bug fixing, the vehicle’s battery drains, and the update process is interrupted: With a Bootloader: When power is restored, the bootloader detects that the application firmware is corrupted or incomplete. It can either retry the update automatically or revert to a backup firmware version, ensuring the vehicle remains operational and can be updated again. I agree in this condition driving is not safe, but at least the car can operate so that it can be driven to repair with full caution. Without a Bootloader: The ECU might attempt to boot the corrupted application, resulting in a system crash or malfunction. The vehicle may not start or may exhibit erratic behavior, requiring a technician to manually intervene and repair the ECU, which could be time-consuming and costly. EDIT: Just found another real-life example. As we all know windows push too much of FOTA(Firmware Over-The-Air), out of which some take too much time to restart and some get applied with restart. Now you must have seen this screen will update. This “DON’T TURN OFF YOUR COMPUTER” message is also displayed for the very same reason, how power disruption can lead to the bricking of your laptop. But you must be curious what exactly what will happen if I cut off the power supply, and power up the device again, right? As a bootloader function, this interruption will be acknowledged and the bootloader will roll back to the previous functional update. You might see below mention image on start-up. IMPORTANT: Avoid trying this at home, this maneuver costs us to retrieve the data but unfortunately all core OS files and applications were corrupted and no longer responded for usage, we tried some troubleshooting using the window troubleshooter, but it wasn’t effective. At last, we installed a completely fresh OS from scratch.  I would expect that you have completely understand the “WHY” and “WHAT” of BootLoader. Now, it’s time to understand the “HOW” of bootloader. Important Terminology in BootLoader Memory Management Memory management is quite an interesting concept that can also help in relating to real-world applications. As we understand the chronology of the working of a bootloader, which is firstly a bootloader will get which now will be followed by application software. Now basically there can be different executions of application software, let’s brief all possible ways: Executing Directly from Flash Memory: This specific condition is noticed in most of the embedded MCUs where the bootloader and application software are placed in FLASH memory only. Flash memory is non-volatile, meaning it retains data even when the power is off.  Copying to RAM Before Execution: In some cases, the application code might be copied from flash memory to RAM before execution. This approach is more common in systems where high performance is required or where the flash memory is slower than RAM. The major reason behind using RAM for execution, RAM is typically faster than flash memory. Overlaying: In systems with limited RAM, overlaying is a technique where only a portion of the program is loaded into RAM at any given time, with different parts of the program being loaded and unloaded as needed.  Virtual Memory Techniques: This specific technique is very common nowadays you must see that recent smartphones have this feature called RAM EXTENSION, where a portion of storage is accumulated to RAM for its R/W access. Parts of the application can be swapped in and out of physical RAM as needed. Such strategies