I welcome you to this part of my RoadTest review. In this part I will describe Renesas RA2L1 microcontroller in details. In this part I will not describe evaluation board because it is described in dedicated blog post Review of Renesas EK-RA2L1 Development Board. Except these two review chapters there are one tutorial describing how to use serial bus drivers, DMA and Interrupts using this microcontroller. Tutorial is split to two parts available at: first part, second part.
Classification of MCU
At beginning I want to describe families and subfamilies which reviewed MCU belongs to. Ordering code of MCU is R7FA2L1AB2DFP. This code is also written at first line of MCU package. While this is full ordering code, MCU is usually referred in the documentation as RA2L1. For some reason Renesas adds “7F” between first and second letter of name. According to documentation 7 means Microcontrollers unit (probably division that the chip is designed by) and F means flash memory. When you omit these two letters then you can read MCU name as RA2L1AB2DFP. The first two letters of this name refer to the main family of MCU. RA means MCUs with ARM Cores. Other possible families are RX, RE, RZ, RH, RL. One of the most important family in Renesas offer is RX family which is their flagship family with their own high performance CPU core instead of ARM Core. According some benchmarks these MCUs are more performant than ARM competitors like currently reviewed MCU. RZ family contains high performance ARM MPUs. RL family contains 8-bit and 16-bit MCUs. RH family contains automotive grade 32-bit microcontrollers and finally RE family contains ARM MCUs which are manufactured using specialized manufacturing process that results to lower power consumption in sleep modes. Last family and the only family which name do not contains R at beginning is Synergy family which contains another ARM MCUs. This review targets MCU from RA family and most content will be related to this family.
The first number after family name refer to subfamily. Currently there are 4 subfamilies referred at Renesas RA webpage. They are RA2, RA4, RA6 and RA8. RA8 currently has no MCU published yet, so technically there are 3 subfamilies. RA2 is least complex subfamily and RA6 is most complex subfamily. RA4 is somewhere between them. This Review MCU from RA2 subfamily, so expect review of one of the most entry level MCU from Renesas offer. The letter after first number refers to type of MCU. Used letters are E, L, M, W and T. E means entry-level, L means low-power, M most probably means Mainstream, W means Wireless and T means motor. Reviewed MCU has L in name, so it is designed as a low-power MCU.
Last number in main part of name refer to group. It has no special meaning but for example in RA4 and RA6 subfamily there are multiple Main groups, so they are distinguished by this number. For example, there are RA4M1, RA4M2 and RA4M3. Higher second number means more features. Reviewed MCU is part of RA2L1 group which is the only low-power group inside RA2 subfamily at the time of writing this review.
Last letters and numbers in name refers to feature set (presence of security engine in case of RA2L1), memory size, package size, operating temperature range and quality grade (consumer and industrial quality grades are available for RA2L1 group).
So, now we know what that MCU which is reviewed in this review is as part one of the most entry level family in Renesas RA family and it is designed as low power. Because MCU is entry level you cannot expect some advanced peripherals known from flagship high performance MCUs here but there are still lot of very interesting features.
At beginning I will describe basic subsystems like CPU core, clocking, and interrupts. Then I will describe performance and peripherals, later I will also describe available software like SDK and development environment.
At the beginning I likely to say something about CPU core used in this RA2L1 MCU. Used core is Arm Cortex-M23. It is one of the newer generations of Arm Cortex cores available today, but it is very similar to Cortex-M0. In fact, they are very similar and there are only few improvements. The most important benefit of Cortex-M23 core to the M0, M0+ and M1 are new security options, especially TrustZone. But TrustZone is optional feature of Cortex-M23 and Renesas did not integrate it in this MCU. Higher RA families like RA6 has better ARM Cortex-M33 core with integrated TrustZone. In opposition memory protection unit is implemented. It allows you to configure 8 memory regions to protect. Another benefit of Cortex-M23 is division instruction which significantly speedup division operations. Another benefit when comparing to old Cortex-M0 is relocable vector table which allows you to easily switch interrupt vector table or move them to different memory (usually RAM). Support for relocable VTOR is not mentioned in any documentation, but I experimentally checked that it works, so Renesas implemented it. Otherwise, cores have very similar features to other Cortex-M0, M0+ and M1 cores. You cannot expect features like saturated arithmetic instructions, DSP instructions and support for float operations. All these operations are emulated in software when used. This means that doing these operations is significantly slower in comparison when doing the same on core which support them natively (for example Cortex-M7).
Maximum clocking speed of core present in RoadTesteted unit is 48 MHz. It is not the best in class, but it is still much better than any common 8-bit MCU and it is acceptable from entry level MCU. Higher MCUs in Renesas RA family can be clocked up to 200 MHz.
Clock subsystem is very simple, but still briefly configurable. Do not expect complex clocking subsystem with lot of domains and integer divers like you may know from Cypress PSoC MCUs. But it still has more features than for example MCUs from Maxim Integrated or Nordic semiconductor and clocks are not fixed to single working frequency. RoadTested unit is very simple and do not have some features which are present in more advanced MCUs in RA family. For example, RA2L1 has no PLL. More advanced RA MCUs have one or two PLLs. There are multiple possible clock inputs. You can use two external crystals and three internal oscillators. One internal oscillator is also configurable and support multiple frequencies. For most domains you can select dividers. Only powers of two are available. There are no integer dividers. MCU support clock out feature, so you can expose internal clock signal to output pin. The biggest issue of RA2L1 I consider lack of PLL. The maximum external crystal frequency is 20 MHz. If you want to run your MCU faster, then you need to use internal oscillators which are less accurate than external crystal. If you need for example accurate clock of frequency about 40 MHz for clocking timers, then you are out of luck on this MCU. When using higher families of RA MCUs there are no issue. The best way to visualize clock subsystem is using configuration tool which is part of e2studio. Following image visualize clock subsystem on RA2L1 MCU.
Renesas MCUs has lot of signals possibly usable as interrupts. Renesas decided to connect interrupts to the matrix and enable user to configure which interrupt connect to NVIC of Cortex-M23 core. There are no fixed interrupt numbers for peripherals like you may know from other microcontrollers. RA2L1 allows you to connect 32 interrupts to the Cortex core. Higher RA families allows you to connect more interrupts to the CPU. For example, RA6M4 allows you to connect 96 interrupts to the MCU. While RA6M4 has no restrictions about your choice of 96 interrupts, RA2L1 has some. For example, interrupt generated when overflow from fifth timer happens (GPT4_OVF) is connectable only to IRQs 6, 14, 22 and 30. If you have connected other sources to these IRQs, then you are out of luck. Some interrupts are connectable to 4 IRQs (it is example of GPT4_OVF), but most of them is connectable to 8 IRQs, so in most cases you can do your choice in more flexible way. While this restriction exists, I did not find any situation and commonly used combination of interrupts impossible to configure. Unless you use all peripherals and needs all interrupts you most probably never notice this limitation. And even you face this issue you can in most case just use different instance and then you can map required interrupt to other set of IRQs. So, you do not need worry about it much.
Interrupt controller is not used only to connecting interrupts to NVIC, but it is also used for triggering DTC (Data Transfer Controller) transfers. DTC is something like DMA and you can trigger transfer using very similar set of signals. You can configure triggering both interrupt and DTC by signal at the same time.
While it looks complicated, you do not need to understand this much because e2studio development IDE will map interrupts to IRQs for you.
Renesas RA MCUs can be powered by very broad range of voltages. In case of RA2L1 the range is 1.6 to 5V but at 1.6V you are very limited, and you get full range of features starting at 1.8V. Between 1.8 and 5V you can run chip at full clock speed. Below 1.8V you are limited to 4 MHz. Powe consumption of MCU is very low. You can find extensive tables in the Datasheet. There are multiple sleep modes. Typical power consumption in the sleep mode with 32.786 kHz clock used and all peripherals disabled is mentioned as 2 micro ampers in datasheet. This is very nice result. I have limited opportunity to verify these values, so I did not check for it, but I think this is possible with latest semiconductor technology and good design. MCU has integrated LDO and switching regulator for generating low voltage for powering CPU core and internal peripherals. You can choose which regulator you want to use. When choosing LDO you need only few external components (2 decoupling capacitors). When choosing DC/DC mode, you need to provide more external components including coil, but you get better efficiency. LDO mode is recommended when using MCU in low power modes and when it runs on very low frequencies. DC/DC mode is best when running MCU for most time at full speed. There is restriction that when using advanced sleep modes with lower possible consumption, you cannot use DC/DC mode. It looked complicated to me at the first look, but later I probably realized how does it works.
RoadTested EK-RA2L1 kit has cut traces, so you can choose powering mode, but you cannot adjust powering voltage or provide external one. As I have specified in blog post Review of Renesas EK-RA2L1 Development Board, powering voltage is fixed to 3.3V and there is no easy way how to evaluate MCU at other voltages.
RA2L1 is one of the least advanced subfamilies in RA family, so there are some restrictions which do not apply for higher subfamilies. One of the most significant (related to powering which I describe in this section) I consider lack of RTC powering domain. Some competitor MCUs (and higher RA subfamilies also do) has dedicated powering pin for powering RTC domain from the coin battery, but RA2L1 RTC power domain is powered directly from main voltage and you cannot use separate independent power source for powering it. MCU is designed for powering by standard (possibly rechargeable) battery, so in many cases this restriction does not affect you.
While MCU is entry level and has lot of restrictions which I mentioned above, it still has lot of interesting peripherals including peripherals that are usually present only in middle or high-end MCUs. Peripherals are very good part of this MCU. RA2L1 MCU contains balanced mix of components. Peripherals are advanced and support many features.
There are 10 timers. Four of them are 32-bit timers and remaining six timers are 16-bit. Except these 10 timers there are additional two 16bit low power asynchronous timer. Another timer is RTC timer. It is not just a second timer you may know for example from Nordic MCUs, but It is timer with date and time registers that are automatically adjusted like you may know from dedicated RTC chips. So, you do not need to recalculate dates from Unix timestamp or other kind of counters, and you get full date time from this peripheral without need of any conversion.
There are two SPI controllers, two I2C controllers and 5 generic serial bus controllers that can be used as a SPI controller, I2C Controller, UART, smart card interface and some other.
MCU has both ADC and DAC. Both are 12-bit. There is temperature sensor which can be used for measuring temperature of chip die. Output of this sensor can be connected to the ADC input. Voltage comparator is yet another analog peripheral. The last analog peripheral is capacitive touch sensing unit used for capacitive touch buttons sliders and other components.
RA2L1 MCUs has two peripherals for processing data. One of them is used for calculating CRC and second peripheral is Data Operation Controller (DOC) which can be considered as an entry level DSP block. It can add, subtract and compare values received at input.
Lastly, MCU also has two watchdogs (one of them is independent).
As you can see, while MCU is part of one of the lowest RA family It has plenty of peripherals. Peripherals mentioned above I consider as a standard peripheral but there are also some peripherals which I consider unique and interesting. I will describe them in following section.
Unique and Interesting Peripherals
CAN bus driver
The first peripheral which I consider interesting is CAN bus driver. Vere few entry level MCUs features CAN bus driver. Renesas is company specialized to automotive segment and almost all their MCUs have CAN bus driver (CAN bus is commonly used in automotive).
Data Transfer Controller
Another interesting peripheral which is rarely part of entry level MCUs is DMA. MCU has DTC (Data Transfer Controller) peripheral which is efficiently DMA controller. Higher RA families have the same DTC peripheral, but they have more complex additional DMA Controller. DTC controller, which is part of RA2L1 can do single, repeat, or block transfers. Transfers are triggered using signals used as interrupts. You can configure signal to trigger data transfer, interrupt, or both inside Interrupt Controller Unit (ICU). You can define transfer for every mapped interrupt. RA2L1 supports 32 configurable interrupts, so DTC has efficiently up to 32 channels. Information about transfers is stored in RAM memory. You provide array of pointers to the structures containing configuration and status data for each used channel. It is nice and useful DMA controller. DTC can be utilized using SDK but mostly its details are hidden, and it just works out of box. You can see it in my tutorial blog post. In second part of this tutorial, I shown using SPI driver for transferring screen buffer to the display and SDK internally uses DTC for managing transfer at background.
AES and TRNG
Another peripheral which other vendor adds to middle-end MCUs and higher are cryptographic engines. RA2L1 has true random number generator and AES engine. Both peripherals are not documented in User Manual and you need sign NDA when you are interested in their documentation. It is sad especially in case of TRNG. According to datasheet AES engine should support 128 and 256 bit variants of AES, but tinycrypt library provided as a FSP stack in e2studio contains support only for AES 128 and I did not find any other reference to AES 256. Accelerator do not support any kind of hash functions and do not support any kind of asymmetric cryptography. Similarly, I did not find any reference to secure storage for keys. But still is nice that at least AES is here for you. Of course, higher RA families support all of them.
As I have already mentioned, many Renesas MCU (and other products) target automotive and other safety critical segments. As a result, RA2L1 MCU (and other MCU within RA family and other families) has lot of safety related features. For example, there are lot of write protections. Usually, vendors provide write protection to disable watchdog timer, but Renesas includes write protection on much more places. User manual has dedicated section “Register Write Protection” containing description about protections related to clocking subsystem, low power modes and low voltage detections. Except these protections, lot of peripherals have some own protections. For example, IIC (Renesas refer I2C as IIC) peripheral has write protection for preventing occasionally toggling state of driving I2C bus lines, occasionally switching between master and slave mode and occasionally transmitting acknowledge bit. If you want to access protected feature, then you need to unlock protection first. Protections are used to prevent issuing malicious operation that affects system stability and operation in case of failure and reduce impacts of this failures.
Another safety related feature is error checking on RAM. RAM is split to two parts. Lower half of memory is protected by error correcting code (ECC) and second half of memory is protected by parity. Lower half of memory can detect up to 2-bit error and fix up to 1-bit error. Second part of memory can detect up to 1-bit error and cannot fix any error because it has no idea which bit (of 8 bits) is wrong. For example, when one-bit toggles due to some strange thing, then in case of lower half of memory you do not need to worry about anything and ECC will fix error for you. In case the affected memory cell belongs to the second half memory, then it cannot fix error, but can notify you that you have read wrong value and possibly reset your MCU. Flash memory is protected against tampering and errors when erasing and writing.
Another interesting safety feature is that MCU can detect when oscillator stop and fallback to internal oscillator when external crystal (or PLL in MCUs that have PLL; RA2L1 have no PLL) stop working for some reason. Another feature which is not so common in microcontroller is unit that count ticks of clock and comperes them with some other reference clock. This unit can be used for checking clock stability and possibly generate interrupt when it detects mismatch from expected value.
As you have seen, while RA2L1 is one of the lowest MCU in family it still offers lot of safety features that we can know only from middle and some only from high end MCUs from other vendors. Sometimes other vendors add these features to the automotive grade MCUs only. But Renesas adds them to almost all their MCUs. If you develop some application and need these safety features, then Renesas MCUs are good choice for your project.
In following sections I will describe every software part related to development on RA2L1 platform. Most information applies to other RA families also. In following sections I will describe provided development environment, FSP concept, peripheral drivers and example projects which are available to you when developing firmware for RA2L1 microcontroller.
e2studio is eclipse based development studio. In comparison with most IDEs from other vendors is it significantly modified and is much better than standard eclipse. Renesas tweaked IDE well and added bunch of functionalities to the standard eclipse implementation. There are also preinstalled plugins. Projects created by this tool are configured well. It is easy to do even complicated modifications in project structure. I like this IDE much. Quality of IDE is comparable to competitive STM32CubeMx. I think that this IDE is even better. In many features they are comparable, but I consider Renesas e2studio better. My main reason for considering e2studio better is that e2studio do not need to download huge packages before using new family of MCUs and is faster and more responsive in comparison with STM32CubeMX. For example, loading tool to configure project loads in e2studio immediately while loading STM32CubeMX project configured takes multiple seconds on the same computer. Another difference is structure of generated projects. e2studio generates source in dedicated folder for generated source and do not affect your own code unless you want. In opposition STM32CubeMX generate whole code for you and you need to modify generated sources. In case of e2studio you do not need to modify any generated source.
Development environment has some smart very useful windows like window containing links to available documentation containing notifications about new revisions of PDF document available. Lot of documentation is also integrated directly into development environment and for example brief description of software function of peripheral drivers is available as part of FSP configuration tool.
Flexible Software Package (FSP)
Flexible software package is concept widely used in Renesas RA ecosystem. It allows you to add packages to the projects. Packages contains common libraries and peripheral drivers. Generated sources contain only libraries which you have chosen. This approach reduces firmware size because firmware contains only used libraries. Package generator support integration with RTOSes and their threads. All packages are configurable. In case of peripheral driver, you can specify driver specific properties. For example, in case of I2C bus driver (It is referred as IIC on RA platform) it is bus speed, slave address, timeout feature and much more. Configuration is also available to the other libraries. For example, MbedTLS stack allowing you to use cryptographic engine allows user-friendly configuration of macros used in this library.
FSP packages are stackable, and you can for example stack SPI driver with DMA driver for using DMA for transfer. Stacking is limited to configurations that make sense. Stacking allows very easily change internal implementation of package without need of any intervention from developer. This is nice concept, and it works well.
Concept like FSP we can see in offering of other vendors like STM and Cypress. Both have similar concepts but Renesas have it more polished. Configuration tool is easy, integration is user-friendly, errors from generator are human readable and it is easy to understand internals of every configuration that you can do in this tool. It also saves you lot of time in prototyping time when you are not exactly sure yet about libraries that you want to use in your design because you do not need to integrate and port every potential library manually and you can just easily add and remove libraries without any writing code or porting anything.
As I have mentioned in section above, peripheral drivers are available as a configurable package. Peripheral drivers are designed as HAL and there is no layer usually referred as standard peripheral driver (StdPeriph) between HAL and registry access approach. This kind of drivers usually allows access all features of peripheral, but do not require any knowledge of registers. Renesas do not provide this type of driver. Provided HAL driver directly accesses registers. Provided driver allows utilize only main features of peripherals. Some features can be statically configured using FSP configuration tool but there is no support for advanced (and interesting) features of microcontroller. If you want to use them, you need to drive registers manually. It is not hard but cost you a lot of time and debugging. For example in tutorial Using I2C, SPI and DMA on Renesas RA2L1 I shown feature allowing manual generation of clocks (which is supported by peripheral), but I had to manually control register bit because this feature (and many more features of IIC driver) are not integrated as part of library.
I consider lack of support for advanced peripheral features as a biggest disadvantage of this platform in comparison with STM32 and Cypress PSoC platform where are multiple libraries available. It allows use peripherals at more levels of abstraction and lower-level libraries allow use all (or almost all) features of peripherals without need to study registers.
Renesas provides bundle of example projects available do download page of EK-RA2L1 after login. There are 32 examples showing usage of peripheral drivers. There is also example project showing usage of FreeRTOS. Some examples require external hardware. All example projects contain readme file describing what is going on and details about connecting required hardware before running example. Example projects are easy to read and well documented. Most of them are simple, few example projects are quite complex. While they are not necessary for getting started due to high-quality documentation, I recommend looking at them when beginning with Renesas RA platform.
Renesas provide very high-quality documentation. It is one of the best MCU documentation which I have seen. Main documents related to MCU are Datasheet and User Manual. Datasheet contains overview of chip features, pinouts, electric specifications and many other. Renesas follows structure that use almost all vendors and datasheet does not contains detailed description of all peripherals and registers. These information are available in User Manual document. Both documents are useful and very detailed. Especially User Manual is very detailed and contains lot of details which other vendors frequently omits. Renesas present all details explicitly. Similarly, they describe all relations to other part of systems. For example, every flag bit has explicitly specified conditions when it is set and when it is cleared.
Renesas describes revision of documents in very high details. While most other vendors in revision changes table just note something like “Chapter X.Y.Z changed.”, Renesas describes changes more precisely. For example, change of some value in table is described by exact name of changed variable. It is nice because it significantly reduces manual checking for changes when new revision became available. Also note, that Renesas website supports subscribing for notification raised when new version of subscribed document become available.
I did not find any mistake and error in Datasheet and User Manual when RoadTesting EK-RA2L1.
Except documentation about MCU, Renesas provide similarly comprehensive documentation about other part including FSP packages. Documentation related to FSP is generated by doxygen and available online. The same documentation is also exported to PDF for printing/offline viewing. Generating documentation to PDF I like because in PDF viewer it is easy to search in comparison with doxygen documentation.
Compatibility within Renesas RA family
Compatibility between RA families is very good part of Renesas RA ecosystem. Renesas use almost exactly the same peripherals across whole RA family. For example, IIC peripheral used for driving I2C bus are the same in both low-entry and high-end families. Similarly, FSP peripheral drivers are platform neutral, codebase is shared across families and porting your program between families is easy. e2studio allows you to easily change MCU model.
While compatibility between RA family is very good, compatibility across other families like RX does not exists at all. RX and RA are completely different MCUs with different CPU cores, different peripherals, and different development concepts (RX MCUs do not use FSP architecture).
The RA2L1 MCU is good MCU, and I like it. While some core subsystems are quite limited and interesting Cortex-M23 features like TrustZone are not implemented, it still has lot of benefits and advanced peripherals. RA2L1 has lot of features targeting safety critical applications. Similarly, it has CAN bus controller for automotive applications. RA2L1 is low-power MCU with multiple powering options and broad operation voltage range allowing running it from battery for a long time. Provided development environment is one of the best in category. Provided FSP peripherals drivers do not support utilizing full potential of MCU but are easy to use. Documentation is very detailed and high quality. To summarize, I recommend looking at Renesas RA family when choosing MCU for your next application.