Dennis, I understand your frustration, since I’ve been there too.
First, the HiFive1 board is an Arduino board. If you use it with the Arduino environment, you generally manage to upload your application and it runs as expected. As usual in the Arduino world, it generally does not allow customizations, the Arduino environment provides the startup, the linker scripts, the main code, the libraries, and generally everything.
Second, by design, the Arduino development does not allow debug, and there is nothing to do about this.
Given the above, the HiFive is a decently reliable Arduino board. Based on my experience, sometimes you might need 2-3 attempts to upload your application, but regardless how messed my board was, the Arduino environment always revived it.
However, if you try to use the HiFive1 outside the Arduino environment, well… your mileage may vary. 
I was probably the first embedded user to try complex development with the HiFive1 (while working on the Eclipse SiFive templates), and my conclusion was that the board is not usable; with code under development the board was bricked almost each time, and flashing it required booting to bootstrap and multiple attempts before succeeding.
In fact, after a while, I gave up, and I developed the templates using the E31-ARTY, which had a proper JTAG connector and I could use the J-Link.
The reasons for the board bricking are somehow complicated, but, based on my experience with the board, I would say that the following events happen:
- if the application is functional and running, everything is fine, you can generally reflash it
- if there is something wrong with the application, it generally throws an exception and hangs
- for reasons that I do not know, OpenOCD is not able to halt the board immediately after reset, so the board starts and hangs with an exception
- again for reasons I do not know, the debug code in OpenOCD does not seem able to get the board out of this hanged status
The usual/expected JTAG behaviour is that the debugger should be able to get full control of the debugged device, regardless the status reached, even with a faulty software. Unfortunately the RISC-V OpenOCD I used was not able to do this with the FE310 device; I reported this to SiFive, but I did not receive a good explanation.
A good question is why applications hang; well, in my case it was due to bugs in my under development code, which sometimes failed to start properly. Special attention must be observed to the startup code, to the linker script, and to the _sbrk() implementation, which depends on both; all can easily lead to hanged boards.
Another reasons for hanged devices, if you used the SiFive toolchain, is the mandatory inclusion of libgloss which implements system calls with ECALL; for example, if your application includes a printf(), but you missed to properly define _write(), the default call is implemented with an ECALL, which obviously fails. This problem was also reported to SiFive, but the toolchain configuration was not changed (the problem was fixed only in GNU MCU Eclipse RISC-V Embedded GCC).
As a conclusion, if you want to use the HiFive1 board, use the Arduino environment. My experience is that the board is generally not suitable for active development outside the Arduino development.
