There is one major difference: I am using Segger Embedded Studio for RISC-V, not Freedom Studio. If you are interested in trying out Segger Studio, go download it from Segger. It is free for non-commercial use. Make sure to get the RISC-V version, not the ARM version. The RED-V board contains an onboard Segger hardware debugger, accessed through the USB connection. Segger Studio knows how to work the RED-V debugger, and there is nothing special you have to do.
Start by installing Segger Embedded Studio. Start the program. I can’t remember if the initial startup of Segger Studio starts the package manager. If not, select “tools/Package Manager”. Scroll down until you see the SiFive section. Click on the package “HiFive1 Rev B Board Support Package”, and install it.
Important Note: The “HiFive RevB” board is quite similar to a SparkFun RED-V, but they are NOT exactly the same. However, it is close enough to get up and running, and start building and downloading software. They both use an identical processor and Flash/SRAM memory layout which is 90% of the battle.
Now you should be able to click open/solution. On my machine, Segger wants to store the solutions in my user directory, so for me I would navigate to “C:\Users\robin\AppData\Local\SEGGER\SEGGER Embedded Studio for RISC-V\v3\packages\HiFive1_RevB”. Inside that directory should be a file called “HiFive1_RevB_Samples.emProject”. Select that file.
You should see a couple of projects appear under a new solution. One of the projects is called “Blinky”. Left click <Project “Blinky”> to highlight it, then select menu item project/options. A dialog window will appear. Under the “build” section, you will see an option for “Memory Segments”. If you click “memory segments”, three dots “…” will appear at the far right of the option’s value. Click the dots to change the value for Memory Segments. I think the proper value should be “FLASH RX 0x20010000 0x1FFF0000;SRAM RWX 0x80000000 0x00004000”. This is telling the linker to build your executable so that it starts at address 0x2010000. This new address is required to avoid overwriting the bootloader located in the first 64K of flash.
As written, Blinky won’t do anything on a RED-V because the RED-V’s LED is wired up differently. The HiFiveB uses an RGB led, but the SparkFun RED-V only has a single blue LED. As a brutal hack to just make sure things work, edit the Blinky.c, and after all the include files have been included, add a define to override the definition of the blue LED for the HiFiveB to be on pin 5, which is where it is on a SparkFun RED-V:
include <stdint.h>
#include "platform.h"
#include "encoding.h"
#define BLUE_LED_OFFSET 5
Finally, you are ready to build. You should be able to build that project now by hitting F7, or click the build menu, and select “Build Blinky”. Once built, you click F5 (or select Debug/Go). The beauty of using Segger Studio is that you can be sure that it knows exactly how to use the Segger debugger that is built onto the RED-V board. Hitting F5 will flash your executable, and start it running. By default, Studio sets a breakpoint at the first line of main(), so the system should stop right there. Try hitting F10 a few times to single step main(). At any point, you can hit F5 (go), and the blue LED should start blinking. While the program is running and the LED is blinking, you can find scroll to the lines in Blinky.c that say:
// Toggle LED
GPIO_REG(GPIO_OUTPUT_VAL) ^= (0x1 << BLUE_LED_OFFSET);
Right click in the grey area just to the left of the source line that is toggling the LED, shown above. You should see a red breakpoint dot appear. If there is no code associated with the source line, the debugger will ignore your attempt to set a breakpoint. For example, if you click in the grey area to the left of the comment line, nothing will happen because comments don’t generate code. Once the breakpoint is set, the debugger will stop on that line the next time the interrupt occurs which should be within a second. You can then hit F10 to singlestep execution and watch the LED toggle.
Well, that’s what should happen in theory. I’ve tried to recreate these steps from memory, so they may not be exactly right.
Finally, your modified Blinky program is a nice starting point for writing code. However, we did lie to the Segger tool and told it that we were using a HiFive RevB board, so again, the peripherals outside of the CPU on that board (like the LEDs) are not identical to the RED-V. However, the overall memory map and all on-chip peripherals are completely identical because the processor and its external flash chip are both completely identical. This means that all of the HiFiveB startup code to get the processor set up for operation is pretty much exactly what you need, even for a RED-V. So this Frankenstein setup is not a perfect long-term solution, but it should certainly get you going.