After executing the instructions (lui and addi) the a5 register contains always 0xffff86a0
and not 0x000186a0 as expected?
Using C++
What is wrong not getting 100.000 as integer?
Tool chain / IDE maybe - doubtful it is a chip problemā¦ but I donāt know what you might have done do your board 
Anyway, I tried on my red-v (and the hifive1_revb) and it is all good. I donāt use the eclipse IDE - personal preference leads me away from eclipse every time if there is a viable alternative.
Have you tried Visual Studio Code with the platformio extension installed?
Thank you very much for your evaluation effort!
- Because you have the same chip revision FE310-G002, I think the core is o.k. (good news
).
In case of doing a fast evaluation to verify how easy it is to work with a RISC-V core, it is not so easy:
-
Fact is using the out-of-the-box by SiFive released Eclipse IDE with compiler shall be the fastest way to evaluate something.
-
Bad is, if such a representative tool released by SiFive is not working proper.
As experimenter I will try your proposal with Visual Studio Code, but I fear to get my simple project with less effort running.
As professional I work in a huge company over years with ARM processors and I am very open for new solutions, but now I am very frustrated evaluating the RISC-V core:
- Official tool not working
- Additional I have bought the SiFive Learn Inventor (Pimoroni UK):
I have send SiFIve an EMAIL to get the schematic and the FE310-G003 data sheet and manual
ā> no response from SiFive
- SparkFun RED-V RedBoard :
I try to use the I2C interface (have bought many additional hardware for the QWIIC interface)
ā> mission impossible, no I2C software available in the HAL
Iāve used the zephyr OS and i2c with the hifive1_revb and red-v. It does work, but you have to enable CONFIG_I2C in your project to get CONFIG_SIFIVE_I2C (or CONFIG_I2C_SIFIVE I forget).
Agreed, Iāve been disappointed as well with the support on the freedom everywhere chip (at least on the forum - I havenāt tried other avenues). If youāve seen the movie āTraining Dayā - You gotta put your own work in around here, itās like that.
I get the feeling the microcontroller isnāt getting much support vs. the larger SOC efforts but that is just conjecture - which I get w.r.t. $
Thank you āaloeppertā, i will try your hint with zephyr OS code
Now some good news ā¦
knightsifive/SiFive-Learn-Inventor-Docs
ā¦ documents for the āSiFive Learn Invertorā board are now availableā. I am happy!
Problem with Eclipse environment solved:
Stepping through with the debugger to evaluate the variables is changing something.
If I let the code run I get the correct values printed:
Quick question, was this whole ā100000ā thing related to i2c speed?
100000 is the isolated example to figure out the problem.
I have started to write my own I2C driver class and one method should use the CPU speed as parameter to set the I2C speed divider.
Stepping into the method by single steps has shown that anytime the input variable is wrong. Have never thought the software break-point mechanism is the root cause. I have opened a support ticked to the Segger company (no reaction by SiFive telling this problem by EMAIL).
I hit a somewhat similar problem when trying to assign long values to long long values, and the high bits ended up being occupied by random uninitialized memory. These are 32-bit instructions and likely arenāt touching the high dword bits (and my attempts to zero this out were being optimized out by the compiler).
My guess here is that using the debugger is doing something different with memory and/or placing things elsewhere besides zeroād out memory.
It also doesnāt look like youāre reading register a5 itself, but the symbol address for your variables. I wonder if a5 has the correct result in it (you can do something like monitor reg a5 in gdb to read it directly, not sure if eclipse can execute raw gdb commands).
And I am curiousādoes Sifive have an official email contact? The only thing Iāve seen has been sales contacts which would not be able to handle technical issues. Iād guess theyād have email contact for those with support contracts, but otherwise it doesnāt seem the appropriate avenue for general support or issue reporting. Iāve had good luck with most of my GitHub issues and pul-requests so it may be an issue of finding the right project to report this against (and forums would be a good place to start here)
I had many times contact to the Segger company to get support. So I mean they will fix it soon. The support ticket is open, I got always fast responses and a forecast in which release it will be fixed.
This is the first time I worked with a Risc-V MCU. That a break point is not working I have never seen since years.
I was too optimistic as an eval board āevaluationā freak there is a new interresting MCU stuff. Paid much money for two eval boards. I call them James Bond boards (secret service, nobody shall know something). Now I know that the SiFive core has not been a good choice, if compared with other huge MCU vendors and the support which I do NOT need there! If I get documentation (I2C is secret), a basic HAL (I2C is secret) and a good schematic (Learn Inventor Board, MCU page is secret) I survive by myself.
@wkh SiFive does not yet offer email support for customers of our dev boards. For most discussions concerning our dev boards, these forums are the right place to ask questions and exchange ideas. I have shared your frustrations with the company and am optimistic that we will improve our response-times for questions/issues raised on these forums.
If youāre encountering an issue with the open-source software (freedom-studio, freedom-e-sdk, freedom-metal, etc.) maintained by SiFive, please consider raising an Issue (or better yet, a PR) on those GitHub pages, as @tincman suggests. If you do so, please prepare a reproducible example, with clear steps to reproduce.
Best,
Nick Knight
Technical Lead, Software Performance Team
I can see I2C info in the FE310-G002 manual (itās an OpenCores based device, thereās a link to the project which includes documentation and even the full VHDL, which seems very open to me) and I have seen other people using and working with it manually or through ZephyrOS, and it looks like support for it should be showing up in freedom-metal in the next release (https://github.com/sifive/freedom-metal/pull/188, current latest release was in August and this merged in October). The schematic for your RED-V board is provided by Sparkfun themselves, which makes sense as I would guess they designed and fabricated the board themselves.
Back to your issue, it may be a sign extension issue judging from the output. The LUI is also suspicious since Iād guess it should be LUI a5,0x0.
Iād be interested in taking a look at your source and disassambled output to see what may be going on.
EXAMPLE 1
SiFive Eclipse IDE for C/C++ Development
Version: 4.12.0.2019-08-2
Copyright Ā© 2016-2019, SiFive Inc. All rights reserved.
Segger (now) newest J-Link software V6.70 (has updated the on-board debugger, too):
Original sifive-hifive1-revb-hello code with tiny modification (any other code can be used, too).
The code has been execute with single steps line by line:
Single steps (maybe software breakpoints) are killing the initialization (?).
EXAMPLE 2:
Same code executed with run:
Segger has now got this example code. I have opened a support ticket there.
Other topic:
- Yes: SparkFun has a full schematic for the RED-V board
- Has never been a problem to get a schematic there.
I2C
- After 10 days contact with a RISC-V MCU I have never known how distributed information could be.
- After installing the professional looking SiFive Eclipse IDE I was thinking I will find everything inside (sorry).
- I will try now to pick the code from the GIT repository.
@wkh Please help us out and keep each forum thread to an individual topic! Otherwise itās hard for us to keep track of all the questions. You have already started a thread over at SiFive Learn Inventor Board - Documentation , letās have the āLearn Inventor Documentationā discussion over there.
I am able to reproduce that same assembly, and the lui does make sense now that I researched it moreāit sets the high 20 bits for 100000, then the addi adds the low 12 bits via the immediate value. My guess would be this combo is good for instruction compression and pipeline concurrency, but that is just a guess (if anyone does happen to know, Iād be very curious to find out).
Using gdb I can step and poke at the int value in memory and the a5 register and both contain the correct value (whether I do unsigned int or int for the value). Iāll try repeating this a few times to see if itās a transient issue or not.
@tincman lui+addi is the standard way of loading a general 32-bit constant into an X-register in RV32. For certain special constants, just one or the other suffices, but if you think about it, itās impossible to encode all 32-bit constants into 32-bit instructions: thereād be no encoding space left for the (actual) instructions!
An alternative is to place the constant in data memory at compile-/link-time and use lw to load it into an X-register when needed. At first glance, this may seem to require one fewer instruction than lui+addi. However, accessing an arbitrary address in data memory may take many more cycles than accessing the next instruction, which in typical implementations would have already been (pre)fetched. Moreover, the address of this constant (needed by lw) is itself a 32-bit constant, which we have to load into a register somehow ā¦ so weāre essentially back to where we started! (Itās a bit more complicated because lw takes a 12-bit immediate āoffsetā in addition to a register.)
1 Like
With the now available version of the J-Link software (V6.72d) the āsingle-step debug problemā is solved!
Note:
- I have triggered that āSeggerā is fixing the bug by opening a support ticket there (now fixed).
- It seems SiFive has no interest that the J-Link debugger is working proper.