MK program the most different. These are the well-known stm, lattice, microchip, nuvoton, altera, etc. and exotic things like azoteq, silicon works or freescale of some 2003 release. All of them (well, almost all) develop their own protocol, unique, which no one else has and it is the very best. Although it is held under the slogan of the universal. And all this set of universal protocols pleases with its diversity. If there is an exaggeration here, it is quite a bit.
But this recent article prompted me to write here... Samples for different gd32 families just came to me and, having written programs for programming all lower families, I puffed over the RISC-V family. And I saw this article. Well, I thought, if someone is interested in retelling the datasheet, then the programming programming datasheet may also be interesting.
Younger families are programmed via JTAG and SWD (with minor exceptions, where there is only SWD.gd32f130xx, for example). gd32vf, on the other hand, only has JTAG. But JTAG or SWD is just a tool. Driving with these tools happens in very different ways. If you can read the ARM Debug Interface Architecture Specification about gd32f and everything is quite clearly described there, then about gd32vf is smeared in RISC-V External Debug Support and The RISC-V Instruction Set Manual. And these two works cannot be mastered with half a kick. The latter also has a subtitle Volume II. This alarmed. So there is also a pig with number 1 and possibly numbers 3 and 4.
According to RISC-V External Debug Support, access to the registers can be done in two ways:
- Using Abstract Command
- Using Program Buffer
To memory three:
- Using System Bus Access (GD32VF does not)
- Using Program Buffer
- Using Abstract Memory Access
Since the GD32VF does not have System Bus Access (the "system bus accesses are supported" bits in the sbcs register), and there is no joy in using a program buffer and writing assembler there, there is a very good way to get by with commands. At first it was completely incomprehensible to me where these damn clever guys get the number of the register (Number of the register to access). The description of the value regno proudly says: Number of the register to access, as described in Table 3.3.
But where exactly. But then I found them in the adjacent datasheet mentioned above (The RISC-V Instruction Set Manual. Volume 2) and the sun shone.
So it all worked. Everything really turned out to be more convenient than that of gd32f. From the point of view of pouring code into it. But that was only the beginning. Now I needed to write a monitor for it. To make it even faster than fast. IAR didn’t let me download my WORKBENCH from him, although he was bragging about it with might and main. I still haven't found a place to click and download. The Chief Chinese Manager who sent the samples said they were using NucleiStudio and I downloaded it and installed it. It seemed to me that the most inconvenient thing that I used was the rocker. I don’t understand how the bastards of the past carried water in it and then walked dry. I was wet to the top of my head. But NucleiStudio has outdone the rocker. In general, after much suffering, I managed to shove the data and function into the right places in memory. I'm sure you can do it more gracefully, but I was not enough.
It looks like this.
We need to find the original script (I found it somewhere in the bowels of this eclipse, whether it was wrong), which contains a bunch of incomprehensible scribbles and add a description of the necessary addresses there
. = 0x20000000;
.data_sect : { *(.data_sect) }
. = 0x20000400;
.a_sect : { *(.a_sect) }
. = 0x20000500;
.f_sect : { *(.f_sect) }Still, how much IAR's * .icf file looks much clearer and simpler! But this is a matter of habit, I guess. When I was looking for this unfortunate file, Google assured me all the time that there is nothing more powerful and stronger and cooler and more flexible than a link script. Perhaps, but I'm worn out. Anyway. Shoveled.
Now I just need to rearrange the PC and everything will work at a terrible speed. But the monitor still didn't work. And now the paragraph for which I started all this. Which will help future RISC-V-Miracle researchers.
Here he is.
To rearrange the PC, you just need to write its value into the dpc register, and then at the start of hart, the value will be copied to the PC. Up to this point, the program has already written and read a bunch of other registers. With great success, I must admit. And the monitor doesn't work. As it turned out, to write to dpc, you need to write there, and then read from there. Why this is so, I do not know. I read all the documentation again and "followed the fate of the heroes with excitement." But I never found why this is so.
After that, everything worked. The only inconvenience, to read something from memory, is to stop hart and then start it again. It's not very convenient, but not scary. For example, to find out how the monitor feels there and whether it has finished working, you need to stop hart, read the required memory and, if necessary, start again.
I hope that the paragraph on dpc will save someone a couple of hours of time and it will be possible to do nothing all this saved time.