DIY hardware developers today are spoilt by the ease with which they can create processor-intensive hardware with very little prior knowledge. A Teensy 3.2, for instance, runs at 96MHz and can easily process and output CD-quality audio (through its Audio Adapter Board), and the relatively small amount of coding you need to do is well documented and easy.
If you need something a bit more powerful (and with quite a bit more RAM than the Teensy 3.2’s 64KB), there’s PIC – their top MCUs (PIC32MZ) run at 200MHz, with 512KB RAM. Not quite as easy to use as Teensy / Arduino, but still manageable, and with a large user community who can help you out. (The top PIC32MZ does have many known errata, for which users are anxiously awaiting an updated version.)
But where to if you need even more power than that? That’s the question that I came up against a few months ago, and nowhere on the Internet had a definitive answer. For an advanced piece of music hardware I’m developing, I needed something with as much processing power and RAM as possible.
The option I went with, and spent several difficult months learning how to use, is the Renesas RZ. It runs at 400MHz (and has 3 times the DMIPS of the top PIC32MZ), and has between 3MB and 10MB of onboard RAM, depending on the model, and allows you to connect up to 128MB of external SDRAM. Its specs are an enormous upgrade from Teensy and PIC.
My own synthesizer engine, which crunches 32-bit integers, runs 4.2x faster on the Renesas RZ than Teensy 3.2 / 3.1. (That’s with virtually the exact same codebase – I’d bypassed the Teensy audio library and am writing generated audio data straight to a DMA-read output buffer in both cases. The same GCC optimisation settings were used.)
However, if you’re used to the friendly documentation and active online user communities around Teensy, Arduino and PIC development, you’re not going to find Renesas easy: all there is is a 2,500 page datasheet, a few example projects, and the RZ forum only gets about 3 posts per week. And yet, it’s still the best option. Nowhere could I find any hint of an MCU more powerful than the PIC32MZ with a more active user community than the Renesas RZ’s very small one.
The purpose of this post is not to provide a step-by-step guide to using Renesas RZ microcontrollers. They are extremely complicated things to use, and developers will need to know (or learn) how to do things like design their own PCBs (see below), read and understand MCU datasheets, tweak linker scripts, and unless your luck is significantly better than mine, probably troubleshoot seemingly unexplainable problems for days at a time.
This post is intended simply as a DIY-friendly introduction to the Renesas RZ so that you can assess its suitability for your project, and have some pointers should you decide to begin developing with it.
- The Renesas RZ has multiple SPI ports, which Teensy 3.2 doesn’t have (but PIC does).
- A possible advantage over PIC is that Renesas RZ development standardly uses the free GCC compiler, which includes the option to significantly optimise your compiled program. My understanding is a little limited here, but it appears that with PIC, you have to use Microchip’s XC compiler, whose free version does not include any optimisation (and the paid versions cost $495 USD and $995 USD). I could have this wrong though – maybe there is a way to use GCC with PIC.
- The Renesas RZ includes an SD host interface – for talking to SD cards using a faster method than SPI. This sounds great, but what I didn’t initially realise is that in order to obtain the code library for this, or even the corresponding chapter of the datasheet, you need to sign a non-disclosure agreement with Renesas. This will be related to the fact that SD cards are proprietary technology, and companies have to pay a $2000 USD per year licensing fee to Secure Digital if their products interface with SD cards using the non-SPI interface. I contacted Renesas, hoping to go through the process of signing the NDA so that I could use the SD host interface in my own personal, non-commercial projects, but I think they cottoned on that I’m just a DIY enthusiast and not a large company. You can still access SD cards using SPI though – I’ve done this successfully, using the free FatFS library for handling the FAT filesystem.
How to get a Renesas RZ
If you’re used to working with Teensy, Arduino, and possibly PIC, you’ll be used to buying your microcontrollers as existing PCBs, all set to be wired up to LEDs and switches, with a USB connector for programming them. And it’s cheap. Whereas, Renesas’s development board for the RZ (the Renesas Starter Kit+, or RSK+) costs…….. $1,100 USD.
A couple of other companies have created and are selling Renesas RZ development boards significantly cheaper:
- The Vekatech VK-RZ/A1H – 49.99 EUR. Purchase here.
- The Computex CEV-RZ/A1L – I can no longer find the purchase link, but I think it was around $100 USD
The option I prefer, however, and the one I’m going to provide info on, is the creation of a custom PCB. If you’re working on a project advanced enough to require something as powerful as the Renesas RZ, chances are you’ll be planning to do this anyway, so it may be logical to jump straight to this step rather than first experimenting with the pre-built boards. The Reneas RZ chips cost between $18.11 US and $35.96 US on Digi-Key, depending on RAM size.
If there’s any interest, I may eventually share the design for, and possibly even sell pre-made, my own basic evaluation board for the Renesas RZ.
A significant difference between the Renesas RZ and any of the more common DIY-friendly MCUs is that the RZ does not store its program (the code you write) on on-chip flash memory. The program has to be stored on an external flash memory chip, connected via SPI. It’s ok – these chips cost just a couple of dollars for a few megabytes. The user will probably want to set up a bootloader program to copy the main program from flash to RAM before it is executed. Renesas provides a working one – see below.
Unfortunately, programming the Renesas RZ (i.e. programming its external flash chip) isn’t as simple as just plugging in a USB cable as you might be used to. There are a couple of different ways you can do it. The ideal way, recommended by Renesas, is to use a device called a J-Link, made by a company called Segger. Digi-Key stocks them. The J-Link is a “JTAG emulator”. It provides a connection between your computer’s USB port and the Renesas RZ’s “JTAG” port (you’ll build a connector into your PCB), allowing it to do a couple of things:
- Program your external flash memory chip – but only if you have an expensive version of the J-Link – see below
- Load your program directly into the Renesas RZ’s RAM for immediate testing and even live debugging (pretty cool)
For a DIY developer, getting all of this working is prohibitively expensive. There is a cheap version of the J-Link – the “EDU” model – which is only $60 USD and licensed for educational purposes only. It can load your program to RAM and do debugging, but it doesn’t come with the software J-Flash for programming your external flash memory chip. The cheapest J-Link to come with this software is the $598 USD version. Or you can buy the J-Flash software separately for $384 USD, but the Segger website suggests that it doesn’t work with the J-Link EDU anyway. There is also a “lite” version of J-Flash, which is free and works with the J-Link EDU, but it doesn’t appear to support the Renesas RZ. (Please note that I have not personally verified that the J-Flash software can program the Renesas RZ at all – I don’t have it, and only have some fairly hazy information to go by, so research this yourself before spending lots of money.)
The solution if you’re on a budget is to instead (or preferably in addition) use something like a FlashCatUSB ($30 USD) to program your flash memory. The FlashCatUSB connects directly to your flash chip via SPI (you’ll need to build a physical connector for this into your PCB), and comes with free software for programming it. There are some complications to this method though – it’s really a bit of a “hack” compared to the elegant but expensive J-Link:
- You need to keep your Renesas RZ in “reset” mode (you’ll normally build in a hardware button for this) while programming your flash chip, otherwise the RZ will try to access the chip at the same time as the FlashCatUSB and it won’t work. In fact, you’ll want to make your PCB’s reset button a toggle switch rather than a momentary button so that you can leave it in reset mode hands-free.
- If you’re going to leave the FlashCatUSB connected to your flash chip while you run your program, you’ll need to disconnect the FlashCatUSB from your computer’s USB port first, otherwise again, both things will be trying to access the flash chip at once.
- After writing your program to the flash chip, you need to switch the power off and on again to the RZ to flush a potentially cached version of what was on the flash chip before.
So a sensible and economical solution (provided it’s just for “educational” purposes, which it probably will be, because you’ll have a lot to learn) would be to use the $60 USD J-Link EDU for debugging and running your program directly from RAM, and the $30 USD FlashCatUSB for programming your flash memory so your creation can function away from your computer.
Designing a PCB
The best resource on what your Renesas RZ schematic should look like is Renesas’s own schematic for the RSK+. By copying the parts of this that I needed, and referring to the datasheet a lot, I was able to create a functioning board. The Computex CEV-RZ/A1L also has its schematic publicly available – it’s a bit simpler as it has less add-ons included.
Some important notes on your PCB design:
- I would recommend starting with the 10MB RAM version of the RZ – the RZ/A1H, because some of the example projects’ linker scripts are configured to use the full 10MB, and need modifying in order to run on an RZ with less RAM (this is the case with the USB example project). That can be done though, if you prefer. The RSK+ uses the 208-pin version of the chip, so perhaps you’ll find that easiest if you’re copying the schematic, and it might mean the example projects will be happier to run without modification. But I used the 176-pin version and got it working.
- Unlike custom PCBs based on Teensy or PIC, you need a “reset supervisor”. Switching power on to the Renesas RZ chip sometimes doesn’t cause it to start up correctly. It needs to be kept in “reset” mode momentarily first, which is what a reset supervisor does. This is very easy and only needs one component – I use a APX803-31SRG-7. Making this setup compatible with the JTAG connection needs to be done right. The RSK+ schematic’s way is quite complicated. I do it an equivalent and easier way – here’s the schematic. You can see the reset button, reset supervisor, and JTAG connector.
- If you’re going to use one external SDRAM chip, but not two, it should be connected to CS3 (that is, the pin called CS3, which will also “attach” it to the “CS3 address space” as it’s referred to in the datasheet). Both the datasheet and some comments in a Renesas example project state this requirement, although I’m not sure exactly what would happen if you connected your lone SDRAM chip to CS2 instead.
- The SDRAM chips that you’re able to use with the RZ are generally the 54-pin ones which operate off a 3.3V supply, and may be up to 64MB each. The RSK+ uses the K4S561632D (32MB) which can be had for only a dollar or two on sites like AliExpress. From the more mainstream suppliers, Digi-Key has the 32MB AS4C16M16S-6TCN for $2.84 USD (that one I haven’t personally tried yet), or the 64MB MT48LC32M16A2TG-75:C for $11.95 USD. Conveniently, these chips all share the same pinout.
- As you will see, the RZ requires a 1.2V supply as well as 3.3V. You should use a switching regulator like this one, rather than a linear regulator, to supply the 1.2V, because the RZ will draw almost 400mA from it, which is huge, and a linear regulator would be terribly inefficient.
- While there might be a technically better way to do it, the board I created was just 2-layer. In order to achieve all the routing between the RZ and my SDRAM chip, I “piggy-backed” the two of them on opposite sides of the board. This meant that the SDRAM chip was kind of disrupting my ground plane, but it still worked fine.
- You need to be careful with your placement of crystals (you’ll at least need one ~13.333MHz one). The PJRC (Teensy) website has some good guidelines for this, on this page.
- There are some pins which you need to tie to either 3.3v or 0v to select a few options, including whether you want to boot from your external SPI flash memory (you very likely do). They are called MD_ BOOT0, MD_ BOOT1, MD_ CLK, and MD_ CLKS – look them up in the datasheet.
- The BSCANP pin should be tied to 0V to enable JTAG programming / debugging with the J-Link.
Just like Arduino, Teensy and PIC, programming is done in C or C++. For an IDE, Renesas makes their own modified version of Eclipse called e2 Studio, which is what I’ve used. It uses a GCC toolchain. The other option Renesas provides is a program called ARM DS-5, but I haven’t used it.
Download the installer for the RSK+. Make sure you get the version that includes e2 Studio rather than DS-5, unless you want to give that a try. The download will install e2 Studio and give you 10 or so example projects. It will also give you a very basic PDF “manual” for the setup, which will explain how to import the demo projects.
After importing the demo projects into e2 Studio, you should be able to run them on your RZ chip / board by connecting it to your computer via your J-Link, and clicking e2 Studio’s “debug” button. Hopefully, the code should compile, the debug perspective should open, and you should be able to step through the code as it runs on the RZ – just like any debugger.
It’s worth mentioning that all kinds of things can go wrong in e2 Studio. I’ve been using it for a couple of months and I still think it sometimes gets confused despite me selecting the correct options. For instance, most of the example projects have multiple run / debug configurations, called “HardwareDebug” and “Release”. I seem to have ended up in a situation a few times where (I think) the project is being “built” for one of the configurations, but then the debugger uses the other configuration, and consequently I can’t see the source code while debugging. And sometimes, no matter how much I fiddle with the options, I just can’t get a project out of this state. There are plenty of options relating to these configurations and to the debugger, so you’re going to have to use trial and error. If it’s not working, look at every option in the project’s properties, or maybe try another one of the example projects.
Most of the example projects relate to particular peripherals (e.g. a USB connection) which you may or may not have implemented in your PCB, so not all of them will be relevant. In any case though, if you can get the code to compile, and you can see it start to execute in the debugger, then you know that it’s working, so you can start changing the example code to do what you want for your own projects.
Using the example projects as a base to build my own programs on top of is the best way I’ve found to code for the RZ. e2 Studio does have an option to begin a “new” C or C++ project, and this does create you a project stub with a tiny bit of existing code, which you can successfully run using “debug”. Most of the example projects, though, contain some additional code (in the “compiler_specific” folder, much of it in assembly language) which sets a number of options for the RZ which make it run faster, allow interrupts, and more – all important stuff. I haven’t figured out exactly how to copy all of this functionality into a “new” project (it’s not straightforward), so I just build on top of the example projects. I also haven’t found a way to rename the example projects without getting build errors, so my own projects all have the names of the original example projects for the time being.
Another note: while the “debug” option in e2 Studio works, the “run” option gives me an error. The only way I can get my code to run on the RZ via my J-Link is with the “debug” option, which seems to be slower than ideal. Renesas’s tech support department gave me a cryptic answer to my question about this and didn’t seem to dispute that the feature wasn’t working as one would expect.
The example projects include code to perform most of the RZ’s core functions – UART, SPI, using individual pins for switches or LEDs, USB. This code is not presented in the same kind of user-friendly library form that you might be used to with Arduino or Teensy, though, so you can expect to have to poke around and modify things a lot.
There is also an SSI (Renesas’s name for I2s – audio output) example – not included in the RSK+ download, but in the sample code section of Renesas’s website. That one took some serious tweaking to get running though. I use a CS4344 DAC. You’ll need a dedicated audio crystal, too.
And, if you want to use SD cards, I recommend the FatFS library for handling the FAT filesystem. You’ll need to tie it to the RZ’s existing SPI “library” – for this connection, I modified FatFS’s example PIC24 implementation.
Hopefully (and if there’s enough interest) I’ll eventually find time to tidy up and release some of the “libraries” I’ve created myself from all of this example code.
Additional development quirks
- If you use C++, you’re going to notice a frustrating problem: globally declared object variables don’t get their constructors called. See this thread for a long description of the problem by me, and a confirmation from someone more experienced that Renesas’s C++ implementation isn’t as it should be here. I found a work-around though: manually call the constructors of all your globally declared object variables once your program is running, e.g.: new (&alreadyExistingObject) ClassName;
- The example projects’ linker scripts aren’t properly set up for dynamic memory allocation (that is, calling malloc() or new), but it can be fixed. The explanation is a bit long – leave a comment if you want to know how to fix this, and I’ll add it here. And speaking of linker scripts, any time you change yours, you have to tell e2 Studio to “clean” your project before you build it, otherwise your changes won’t take effect.
- Unbelievably, there seems to be no way to make a program “print” text out to the console in e2 Studio via the J-Link. Even Renesas’s tech support, when I asked them, said I’d need to use a USB serial connection. Currently, I’m obtaining a printout by having my RZ output text via a UART (non-USB serial) connection to an Arduino, which then relays the text back to my computer – clunky but it allows me to work.
- Among other build options for GCC that e2 Studio gives you access to, there is link-time optimisation. Unfortunately, selecting this option doesn’t work. I found a way to manually achieve it though – leave a comment if you’d like me to write up how to do it. It has only a surprisingly small effect on performance, though it does make my program 20% smaller.
Running your program from flash memory
Above, I outlined how to write to your external flash memory using either a J-Link or a FlashCatUSB. The actual file you want to put onto the flash memory is the .bin file that’s generated by building, and will be sitting in either your project’s HardwareDebug or Release folder, depending on what configuration you’re using.
Hold on though – simply writing that file to flash memory won’t make it run correctly when the RZ powers up. Most of the example projects have linker scripts which assume the program is being run from RAM. The linker script would need to be changed significantly if the program was to be run directly from SPI flash. The RZ_A1H_Tutorial_RSK project includes an alternate linker script which can be used for this.
However, you don’t really want your program to run from SPI flash, because this would be slow, so don’t in fact change your linker script. What you instead want is a bootloader which runs from SPI flash, then loads your actual program from SPI flash into RAM and then runs it from RAM. The example project called RZ_A1H_QSPI_LOADER does just this. You need to build it and write the generated .bin file onto your flash chip at address 0x000000. Then write your actual program’s .bin file at address 0x080000, which is where the bootloader will look for it.
There’s another step! The RZ_A1H_QSPI_LOADER likely needs to be modified slightly before you can use it with a board that’s not the RSK+. This bootloader assumes, among other things, that there are two SPI flash chips connected, which is likely not the case on your board. The most fool-proof way of making it work (probably at the expense of some speed) is to go into the file src/spibsc_init2.c and comment out lines 225 to 229 – the ones under the comment “==== Sets the SPIBSC ====”. I’m still trying to determine whether there’s a better way than this, but it should at least get it up and running.
Another reason to build on top of the example projects rather than creating “new” projects is that the example projects are configured (via assembly language located in compiler_specific/asm/start.S) to present certain information (such as the program’s size) to the RZ_A1H_QSPI_LOADER. The RZ_A1H_QSPI_LOADER in fact won’t load any program which doesn’t have this.
And if you’re wanting to create a product which allows your users to update their firmware at a later date, you could modify the RZ_A1H_QSPI_LOADER to include the ability replace the actual program (which, remember, begins at 0x080000) on your flash chip. For instance, I’ve created a variant which loads a new firmware version from a file on an SD card and overwrites the old version on the flash chip. Modifying RZ_A1H_QSPI_LOADER is quite tricky though, since the configuration of its linker script and the way it operates is quite complicated, so be prepared to troubleshoot.
Let us know how you get on. It would be great to see some more people developing innovative hardware using this very powerful microcontroller.