\u00a0 \u00a0ARM Cortex-M4 Processor + FPU\u00a0 \u00a0<\/span><\/strong><\/span><\/h3>\nArm\u00ae Cortex\u00ae-M4<\/span><\/strong><\/p>\n The Arm\u00ae Cortex\u00ae-M4 with FPU processor is the latest generation of Arm\u00ae processors for embedded systems. It was developed to provide a low-cost platform that meets the needs of MCU implementation, with a reduced pin count and low-power consumption, while delivering outstanding computational performance and an advanced response to interrupts.<\/span><\/p>\nThe Arm\u00ae Cortex\u00ae-M4 with FPU 32-bit RISC processor features exceptional code efficiency, delivering the high-performance expected from an Arm\u00ae core. The processor supports a set of DSP instructions that allow efficient signal processing and complex algorithm execution.<\/span><\/p>\nIts single precision FPU speeds up the software development process and accelerates the target performance. With its embedded Arm\u00ae core, the STM32L432KC microcontroller can be used in a wide range of applications. As we’ll see throughout the course.<\/span><\/p>\nThe other STM32F103C8 microcontroller has a Cortex-M3 core that lacks the FPU and DSP operations which can be a huge miss in certain applications, however, it’s much cheaper target MCU at the end of the day.<\/span><\/p>\nAdaptive Real-Time (ART) Accelerator\u2122<\/strong><\/span><\/p>\n The ART Accelerator\u2122 is a memory accelerator that is optimized for STM32 industry-standard Arm\u00ae Cortex\u00ae M4 processors. It balances the inherent performance advantage of the Arm\u00ae Cortex\u00ae-M4 over Flash memory technologies, which normally requires the processor to wait for the Flash memory at higher frequencies.<\/span><\/p>\nTo release the processor near 100 DMIPS performance @ 80MHz, the accelerator implements an instruction prefetch queue and branch cache, which increases program execution speed from the 64-bit Flash memory. Based on the 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 80 MHz.<\/span><\/span><\/p>\nMemory protection unit (MPU)<\/span><\/strong><\/p>\nThe memory protection unit (MPU) is used to manage the CPU accesses to memory to prevent one task to accidentally corrupt the memory or resources used by any other active task. This memory area is organized into up to 8 protected areas that can in turn be divided up into 8 subareas.<\/span><\/p>\nThe MPU is especially helpful for applications where some critical or certified code has to be protected against the misbehavior of other tasks. It is usually managed by an RTOS (realtime operating system). If a program accesses a memory location that is prohibited by the MPU, the RTOS can detect it and take action.<\/span><\/span><\/p>\n Firewall<\/span><\/strong><\/p>\nThe device embeds a Firewall that protects code sensitive and secure data from any access performed by a code executed outside of the protected areas. Each illegal access generates a reset which kills immediately the detected intrusion.<\/span><\/p>\n Boot modes<\/span><\/strong><\/p>\nAt startup, BOOT0 pin or nSWBOOT0 option bit, and BOOT1 option bit are used to select <\/span>one of three boot options:<\/span><\/p>\n\n- Boot from user Flash<\/span><\/li>\n
- Boot from system memory<\/span><\/li>\n
- Boot from embedded SRAM<\/span><\/li>\n<\/ul>\n
BOOT0 value may come from the PH3-BOOT0 pin or from an option bit depending on the <\/span>value of a user option bit to free the GPIO pad if needed. <\/span>A Flash empty check mechanism is implemented to force the boot from system flash if the <\/span>first flash memory location is not programmed and if the boot selection is configured to boot <\/span>from the main flash.<\/span><\/p>\nThe boot-loader is located in system memory. It is used to reprogram the Flash memory by <\/span>using USART, I2C, SPI or USB FS in Device mode through DFU (device firmware upgrade).<\/span><\/p>\n <\/p>\n
\n\u00a0 \u00a0System Architecture & Bus Matrix\u00a0 \u00a0<\/span><\/strong><\/span><\/h3>\n <\/p>\n
STM32L432KC (ARM Cortex-M4) Architecture<\/span><\/strong><\/span><\/p>\n<\/p>\n
<\/p>\n
The system mainly consists of 32-Bit Multilayer AHB Bus Matrix (Highlighted in Yellow) that interconnects the following hardware components:<\/span><\/p>\nFive masters:<\/span><\/strong><\/p>\n\n- Cortex\u00ae-M4 with FPU core I-bus<\/span><\/li>\n
- Cortex\u00ae-M4 with FPU core D-bus<\/span><\/li>\n
- Cortex\u00ae-M4 with FPU core S-bus<\/span><\/li>\n
- DMA1<\/span><\/li>\n
- DMA2<\/span><\/li>\n<\/ul>\n
Seven slaves:<\/span><\/strong><\/p>\n\n- Internal Flash memory on the ICode bus<\/span><\/li>\n
- Internal Flash memory on DCode bus<\/span><\/li>\n
- Internal SRAM1<\/span><\/li>\n
- Internal SRAM2<\/span><\/li>\n
- AHB1 peripherals including AHB to APB bridges and APB peripherals (connected to APB1 and APB2)<\/span><\/li>\n
- AHB2 peripherals<\/span><\/li>\n
- The external memory controller (QUAD SPI)<\/span><\/li>\n<\/ul>\n
This bus matrix enables multiple masters on the bus to communicate with slaves concurrently. This accelerates the overall performance especially when DMA units are programmed.<\/span><\/p>\nThe CPU can be doing some calculations and workload while the DMA1 unit is moving the data being received via SPI to SRAM1 memory space. All being done in the same time without CPU intervention or interrupts when every single byte is received.<\/span><\/p>\nMultilayer AHB Bus Matrix<\/span><\/strong><\/span><\/p>\n<\/p>\n
The BusMatrix manages the access arbitration between masters. The arbitration uses a Round Robin algorithm. The BusMatrix is composed of five masters (CPU AHB, system bus, DCode bus, ICode bus, DMA1, and DMA2 bus) and seven slaves (FLASH, SRAM1, SRAM2, AHB1 (including APB1 and APB2), AHB2 and QUAD SPI).<\/span><\/p>\n\n- S0 – I-Bus<\/strong>: This bus connects the instruction bus of the Cortex\u00ae-M4 core to the BusMatrix. This bus is used by the core to fetch instructions.<\/span><\/span><\/li>\n
- S1 – D-Bus<\/strong>: This bus connects the data bus of the Cortex\u00ae-M4 core to the BusMatrix. This bus is used by the core for literal load and debug access.<\/span><\/span><\/li>\n
- S2 – S-Bus<\/strong>: This bus connects the system bus of the Cortex\u00ae-M4 core to the BusMatrix. This bus is used by the core to access data located in a peripheral or SRAM area.<\/span><\/span><\/li>\n
- S3, S4 – DMA-Bus<\/strong>: This bus connects the AHB master interface of the DMA to the BusMatrix.The targets of this bus are the SRAM1 and SRAM2, the AHB1 peripherals including the APB1 and APB2 peripherals, the AHB2 peripherals and the external memories through the QUAD SPI.<\/span><\/span><\/li>\n<\/ul>\n
AHB\/APB Bus Bridges<\/span><\/strong><\/span><\/p>\n<\/p>\n
The two AHB\/APB bridges provide full synchronous connections between the AHB and the two APB buses, allowing flexible selection of the peripheral frequency. address mapping of the peripherals connected to this bridge.<\/span>
\nAfter each device reset, all peripheral clocks are disabled (except for the SRAM1\/2 and Flash memory interface). Before using a peripheral you have to enable its clock in the RCC_AHBxENR and the RCC_APBxENR registers.<\/span><\/span><\/p>\nMemory MAP<\/span><\/strong><\/span><\/p>\n<\/p>\n
<\/p>\n
\n\u00a0 \u00a0RCC & Clock Tree\u00a0 \u00a0<\/span><\/strong><\/span><\/h3>\n <\/p>\n
Resect and Clock Control (RCC)<\/span><\/strong><\/span><\/p>\n <\/p>\n
Resect and Clock Control (RCC) Circuitry is our next topic. Let’s just start with the reset circuitry and its functionality. There are three types of reset, defined as system reset, power reset, and backup domain reset.<\/span><\/p>\n A Power Reset<\/strong> is generated when one of the following events occurs:<\/span><\/p>\n\n- a Brown-out Reset (BOR).<\/span><\/li>\n
- when exiting from Standby mode.<\/span><\/li>\n
- when exiting from Shutdown mode.<\/span><\/li>\n<\/ul>\n
A System Reset<\/strong> sets all registers to their reset values unless specified otherwise in the register description. The reset source can be identified by checking the reset flags in the Control\/Status register, RCC_CSR. A system reset is generated when one of the following events occurs:<\/span><\/p>\n\n- A low level on the NRST pin (external reset)<\/span><\/li>\n
- Window watchdog event (WWDG reset)<\/span><\/li>\n
- Independent watchdog event (IWDG reset)<\/span><\/li>\n
- A firewall event (FIREWALL reset)<\/span><\/li>\n
- A software reset (SW reset)<\/span><\/li>\n
- Low-power mode security reset\u00a0<\/span><\/li>\n
- Option byte loader reset\u00a0<\/span><\/li>\n
- A Brown-out reset<\/span><\/li>\n<\/ul>\n
The Software Reset: The SYSRESETREQ bit in Cortex\u00ae-M4 Application Interrupt and Reset Control Register must be set to force a software reset on the device.<\/span><\/p>\n<\/p>\n
The Backup Domain Reset<\/strong> has two specific reset signals. A backup domain reset is generated when one of the following events occurs:<\/span><\/p>\n\n- Software reset, triggered by setting the BDRST bit in the Backup domain control <\/i>register (RCC_BDCR)<\/i>.<\/span><\/li>\n
- VDD<\/sub> or VBAT<\/sub> power on, if both supplies have previously been powered off. A backup domain reset only affects the LSE oscillator, the RTC, the Backup registers, and the RCC Backup domain control register.<\/span><\/li>\n<\/ol>\n
<\/p>\n