Renesas RISC-V MCU FPB-R9a02G021 Fast Prototyping Board Road Test

View table of contents ...  

RoadTest: Review the 32-bit RISC-V Renesas Fast Prototyping Board FPB-R9A02G021

Author: jacky000

Creation date:

Evaluation Type: Evaluation Boards

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: None

What were the biggest problems encountered?: The debug interface was disabled after changing the startup code.

Detailed Review:

Introduction

This RoadTest review covers the following topics for Renesas Fast Prototyping Board FPB-R9A02G021. 

  • How to set the development environment for Renesas RISC V MCU
  • How to use the driver code generation tool, Smart Configurator
  • How to Build, Download, and Debug
  • How I failed!

The board is equipped with a RISC-V-based MCU, R9A02G0214CNE. The RoadTest page contains further information.
https://community.element14.com/products/roadtest/rt/roadtests/665/review_the_renesas_fast_prototyping_board_fpb-r9a02g021#pifragment-18971=4&pifragment-18972=7

Development Environment Setup

Initially, I tried using Renesas’s E2Studio, which supports Windows, Mac, and Linux. However, at the time of my RoadTest, the RISC-V was not yet supported for the Linux environment. So, the plan B for my Ubuntu 22.04 machine was Embedded Studio from Segger. They provide a free version for non-commercial use.

The next challenge was the driver code generator, Smart Configurator. It also supports only Windows. However, I could use it through WINE(https://www.winehq.org). It worked well except for a minor graphic glitch, but I had no issue using the tool for BSP configuration and generation. The tool also creates a project file for E2Studio, IAR workbench, and Embedded Studio. I was able to build the generated project immediately. 

The board has an onboard JTAG, jLink OB, which supports Embedded Studio natively. It also supports a standalone JTAG tool connection, but the connector pins are not assembled. The generated project has JTAG as a default interface, but this must be changed to cJTAG. You can change this from the project option window. The user interface was a bit confusing. You have to select your project first and then select Project > Options from the menu. 

[RoadTest Development Environment Summay]

  • Ubuntu 22.04
  • Segger Embedded Studio 8.10b
  • Smart Configurator (Installed on Ubuntu using Wine)
  • Debug Interface: jlink OB(OnBoard) - cJTAG

Test Project Configuration

When creating a new project in Smart Configurator, you must choose a device and toolchain. The board was already available and SEGGER RISC-V Toolchain was selected for the Embedded Studio.

The following components were used for the test.

  • CLock config: Used the default configuration
  • LED Control (GPIO): The default configuration was used. This provides GPIO configuration for LED’s on the board. 
  • Console (UART0): The configuration is very straightforward. However, one tip is to select the desired baud rate first and change the clock setting for the best bit timing accuracy. 
  • Interval Timer Interrupt: A TAU0 timer interrupt for the 1ms interval timer source.

After code generation, you will have a project file in the output path. The header files of the generated BSP are easy to understand, so a simple application was written below. This code keeps blinking the LED2 and sending a message over UART 0 every 500ms. Also, a timer interrupt occurs every 1 ms.  

#include "r_smc_entry.h"

int main(void)
{
    const char msg[20] = "Hello Element14.\n";

    // Setup UART0
    R_BSP_UART0_Start();
    // Setup Interval Timer
    R_BSP_TAU0_0_Create();
    R_BSP_TAU0_0_Start();

    while(1)
    {
        /* Toggle LED status */
        PIN_WRITE(LED2) = ~PIN_READ(LED2);

        R_BSP_UART0_Send(msg,17);

        /* Delay 500 milliseconds before returning */
        R_BSP_SoftwareDelay(500, BSP_DELAY_MILLISECS);
    }

    return 0;
}


FAILURE!!!

After having these essential embedded software components, I tried more challenging tests. Unlike the other MCU families, this device did not support RTOS, so I explored RTOS for this target. Segger has embOS for RISC-V, and FreeRTOS does, too. However, no port for the Renesas target was available. The required porting job was around the trap/interrupt hander part, as the generated code from Smart Configurator was quite different from what the two OS ports used.
While browsing the tool, I found an interesting option about the Startup code selection. I changed it to “Disable”. I thought it allowed the startup code of Embedded Studio instead.

After generating the code, I built it and flashed it. Of course, the code did not work as I intended.
The real problem was that I could not connect jLInk anymore after a reset. It was a surprise, as there was no warning with this option. I could not find the root cause, but it might be related to the security ID related to the debug option. But it’s not quite ordinary compared to my experience with other MCUs. I tried to use the serial bootloader for flashing, but it declined further operations with an error message. I looked up the FAQ and manuals, but the effort was unsuccessful.

Conclusion
My ambitious RoadTest journey ends here due to one configuration option. I don’t have enough data points to provide a balanced evaluation. The initial setup was speedy and straightforward. I could easily use the board and tools, so any actual project would have the same benefits as I did. The RTOS support or other ecosystems can be improved. Lastly, the tool should have an ample warning on the Startup Select option.

Anonymous
  • Hello jacky000,

    the BSP startup code includes option memory configuration bytes where among other MCU system relevant things, the IDCODE is stored. This is an authentication password for the programming interface, and the Jtag connection. Typically you would care of this only for last steps before production.

    image

    so when you disable the tool's BSP, you would have to allocate that yourself, in your code.

    image

    Default setting is 0xFF as for unprogrammed flash, but if you miss to include that reserved structure in your own BSP, you risk bricking the device.

    Good feedback about the warning when disabling the BSP. Please note that all supported IDEs are defining the ".option_osis" section, and the linker script makes space for it, but it's missing some way toa catch-all structure which always defines such section in flash, to avoid missing it.

    As for your problem, if you have still the original unmodified image you flashed, you could try the following: inspect the hex file and check for the 0x800 to 0x80F content (this is the OSIS area, see hw manual).

    If you are lucky and the first bit (OSIS bit 127) is by chance not zero, you can use that content to authenticate to the board either with Renesas flash programmer (see FPB manual for proper jumper settings) or in the e2studio debug settings (if SECS.OCDDI is also not zero).

    Then you might be able to erase the chip. In e2studio try downlaod the standard blinky w/o modifications.

    If bit 127 of OCDDIS is 0, then bad luck - the programming interface is locked down, unfortunately.

    As mentioned, those settings are normally used in production so during development you can safely ignore them, but the OSIS pitfall shall be highlighted more or get a better 'safety net' when the user disables the BSP.

    Nevertheless, hope this helps!