Table of Contents
About STMicroelectronics
STMicroelectronics is a leading provider of semiconductor solutions that are seamlessly integrated into billions of electronic devices used by people worldwide on a daily basis.
The semiconductor company builds products, solutions, and ecosystems that enable smarter mobility, more efficient power and energy management, and the wide-scale deployment of the Internet of Things and connectivity technologies. To know more about STMicroelectronics refer to its website: www.st.com.
Going back in history, ST was formed in 1987 by the merger of two government-owned semiconductor companies: Italian SGS Microelettronica (where SGS stands for Società Generale Semiconduttori, “Semiconductors’ General Company”), and French Thomson Semiconductors, the semiconductor arm of Thomson.
In this blog, we are going to start with ST IoT-based Nucleo Board STm32WB55.
What is STM32WB Series all about?
The STM32WB55xx and STM32WB35xx are advanced multiprotocol wireless devices that boast ultra-low-power consumption. These devices are equipped with a powerful and efficient radio that is compliant with the Bluetooth® Low Energy SIG specification 5 and IEEE 802.15.4-2011 (Zigbee). Additionally, they feature a dedicated Arm® Cortex®-M0+ processor that handles all real-time low-layer operations.
These cutting-edge devices are perfect for a wide range of applications that require reliable and efficient wireless communication. Whether you’re working on a smart home project, a wearable device, or an industrial automation system, the STM32WB55xx and STM32WB35xx are the ideal choices.
With their advanced features and capabilities, these devices are sure to revolutionize the way we think about wireless communication. So why wait? Start exploring the possibilities today and discover what the STM32WB55xx and STM32WB35xx can do for you!
The devices have been meticulously crafted to operate on minimal power and are built around the high-performance Arm® Cortex®-M4 32-bit RISC core, which can operate at a frequency of up to 64 MHz. This core boasts a Floating-point unit (FPU) single precision that supports all Arm® single-precision data-processing instructions and data types. Additionally, it is equipped with a full set of DSP instructions and a memory protection unit (MPU) that enhances application security.
These devices have been designed with the utmost care and attention to detail, ensuring that they are not only efficient but also highly effective. The Arm® Cortex®-M4 32-bit RISC core is a powerful tool that enables these devices to perform at an exceptional level, while the FPU single precision and DSP instructions provide unparalleled accuracy and precision. Furthermore, the memory protection unit (MPU) ensures that your applications are secure and protected from any potential threats.
Enhanced inter-processor communication is provided by the IPCC with six bidirectional channels. The HSEM provides hardware semaphores used to share common resources between the two processors.
The devices embed high-speed memories (up to 1 Mbyte of flash memory for STM32WB55xx, up to 512 Kbytes for STM32WB35xx, up to 256 Kbytes of SRAM for STM32WB55xx, 96 Kbytes for STM32WB35xx), a Quad-SPI flash memory interface (available on all packages) and an extensive range of enhanced I/Os and peripherals. 
About STM32WB55
Architecture
The host application is housed on an Arm® Cortex®-M4 CPU (named CPU1) that connects with a generic microcontroller subsystem.
The RF subsystem is made up of a specialized Arm® Cortex®-M0+ microprocessor (named CPU2), Bluetooth Low Energy and 802.15.4 digital MAC blocks, an RF analog front end, and proprietary peripherals. All Bluetooth Low Energy and 802.15.4 low-layer stack functions are handled by the RF subsystem, which limits communication with the CPU1 to high-level exchanges.
Some functions are shared between the RF subsystem CPU (CPU2) and the Host CPU (CPU1):
- Flash memories
- SRAM1, SRAM2a, and SRAM2b (SRAM2a can be retained in Standby mode)
- Security peripherals (RNG, AES1, PKA)
- Clock RCC
- Power control (PWR)
Memories
2.1. Adaptive real-time memory accelerator (ART Accelerator)
The ART Accelerator is a memory accelerator optimized for STM32 industry-standard Arm® Cortex®-M4 processors. It balances the inherent performance advantage of the Arm® Cortex®-M4 over flash memory technologies.
To release the processor near 80 DMIPS performance at 64 MHz, the accelerator implements an instruction prefetch queue and branch cache, which increases program execution speed from the 64-bit flash memory. Based on CoreMark benchmark, the performance achieved thanks to the ART accelerator is equivalent to 0 wait state program execution from flash memory at a CPU frequency up to 64 MHz.
2.2. Memory protection unit
In order to prevent one task from unintentionally corrupting the memory or resources used by any other active task, the memory protection unit (MPU) is used to manage the CPU1’s accesses to memory. This memory area is organized into up to eight protected areas.
The MPU is especially helpful for applications where some critical or certified code must be protected against the misbehavior of other tasks. It is usually managed by an RTOS (real-time operating system).
2.3. Embedded flash memory
The STM32WB55xx and STM32WB35xx devices feature, respectively, up to 1 Mbyte and 512 Kbytes of embedded flash memory available for storing programs and data, as well as some customer keys.
2.4. Embedded SRAM
The STM32WB55xx devices feature up to 256 Kbytes of embedded SRAM, split in three blocks:
- SRAM1: up to 192 Kbytes mapped at address 0x2000 0000
- SRAM2a: 32 Kbytes located at address 0x2003 0000 also mirrored at 0x1000 0000, with hardware parity check (this SRAM can be retained in Standby mode)
- SRAM2b: 32 Kbytes located at address 0x2003 8000 (contiguous with SRAM2a) and mirrored at 0x1000 8000 with hardware parity check.
Security and Safety
The STM32WB55xx contain many security blocks both for the Bluetooth Low Energy or IEEE 802.15.4 and the Host application. It includes:
- Customer storage of the Bluetooth Low Energy and 802.15.4 keys
- Secure flash memory partition for RF subsystem-only access
- Secure SRAM partition, that can be accessed only by the RF subsystem
- True random number generator (RNG)
- Advance encryption standard hardware accelerators (AES-128bit and AES-256bit, supporting chaining modes ECB, CBC, CTR, GCM, GMAC, CCM)
- Private key acceleration (PKA)
- Cyclic redundancy check calculation unit (CRC)
True random number generator (RNG)
The devices embed a true RNG that delivers 32-bit random numbers generated by an integrated analog circuit.
RF Subsystem
The STM32WB55xx embeds an ultra-low power multi-standard radio Bluetooth Low Energy and 802.15.4 network processor, compliant with Bluetooth specification 5.3 and IEEE® 802.15.4-2011. The Bluetooth Low Energy features 1 Mbps and 2 Mbps transfer rates, supports multiple roles simultaneously acting at the same time as Bluetooth Low Energy sensor and hub device.
The Bluetooth Low Energy stack and 802.15.4 Low Level layer run on an embedded Arm® Cortex®-M0+ core (CPU2). The stack is stored on the embedded flash memory, which is also shared with the Arm® Cortex®-M4 (CPU1) application, making it possible in-field stack update.
4.1. RF Front-End Block Diagram
The RF front-end is based on a direct modulation of the carrier in Tx, and uses a low IF architecture in Rx mode. Thanks to an internal transformer at RF pins, the circuit directly interfaces the antenna (single ended connection, impedance close to 50 Ω).
In Transmit mode, the maximum output power is user selectable through the programmable LDO voltage of the power amplifier. A linearized, smoothed analog control offers clean power ramp-up.
In Receiving mode the circuit can be used in standard high performance or in reduced power consumption (user programmable). The Automatic gain control (AGC) is able to reduce the chain gain at both RF and IF locations, for optimized interference rejection.
4.2. BLE Description
It integrates a 2.4 GHz RF transceiver and a powerful Cortex®-M0+ core, on which a complete power-optimized stack for Bluetooth Low Energy protocol runs, providing master / slave role support
- GAP: central, peripheral, observer or broadcaster roles
- ATT/GATT: client and server
- SM: privacy, authentication and authorization
- L2CAP
- Link layer: AES-128 encryption and decryption
In addition, according to Bluetooth specification 5.3, the Bluetooth Low Energy block provides:
- Multiple roles simultaneous support
- Master/slave and multiple roles simultaneously
- LE data packet length extension (making it possible to reach 800 kbps at application level)
- LE privacy 1.2
- LE secure connections
- Flexible Internet connectivity options
- High data rate (2 Mbps)
The device also supports Piconet and Scatternet.
Ultra-low-power sleep modes and very short transition time between operating modes result in very low average current consumption.
4.3. Zigbee (802.15.4) Description
The STM32WB55xx embeds a dedicated 802.15.4 hardware MAC:
- Support for 802.15.4 release 2011
- Advanced MAC frame filtering; hardwired firewall: Programmable filters based on source/destination addresses, frame version, security enabled, frame type
- 256-byte RX FIFO; Up to 8 frames capacity, additional frame information (timing, mean RSSI, LQI)
- 128-byte TX FIFO with retention
- Automatic frame acknowledgment, with programmable delay
- Advanced channel access features
- Configuration registers with retention available down to Standby mode for software/auto-restore
- Autonomous sniffer, wake-up based on timer or CPU2 request
- Automatic frame transmission/reception/sleep periods, Interrupt to the CPU2 on particular events
Low Power Modes
- Sleep
In Sleep mode, only the CPU1 is stopped. All peripherals, including the RF subsystem, continue to operate and can wake up the CPU when an interrupt/event occurs.
- Low-power run
This mode is achieved with VCORE supplied by the low-power regulator to minimize the regulator operating current. The code can be executed from SRAM or from the flash memory, and the CPU1 frequency is limited to 2 MHz. The peripherals with independent clock can be clocked by HSI16. The RF subsystem is not available in this mode and must be OFF.
- Low-power sleep
This mode is entered from the low-power run mode. Only the CPU1 clock is stopped. When wake-up is triggered by an event or an interrupt, the system reverts to the low-power run mode. The RF subsystem is not available in this mode and must be OFF.
- Stop 0, Stop 1 and Stop 2
Stop modes achieve the lowest power consumption while retaining the content of all the SRAM and registers. The LSE (or LSI) is still running. The RTC can remain active (Stop mode with RTC, Stop mode without RTC). Some peripherals with wake-up capability can enable the HSI16 RC during Stop modes to detect their wake-up condition. Three modes are available: Stop 0, Stop 1 and Stop 2.
In Stop 2 mode, most of the VCORE domain is put in a lower leakage mode.
Stop 1 offers the largest number of active peripherals and wake-up sources, a smaller wake-up time but a higher consumption than Stop 2.
In Stop 0 mode the main regulator remains ON, allowing a very fast wake-up time but with higher consumption. In these modes the RF subsystem can wait for incoming events in all Stop modes. The system clock when exiting from Stop 0, Stop1 or Stop2 modes can be either MSI up to 48 MHz or HSI16 if the RF subsystem is disabled.
- Standby
The Standby mode is used to achieve the lowest power consumption with BOR. The internal regulator is switched off so that the VCORE domain is powered off. The RTC can remain active (Standby mode with RTC).
After entering Standby mode, SRAM1, SRAM2b and register contents are lost except for registers in the Backup domain and Standby circuitry. Optionally, SRAM2a can be retained in Standby mode, supplied by the low-power regulator (Standby with 32 KB SRAM2a retention mode).
The system clock after wake-up is 16 MHz, derived from the HSI16. If used, the SMPS is restarted automatically. In this mode the RF can be used.
- Shutdown
This mode achieves the lowest power consumption. The internal regulator is switched off so that the VCORE domain is powered off. The RTC can remain active (Shutdown mode with RTC, Shutdown mode without RTC). The BOR is not available in Shutdown mode. No power voltage monitoring is possible in this mode, therefore the switch to Backup domain is not supported. SRAM1, SRAM2a, SRAM2b and register contents are lost except for registers in the Backup domain.
The system clock after wake-up is 4 MHz, derived from the MSI. In this mode the RF is no longer operational.
Clocks and Startup
The STM32WB55xx device integrate several clock sources:
- LSE: 32.768 kHz external oscillator, for accurate RTC and calibration with other embedded RC oscillators
- LSI1: 32 kHz on-chip low-consumption RC oscillator
- LSI2: almost 32 kHz, on-chip high-stability RC oscillator, can be used by the RF subsystem instead of LSE
- HSE: high-quality 32 MHz external oscillator with trimming, needed by the RF subsystem
- HSI16: 16 MHz high accuracy on-chip RC oscillator
- MSI: 100 kHz to 48 MHz multiple speed on-chip low power oscillator, can be trimmed using the LSE signal
- HSI48: 48 MHz on-chip RC oscillator, for USB crystal-less purpose.
STM32 WB55 has Clock Controller, which has following features:
- Clock prescaler: to get the best trade-off between speed and current consumption, the clock frequency to the CPU and peripherals can be adjusted by a programmable prescaler • Safe clock switching: clock sources can be changed safely on the fly in run mode through a configuration register.
- Clock management: to reduce power consumption, the clock controller can stop the clock to the core, individual peripherals or memory.
- System clock source: four different clock sources can be used to drive the master clock SYSCLK.
- Auxiliary clock source: two ultralow-power clock sources that can be used to drive the LCD controller and the real-time clock.
- Peripheral clock sources: Several peripherals (RNG, SAI, USARTs, I2Cs, LPTimers, ADC) have their own independent clock whatever the system clock. Two PLLs, each having three independent outputs for the highest flexibility, can generate independent clocks for the ADC, the RNG and the SAI.
- Startup clock: after reset, the microcontroller restarts by default with an internal 4 MHz clock (MSI). The prescaler ratio and clock source can be changed by the application program as soon as the code execution starts.
- Clock security system (CSS): this feature can be enabled by software. If an HSE clock failure occurs, the master clock is automatically switched to HSI16 and a software interrupt is generated if enabled. LSE failure can also be detected and an interrupt generated.
GPIO
Each of the GPIO pins can be configured by software as output (push-pull or open-drain), as input (with or without pull-up or pull-down) or as peripheral alternate function. Most of the GPIO pins are shared with digital or analog alternate functions. Fast I/O toggling can be achieved thanks to their mapping on the AHB2 bus.
DMA
Direct memory access (DMA) is used to provide high-speed data transfer between peripherals and memory as well as between memories. Data can be quickly moved by DMA without any CPU action. This keeps CPU resources free for other operations.
Here the two DMA embeds inside the controllers have fourteen channels in total, a full cross matrix allows any peripheral to be mapped on any of the available DMA channels. Each DMA has an arbiter for handling the priority between DMA requests.
Interrupts and Events
9.1. NVIC (Nested Vectored Interrupt Controller)
The devices embed a nested vectored interrupt controller able to manage 16 priority levels, and handle up to 63 maskable interrupt channels plus the 16 interrupt lines of the Cortex®-M4 with FPU.
The NVIC benefits are the following:
- Closely coupled NVIC gives low latency interrupt processing
- Interrupt entry vector table address passed directly to the core
- Allows early processing of interrupts
- Processing of late arriving higher priority interrupts
- Support for tail chaining
- Processor state automatically saved
- Interrupt entry restored on interrupt exit with no instruction overhead
9.2. Extended Interrupts and Events Controller (EXTI)
The EXTI manages wake-up through configurable and direct event inputs. It provides wake-up requests to the Power control, and generates interrupt requests to the CPUx NVIC and events to the CPUx event input.
ADC
The device embeds a successive approximation analog-to-digital converter with the following features:
- 12-bit native resolution, with built-in calibration.
- Up to 16-bit resolution with 256 oversampling ratio.
- 4.26 Msps maximum conversion rate with full resolution .
- Up to sixteen external channels and three internal channels: internal reference voltages, temperature sensor • Single-ended and differential mode inputs.
- Low-power design .
- Highly versatile digital interface.
Comparators (COMP)
The STM32WB55xx device embeds two rail-to-rail comparators with programmable reference voltage (internal or external), hysteresis, and speed (low-speed for low power) and with selectable output polarity.
The reference voltage can be one of the following:
- External I/O .
- Internal reference voltage or submultiple (1/4, 1/2, 3/4).
Touch Sensing Controller
The touch sensing controller provides a simple solution for adding capacitive sensing functionality to any application. Capacitive sensing technology is able to detect finger presence near an electrode which is protected from direct touch by a dielectric such as glass or plastic.
The main features of the touch sensing controller are the following:
- Robust surface charge transfer acquisition principle
- Supports up to 18 capacitive sensing channels
- Up to six capacitive sensing channels can be acquired in parallel offering a very good response time.
- Spread spectrum feature to improve system robustness in noisy environments.
- Full hardware management of the charge transfer acquisition sequence
- Programmable charge transfer frequency
- Programmable sampling capacitor I/O pin
- Programmable channel I/O pin.
- Programmable max count value to avoid long acquisition when a channel is faulty.
- Dedicated end of acquisition and max count error flags with interrupt capability .
- One sampling capacitor for up to three capacitive sensing channels to reduce the system components.
- Compatible with proximity, touch key, linear and rotary touch sensor implementation.
Liquid crystal display controller (LCD)
The STM32WB55xx devices embed an LCD controller with the following characteristics:
- Highly flexible frame rate control.
- Supports Static, 1/2, 1/3, 1/4 and 1/8 duty.
- Supports Static, 1/2, 1/3 and 1/4 bias.
- Double-buffered memory allows data in LCD_RAM registers to be updated at any time by the application firmware without affecting the integrity of the data displayed.
- Software selectable LCD output voltage (contrast) from VLCDmin to VLCDmax.
- No need for external analog components.
- The contrast can be adjusted using two different methods.
- Full support of low-power modes: the LCD controller can be displayed in Sleep, Low-power run, Low-power sleep and Stop modes, or can be fully disabled to reduce power consumption.
- Built in phase inversion for reduced power consumption and EMI (electromagnetic interference).
- Start of frame interrupt to synchronize the software when updating the LCD data RAM. • Blink capability.
Timers and watchdogs
The STM32WB55xx includes one advanced 16-bit timer, one general purpose 32-bit timer, two 16-bit basic timers, two low-power timers, two watchdog timers and a SysTick timer.
Real-time clock (RTC) and backup registers
The RTC is an independent BCD timer/counter, supporting the following features:
- Calendar with subsecond, seconds, minutes, hours (12 or 24 format), week day, date, month, year, in BCD (binary-coded decimal) format.
- Automatic correction for 28, 29 (leap year), 30, and 31 days of the month.
- Two programmable alarms.
- On-the-fly correction from 1 to 32767 RTC clock pulses. This can be used to synchronize it with a master clock.
- Reference clock detection: a more precise second source clock (50 or 60 Hz) can be used to enhance the calendar precision.
- Digital calibration circuit with 0.95 ppm resolution, to compensate for quartz crystal inaccuracy.
- Three anti-tamper detection pins with programmable filter.
- Timestamp feature, which can be used to save the calendar content. This function can be triggered by an event on the timestamp pin, or by a tamper event, or by a switch to VBAT mode.
- 17-bit auto-reload wake-up timer (WUT) for periodic events with programmable resolution and period.
The backup registers are 32-bit registers used to store 80 bytes of user application data when VDD power is not present. They are not reset by a system or power reset, or when the device wakes up from Standby or Shutdown mode.
Inter Integrated Circuit (I2C)
The I2C bus interface handles communications between the microcontroller and the serial I2C bus. It controls all I2C bus-specific sequencing, protocol, arbitration and timing.
The device has 2 I2C peripherals which supports:
- Slave and master modes, multimaster capability
- Standard-mode (Sm), with a bitrate up to 100 kbit/s
- Fast-mode (Fm), with a bitrate up to 400 kbit/s .
- Fast-mode Plus (Fm+), with a bitrate up to 1 Mbit/s and 20 mA output drive I/Os .
- 7-bit and 10-bit addressing mode, multiple 7-bit slave addresses .
- Programmable setup and hold times .
- Optional clock stretching.
UART
UART
The devices embed one universal synchronous receiver transmitter. and one Low-Power UART.
The USART is able to communicate at speeds of up to 4 Mbit/s.It provides hardware management of the CTS and RTS signals, and RS485 driver enable.
The USART has a clock domain independent from the CPU clock, allowing it to wake up the MCU from Stop mode using baud rates up to 200 kbaud. The wake up events from Stop mode are programmable and can be:
- the start bit detection
- any received data frame
- a specific programmed data frame.
The USART interface can be served by the DMA controller.
LP-UART
The device embeds one Low-Power UART, enabling asynchronous serial communication with minimum power consumption. The LPUART supports half duplex single wire communication and modem operations (CTS/RTS), allowing multiprocessor communication.
The LPUART has a clock domain independent from the CPU clock, and can wake-up the system from Stop mode using baud rates up to 220 kbaud. The wake up events from Stop mode are programmable and can be:
- the start bit detection
- any received data frame
- a specific programmed data frame.
Only a 32.768 kHz clock (LSE) is needed for LPUART communication up to 9600 baud. Therefore, even in Stop mode, the LPUART can wait for an incoming frame while having an extremely low energy consumption. Higher speed clock can be used to reach higher baud rates.
The LPUART interfaces can be served by the DMA controller.
SPI
Two SPI interfaces enable communication up to 32 Mbit/s in master and up to 24 Mbit/s in slave modes, in half-duplex, full-duplex and simplex modes. The 3-bit prescaler gives 8 master mode frequencies and the frame size is configurable from 4 bits to 16 bits. The SPI interfaces support NSS pulse mode, TI mode and Hardware CRC calculation.
The SPI interfaces can be served by the DMA controller.
Serial audio interfaces (SAI)
The device embeds a dual channel SAI peripheral that supports full duplex audio operation. The SAI bus interface handles communications between the microcontroller and the serial audio protocol.
The SAI peripheral supports:
- One independent audio sub-block that can be a transmitter or a receiver, with the respective FIFO
- 8-word integrated FIFOs
- Synchronous or asynchronous mode
- Master or slave configuration
- Clock generator to target independent audio frequency sampling when audio sub-block is configured in master mode
- Data size configurable: 8-, 10-, 16-, 20-, 24-, 32-bit
- Peripheral with large configurability and flexibility allowing to target as example the following audio protocol: I2S, LSB or MSB-justified, PCM/DSP, TDM, AC’97 and SPDIF out
- Up to 16 slots available with configurable size and with the possibility to select which ones are active in the audio frame
- Number of bits by frame may be configurable
- Frame synchronization active level configurable (offset, bit length, level) • First active bit position in the slot is configurable
- LSB first or MSB first for data transfer
- Mute mode
- Stereo/Mono audio frame capability
- Communication clock strobing edge configurable (SCK)
- Error flags with associated interrupts if enabled respectively.
- DMA interface with two dedicated channels to handle access to the dedicated integrated FIFO of the SAI audio sub-block.
QUADSPI
The Quad-SPI is a specialized communication interface targeting single, dual or quad SPI flash memories.
It can operate in any of the three following modes:
- Indirect mode: all the operations are performed using the QUADSPI registers
- Status polling mode: the external memory status register is periodically read and an interrupt can be generated in case of flag setting
- Memory-mapped mode: the external flash memory is mapped and is seen by the system as if it
REFERENCES
Autosar MCAL layer ADC Driver API’s and data types explanation
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
ADC Driver of Autosar MCAL Layer
ADC Driver of Autosar MCAL layer Explanation, Understanding and tutorial using ElecronicsV3 Development board
BootLoader EXPLAINED!
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
PDB Explained
Prerequisites for PDB of ADC What is the PDB? The PDB is a powerful peripheral in microcontroller’s designed to provide controllable delays and trigger events based on specific conditions for ADC peripheral. Those control delays and trigger events allows us to get ADC Data, making it valuable for applications requiring accurate timing or synchronization. // In this elaborate following things: Point to be learned: Q: What do we mean by controllable delays?A: Controllable delays refer to the ability to set specific time intervals in a system to control when certain actions or events occur. It provides you with flexibility, configurable time delay, and precision. Q: What do we mean by trigger event?A: A trigger event is a signal(which can be external or internal) that prompts the system to begin a predefined action or series of actions. Q: What and which specific conditions we mean here?A: Configurable delay can be a counter-based delay, timer-based delay, or PWM-based delay. If we talk about PDB, here we use counter-based delay which involves using a hardware counter that increments or decrements based on a clock source. When the counter reaches this value, an event (such as a trigger or interrupt) is generated. And talking about the trigger event can be also classified into internal or external triggers, it is quite self-explanatory that if a trigger is received from a physical pin of the MCU then it is considered an external trigger and if triggers are initiated inside the MCU then it is called software trigger. Why is This Important? Understanding how to use the PDB effectively can greatly enhance your control over ADC operations. Whether you’re working on a high-precision measurement system, synchronizing multiple ADCs, or simply improving the timing accuracy of your applications, the PDB offers the flexibility and precision you need. How does PDB Peripheral works? ///// In this explain the relation of working of PDB peripheral. Q: How does PDB generate delaysA: As explained before, PDB works on a counter-based delay where we can specify the value of the counter. When the counter reaches this value, it will be reset back to zero. This counter register is labeled as “Modulus register (PDB_MOD)”. Let’s see how you can get a perfect modulus value for your desired requirement. Example: Peripheral(PDB) bus clock is 48MHz(this can also be modified in the clock configuration tool) and before moving to modulus calculation you are always asked to set the value of pre-scalar and multiplication factor(these two can be in Status and Control Register (PDB_SC)). Prescalar value is used to divide the peripheral clock and set your desired value of clock for operation and multiplication factor as it defines its name, it is used for multiplying with prescalar division. Now we are considering the MULT(Multiplication factor) as 40 and PRESCALAR(Prescalar Divider) as 64.PDB Period = ( (System Clock) / (Prescaler x Mult factor) )PDB Period = (48 MHz / (64 x 40)) = 18750HzNow, we have a clock value for PDB and you can create multiple MOD values from this clock. If we need a counter value for 1 second, we just multiply the PBD Period with “n” second.1 second = 18750 x 1 = 18750(MOD value)2 second = 18750 x 2 = 37500(MOD value)3 second = 18750 x 3 = 56250(MOD value)NOTE: The maximum value for MOD is 65536(MOD register is 16-bit register), which means with my current setting I cannot create a 4-second counter value(4 seconds = 18750 x 4 = 75000 > 65536). In this case, you need to reconfigure the values of PRESCALAR and MULT. Q: Explain the concept of channels in PDB peripheralA: In the Programmable Delay Block (PDB) peripheral, the concept of channels is central to its functionality. Each channel in the PDB is a separate entity that can be configured to trigger specific actions after a programmable delay. Each PDB channel is typically associated with a specific Analog-to-Digital Converter (ADC) block. For example, PDB0 will be linked to ADC0, and so on. PDB channels can be enabled or disabled independently. The concept of channels in the PDB provides flexibility in timing and synchronization, essential for applications requiring precise control over ADC conversions. Q: Concept of triggering in PDB by explaining terminologies like trigger event, trigger input, trigger sourceA: The concept of triggering in the Programmable Delay Block (PDB) is essential for coordinating and controlling actions such as ADC conversions. Trigger Input: The trigger input is the physical or logical signal that the PDB monitors to detect a trigger event. This input can come from various sources like pulling a pin up or down, triggering through Bit Manipulation of register, and all.Trigger Event:A trigger event refers to the occurrence of a specific condition or signal that initiates an action within the PDB.Trigger Source:The trigger source defines where the trigger input originates. Just mention the concept of the triggering mechanism of ADC peripheral and how is it achieved through PDB Relation of PDB delays with ADC peripheral How does the PDB peripheral control the ADC peripheral The Programmable Delay Block (PDB) includes a counter that compares its output to various preset digital values. When the PDB is enabled, a trigger input event will reset the counter and start counting. A trigger input event can be a rising edge detected on a chosen external trigger source, or it can be initiated by a software trigger. For each channel, a delay determines the time between the assertion of the trigger input event to the time at which changes in the pretrigger output signal are started. Each channel in the Programmable Delay Block (PDB) is linked to a specific ADC block. These pre-trigger outputs are connected to the ADC’s hardware trigger select. The role of the pre-triggers is to prepare the ADC block before the main trigger signal is applied. When the ADC detects a rising edge on the main trigger input, it starts the conversion process based on the settings and conditions established by the pre-triggers. The pre-trigger outputs are used to specify which signal will
Motor Control
When engineers are faced with the challenge of designing electrical equipment to perform mechanical tasks, they might think about how electrical signals get converted to energy. So actuators and motors are among the devices that convert electrical signals into motion. Motors exchange electrical energy to mechanical energy. To understand Motor terminologies Stator Rotor Armature Types of Motors A stepper motor is driven by pulses; it rotates through a specific angle (step) with each pulse. Because the rotation is precisely controlled by the number of pulses received, these motors are widely used to implement positional adjustments. They are often used, for example, to control paper feed in fax machines and printers—since these devices feed paper in fixed steps, which are easily correlated with pulse count. Pausing can also be easily controlled, as motor rotation stops instantly when the pulse signal is interrupted. About DC Motor The speed of a DC motor can be controlled by changing the voltage applied to the armature. Variable resistance in the armature circuit or field circuit allows speed control. Modern DC motors are often controlled by power electronics systems which adjust the voltage by “chopping” the DC current into on and off cycles which have an effective lower voltage. What is Brushless Direct Current Motor(BLDC) Author: Kunal Gupta
Timer Peripheral in S32K144 Microcontroller
About FlexTimer Module: Timer peripheral in NXP S32K1xx and S32K3xx Automotive Microcontrollers
Kunal Gupta
Author: Kunal Gupta
Author