 Hello, and welcome to this presentation of the STM32 Chrome GRC. This chapter presents the features of the memory management unit used in graphical-oriented applications. The Chrome GRC is a graphic-oriented memory management unit to optimize the memory usage according to the display shape. The Chrome GRC lowers the memory usage by storing only the visible pixels in the memory. It is fully configurable according to the display shape and is totally transparent in the system. The Chrome GRC works with any memories and any masters of the STM32. The Chrome GRC is seen by the masters of the STM32 system as four virtual buffers to store the graphical frame buffer. Each virtual buffer consists of 1024 lines with 3072 or 4096 bytes per line. The size of each line is configurable by software. In case of accesses exceeding the buffer space, a buffer overflow interrupt can be generated and in case of wrong physical memory address, a memory transfer error is generated. The display shape is described in a lookup table to define which bytes of the virtual buffer have to be stored or not in a physical memory. Thanks to this very flexible architecture, only the visible pixels are effectively stored and each virtual buffer can be physically mapped to any memory of the system. Each virtual buffer is seen as a continuous memory space of 3072 or 4096 bytes per 1024 lines. Each line is composed of 192 or 256 16 byte blocks. In this example, out of screen blocks shown here in white won't be mapped into the physical memory. For each line, the first visible block and the last visible block are stored in the lookup table. Only the visible blocks of each line will be stored in the physical memory. The operation is repeated for each line, indicating the first block and the last block. All the first and last block numbers are stored in a lookup table. And all the visible blocks are stored in the physical memory in a continuous way, saving a huge amount of space for non-rectangular display shapes. All the line parameters are stored in an internal lookup table. The description is the same for all four virtual frame buffers. For each line, the following parameters are stored. The enable bit of the line, the number of the first visible block, the number of the last visible block, and the line offset in the physical memory. The line offset is the offset between the physical buffer base address programmed by the user and the address where the block zero of the line has to be stored. Each virtual buffer has its own base address in the physical memory. The Chrome GRC runs with two operating modes. 192 blocks per line mode or 256 blocks per line mode. The 192 blocks per line mode is useful as we can have an integer number of pixels per line when the frame buffer color mode is in 24 bits per pixel. Thanks to the smart mapping of visible pixels in the memory, the Chrome GRC reduces the RAM usage significantly for the graphical frame buffer. For a round display, the gain is above 20%. There may be slight variation depending on the frame buffer color mode. The Chrome GRC manages five interrupt sources. AHB master error when an error occurred during an AHB transaction to the physical memory. And four buffer overflows, one per buffer when an overflow occurs during the offset calculation of a buffer. The Chrome GRC is active in run and sleep modes. A Chrome GRC interrupt can cause the device to exit. In stop mode, the Chrome GRC is frozen and its registers content are kept. In standby mode, the Chrome GRC is powered down and it must be re-initialized afterwards. Wearable applications require low power management functions together with a high quality user interface. In this context, the Chrome GRC optimizes the internal RAM usage and it's no longer necessary to add an external component for SRAM or SD RAM. The graphical content creation is much faster thanks to the internal zero-weight state RAM. You can refer to peripheral training slides related to RCC and interrupts.