The current OpenOCD code has some problems where it doesn’t always clean up after itself, and doesn’t handle all the cases when the previous OpenOCD session didn’t clean up after itself. If you can provide a specific set of actions that doesn’t work for you, we can try to reproduce it and make a patch to OpenOCD.
Steps to reproduce:
make software PROGRAM="$program" BOARD=freedom-e300-hifive1
make upload PROGRAM="$program" BOARD=freedom-e300-hifive1
screen /dev/ttyUSB1 115200
- reset hifive1 to check output of program
C-a \
to terminate screen
- modify the source code of the program being tested
- repeat
This is the development cycle I was following on episode 21, it does not fail 100% of the time, but it is pretty frequent/easy to reproduce.
This should not permanently harm your HiFive1 board. If you get into trouble, you can always double tap the reset button to get into safe boot mode as describe in the HiFive1 Boot Sequence in the getting started guide.
Awesome, that is great to know 
The Configuration String can be printed with the following code:
unsigned char * ConfigString = (unsigned char*)*(volatile uint32_t *) 0x0000100C;
write (STDOUT_FILENO, ConfigString, strlen(ConfigString));
The string is also documented in the SiFive-E310-G000 manual here. Hopefully they match
I’ll try that code on today’s episode, thanks! I was trying to do it like this:
char *config_string = 0x0000100C;
while (*config_string == 0x00 || *config_string == 0xff)
++config_string;
write(STDOUT_FILENO, config_string, strlen(config_string));
I’m not an expert when it comes to C, does it store the constant 0x0000100C in the read only data section and set the value of config_string to the address of that literal instead of assigning the value 0x0000100C to the pointer? Based on your code I take it that casting is my problem? Although it looks like you are de-referencing the pointer after the cast to volatile uint32_t and then casting that to a pointer… So wait, rather than the string living at or after 0x0000100C, 0x0000100C holds an address to the actual location of the string? I’m sure I’ll figure these questions out once I poke around with your code example today 
I’m not sure I understand the question?
I’m learning about the config string from the following document: PDF.js viewer
…but Hossein linked me this document: https://people.eecs.berkeley.edu/~krste/papers/riscv-privileged-v1.9.pdf
If you look at the document I was referencing, chapter 8 talks about a search procedure, whereas the document Hossein linked does not talk about a search procedure, but instead talks about syntax. I’m wondering what the deal is with the discrepancy between the documents? If the 1.9 draft is more recent than the standard one, does that mean searching for the string was scrapped? Or is 1.9.1 more up-to-date than that draft? (in which case, why doesn’t it detail the syntax of the string?)
Be sure to put the \n in your printf or to call fflush after. For example the following should work:
printf(“this is a test”);
fflush(stdout);
Thanks for the tip!
Yes you are correct. This include statement points to another location in memory where we have the option of placing more configuration information in the HiFive1 OTP memory. In the HiFive1 getting started manual you will see address documented in the OTP Contents section at offset 0x0004. At the moment, nothing is programmed here. I believe there will be more information on this in version 1.10 of the RISC-V Privileged spec.
Sweet, thanks for the info 