BLE Embedded MCU's IoT STM32 MCU's STM32WB55 Tech

Introduction to STM32WB55

Table of Contents

About STMicroelectronics

STM32WB55STMicroelectronics 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.STM32WB55

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.

STM32WB55
Applications of STM32WB55

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!

STM32WB55
STM32WB Series

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.STM32WB55

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

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); 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 which has to be triggered by hardware. Upon receiving the configured hardware signal, ADC conversion starts for those channels. After

Read More »

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

Read More »

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

Read More »

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

Read More »
Kunal Gupta
Author: Kunal Gupta

Author

Kunal Gupta

Leave a comment

Stay Updated With Us

Error: Contact form not found.

      Blog