RISC-V microcontrollers from GigaDevice - Page 1
Forum section: electronics / general

author: oPossum
author_rank: Super Contributor
timestamp: August 24, 2019, 03:01:19 am
content: https://www.cnx-software.com/2019/08/23/gigadevice-gd32v-risc-v-mcu-development-board/amp/The new GD32VF103 series RISC-V MCU family features 14 models with the following key specifications:Core – GD32VF103 RISC-V “Bumblebee Core” @ 108 MHzMemory – 8KB to 16KB SRAMStorage – 16KB to 128KB flashPeripherals – USB OTG and CAN 2.0BI/O – 3.3V, 5V tolerantSupply Voltage – 2.6 to 3.6VPackage – QFN36, LQFP48, LQFP64, and LQFP100 packagesMay be pin compatible with STM32F100 series.

author: ataradov
author_rank: Super Contributor
timestamp: August 24, 2019, 03:29:26 am
content: That sounds lire the first actually usable RISC-V MCU.Would be nice to have dev kit available from sellers on more approachable platforms. I would definitely get one.

author: ebclr
author_rank: Super Contributor
timestamp: August 24, 2019, 03:39:30 am
content: "Would be nice to have dev kit available from sellers on more approachable platforms. I would definitely get one."many availablehttps://gd32.tmall.com/category.htm?spm=a220o.1000855.w4010-18883888930.2.3a7b676eMpeEuQ&search=y

author: ataradov
author_rank: Super Contributor
timestamp: August 24, 2019, 03:42:46 am
content: Yeah, but you need to read Chinese. And probably give them your credit card. And I'd rather not.Hopefully someone will sell them on eBay or Aliexpress.

author: bilibili
author_rank: Newbie
timestamp: August 24, 2019, 01:50:16 pm
content: here is link ofdatasheetandSDKBumblebee_Core_DocGD32VF103_User_Manual_EN_V1.0.pdfGD32VF103_Datasheet_Rev1.0.pdf

author: bilibili
author_rank: Newbie
timestamp: August 24, 2019, 01:59:27 pm
content: RISC-V CPU target for embedded applications that require low energy consumption and smallarea, which is compliant to RISC-V architecture with several efficient micro-architecturefeatures, including simple dynamic branch prediction, instruction pre-fetch buffers and localmemories. It supports 32 general purpose registers (GPRs) and fast multiplier forperformance/area tradeoff:RISC-V compliant little-endian RV32IMAC (32GPRs) ;Configurable 2-stage pipeline optimized for low gate-count and high frequency;Machine (M) and User (U) Privilege levels support;Single-cycle hardware multiplier and Multi-cycles hardware divider support;Misaligned load/store hardware support;Atomic instructions hardware support;Non-maskable interrupt (NMI) support;Dynamic Branch Prediction and instruction pre-fetch buffers to speed up control code;State-of-the-art micro-architecture design to tradeoff area and performance requirements;WFI (Wait for Interrupt) support;WFE (Wait for Event) support;Interrupt priority levels configurable and programmable;Enhancement of vectored interrupt handling for real-time performance;Support interrupt preemption with priority ;Support interrupt tail chaining;Standard 4-wire JTAG debug portSupport interactive debug functionalitiesSupport 4 triggers for hardware breakpoint

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 24, 2019, 01:59:58 pm
content: Would be nice to have models with more RAM too.

author: hansd
author_rank: Contributor
timestamp: August 24, 2019, 02:14:06 pm
content: Quote from: bilibili on August 24, 2019, 01:50:16 pmWhere can you buy the evaluation boards?

author: GromBeestje
author_rank: Frequent Contributor
timestamp: August 24, 2019, 10:10:22 pm
content: Quote from: hansd on August 24, 2019, 02:14:06 pmIt seems at the moment only on the Chinese market, so to get it elsewhere you'll need a service like yoybuy.com

author: ebclr
author_rank: Super Contributor
timestamp: August 25, 2019, 12:20:25 am
content: why you trust eBay and don't Chinese stores, there is much secure than in us, crime there is the death penalty, and you can use Paypal, You are kidding about can't read Chinese in today's world you can read any language, with few keystrokes. The Chinese online stores ( Alibaba group ) are much more reliable than eBay, any seller is required to make a huge deposit just to solve future claims, The risk is much lower

author: Monkeh
author_rank: Super Contributor
timestamp: August 25, 2019, 01:26:38 am
content: Quote from: ebclr on August 25, 2019, 12:20:25 amOh my, that's hilarious on so many levels..QuoteIf it were that easy your English wouldn't be so awful.There are those of us who don't wish to spend three hours figuring out what's happening on a website half in the wrong language and half extraordinarily poorly translated by machine, just to order some cheap parts. And we don't accept that random stores in another country are secure when said country is rife with crime from the top down.

author: wilfred
author_rank: Super Contributor
timestamp: August 25, 2019, 02:17:16 am
content: Quote from: Monkeh on August 25, 2019, 01:26:38 amA bit of self moderation is in order when making comments like this.

author: Monkeh
author_rank: Super Contributor
timestamp: August 25, 2019, 02:27:15 am
content: Quote from: wilfred on August 25, 2019, 02:17:16 amIt was not intended to be nasty, only to make a point.If automatic translation was reliable, one would not need to learn other languages - you'd just use a translator.I apologise for any feelings hurt.

author: westfw
author_rank: Super Contributor
timestamp: August 25, 2019, 03:42:52 am
content: I trust AliExpress over eBay, for tech stuff.(After all, afaict, eBay is usually some less-technical reseller selling AliExpress goods, anyway.?)I’m not willing to order from a site where I can’t accurately read the language, though.Either these chips will show up on a more monolingual-friendly site, eventually, or they’re not worth the trouble. If Baite, or one of the other cluefull vendors starts selling them, I’m in!

author: hansd
author_rank: Contributor
timestamp: August 25, 2019, 04:34:22 am
content: Either these chips will show up on a more monolingual-friendly site, eventually, or they’re not worth the trouble. If Baite, or one of the other cluefull vendors starts selling them, I’m in!Segger supports them in their RISC V Embedded Studio.

author: emece67
author_rank: Frequent Contributor
timestamp: August 25, 2019, 11:28:26 am
content: .

author: bilibili
author_rank: Newbie
timestamp: August 26, 2019, 04:12:19 pm
content: GD32VF103C-START70RMB/10$ including onboard debugger

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 26, 2019, 04:23:03 pm
content: Quote from: ataradov on August 24, 2019, 03:42:46 amDoesn't your credit card company give you the option of generating one time use numbers? Mine does, and I always use this when ordering something from a potentially dodgy site on the Internet. My CC company lets me generate a one-time number with a fixed credit limit (I usually set it to $1 higher than whatever I'm ordering) and an expiration date of next month.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 26, 2019, 04:27:15 pm
content: Quote from: wilfred on August 25, 2019, 02:17:16 amOh, yes, I forgot... Political correctness trumps all these days. My bad.Frankly, I'm glad to see someone (Monkeh) call a spade a spade.

author: emece67
author_rank: Frequent Contributor
timestamp: August 26, 2019, 10:05:03 pm
content: .

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 26, 2019, 10:10:28 pm
content: Is the "F103" codename pure coincidence though?

author: lucazader
author_rank: Regular Contributor
timestamp: August 26, 2019, 10:18:29 pm
content: Quote from: SiliconWizard on August 26, 2019, 10:10:28 pmNope.Another product line that they have released in the past was the GD32F103. And these were basically pin for pin compatible with the STM32. And they were also mostly register and binary compatible, with a few exceptions...

author: thm_w
author_rank: Super Contributor
timestamp: August 26, 2019, 10:19:41 pm
content: I checked the LQFP48 pinout and it matches up, so theoretically you can drop this thing into an existing board design for STM32F103, once you figure out the code of course.This is really smart, first the F103 clone for a lower price to build trust/brand, then this. AFAIK there haven't been any major issues with that design, but I don't know if anyone has done in depth characterizations.

author: westfw
author_rank: Super Contributor
timestamp: August 26, 2019, 10:22:26 pm
content: QuoteI've never heard of such a capability! Sounds neat.Who is "your credit card company"?Edit: Hmm:Capital One, Citi, Bank of America offer disposable card numberson*some* cards...

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 26, 2019, 10:45:57 pm
content: Quote from: thm_w on August 26, 2019, 10:19:41 pmDoes it have a similar set of peripherals as well?Yeah, I guess if a company is producing millions a year of devices using a STM32F103, they could justify the time investment in porting the software to this new chip, and then it would just be a matter of changing a single item in the BOM...Not very fair to STM, but hey. Who said business was fair, right?

author: thm_w
author_rank: Super Contributor
timestamp: August 26, 2019, 11:05:17 pm
content: Quote from: SiliconWizard on August 26, 2019, 10:45:57 pmYeah the peripherals are almost identical, at least for what I looked at, ADC for example (12-bit same sampling times, etc).There is an opportunity to improve the peripherals (they did bump up the clock speed), but I think that makes things overly complicated, and the vast majority of people buying the chip don't care. Maybe they will come out with another model in the future though.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 26, 2019, 11:08:17 pm
content: Quote from: westfw on August 26, 2019, 10:22:26 pmCiti.Another use for them is when buying something that has an auto-renewal "feature". I've been burned by these in the past, as they're sometimes hidden in the small print, so now I just set the expiration date for the virtual card number to next month, and any auto renewal will fail.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 27, 2019, 02:47:27 am
content: Quote from: SiliconWizard on August 26, 2019, 10:45:57 pmThat illustrates a problem for any traction.If the MHz is the same, and the peripherals are the same, then it is only price thatmightselect RISC-V, and I doubt any large company will move to/risk a single-source part, for a few cents saving.To get traction in RISC-V, you really need to offer something extra, as a motivator.Is Gigadevice 'Chinese enough' to win favours in China, over ARM ? - I notice Softbank sold ARM china recently, and certainly China would be keen to avoid sending any license fees off-shore ?

author: ataradov
author_rank: Super Contributor
timestamp: August 27, 2019, 02:50:06 am
content: It eventually will offer lower price due to better licensing. And after that it might offer custom instructions.This is literally the first real MCU with this core. This is good enough for now.I would really like to get my hands on both dev kits. But I'm with others - I want an ordering firm in a language I can read.

author: oPossum
author_rank: Super Contributor
timestamp: August 27, 2019, 02:53:43 am
content: Quote from: PCB.Wiz on August 27, 2019, 02:47:27 amAlso...Higher IPCBetter code densityLower mW/MHz

author: ebclr
author_rank: Super Contributor
timestamp: August 27, 2019, 05:11:28 am
content: While those afraid of everything are making complains, I'm playing with my developer board bought from China in Chinese ( I'm smart enough to use google translator and understand ), paid with Paypal with my one-time card.I hope they understand how limited they areI guess no one of those was never been in Shenzhen to understand what is going on, and how obsolete they are

author: brucehoult
author_rank: Super Contributor
timestamp: August 27, 2019, 05:21:58 am
content: Quote from: SiliconWizard on August 26, 2019, 10:45:57 pmCertainly would be cool if the peripherals are compatible and anyone who wrote their stuff in C pretty much only has to do a recompile.

author: brucehoult
author_rank: Super Contributor
timestamp: August 27, 2019, 07:04:28 am
content: Quote from: blueskull on August 27, 2019, 06:04:22 amI believe Zephyr and FreeRTOS are both in pretty good shape for RISC-V. Of course you need a little porting work for each chip/board.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 27, 2019, 05:03:18 pm
content: Quote from: PCB.Wiz on August 27, 2019, 02:47:27 amI don't quite agree with that. Using STM is also having a single-source solution.Whereas the "risk" may not be worth it for a typical western company, I think it can be well worth it for a chinese one.Don't forget that those chinese chips are MAINLY designed to address the chinese industry and help it become fully independent, not to please the western world.Quote from: PCB.Wiz on August 27, 2019, 02:47:27 amFor a typical western company, again, I'd agree with you. Not necessarily for a chinese one.Quote from: PCB.Wiz on August 27, 2019, 02:47:27 amI don't know about Gigadevice as a whole, but any chip designed in China and not depending on any non-chinese IP is probably enough to win favours in China at the moment.

author: hansd
author_rank: Contributor
timestamp: August 27, 2019, 11:35:42 pm
content: Here is an other onehttps://www.sifive.com/boardsHiFive1 Rev B. Only 16KB of ram. And the Vega boardhttps://open-isa.org/with 4 cores

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 27, 2019, 11:56:46 pm
content: Quote from: hansd on August 27, 2019, 11:35:42 pmThat's unusual, it has a NXP logo, and claims to have a foot in both camps, with ARM and RISC V cores. RF support and BGA with large memories (1.25MB Flash 384k RAM )However, even with a Nov 2018 NXP data sheet download, a search on NXP.COM for RV32M1, finds nothing at all ?

author: hansd
author_rank: Contributor
timestamp: August 28, 2019, 12:04:32 am
content: It must have been initiated by Freescale as and experiment?https://mcuoneclipse.com/2019/03/16/running-freertos-on-the-vega-risc-v-board/https://mcuoneclipse.com/2019/03/05/debugging-the-rv32m1-vega-risc-v-with-eclipse-and-mcuxpresso-ide/

author: coppice
author_rank: Super Contributor
timestamp: August 28, 2019, 12:16:11 am
content: Quote from: PCB.Wiz on August 27, 2019, 11:56:46 pmThat device makes huge sense. The core is only a few percent of the die on a chip like that. Adding a second core lets them dip a toe in the RISC-V waters cheaply, while having a ARM core that ensures market acceptance. Making a complex chip with only a core whose market acceptance is unproven is risky. Making a simple chip with the unproven core means it won't do enough to attract much of an audience.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 28, 2019, 12:23:27 am
content: Quote from: coppice on August 28, 2019, 12:16:11 amYes, I agree it is a clever approach. Given the large Flash and RAM, and Peripherals, the cores will be relatively small % of area.

author: langwadt
author_rank: Super Contributor
timestamp: August 28, 2019, 12:53:19 am
content: Quote from: blueskull on August 27, 2019, 06:04:22 amARM is from the UK

author: langwadt
author_rank: Super Contributor
timestamp: August 28, 2019, 01:34:39 am
content: Quote from: blueskull on August 28, 2019, 01:03:23 amSoftbank is Japanese and ARM is headquartered in the UK, How much stock does Apple own in ARM?

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 28, 2019, 02:15:44 am
content: Quote from: langwadt on August 28, 2019, 01:34:39 amProbably not a lot these days. Fun fact: ARM was originally started as a joint venture between Acorn Computers, Apple, and VLSI Technology.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: August 28, 2019, 06:06:44 am
content: Quote from: coppice on August 28, 2019, 12:16:11 amThese multi-core, multi instruction set franken-monstrosities don't appeal to me at all. TI has something like this in the AM574x sitara.Which has, count em,2 Arm Cortex A15, 2 C66x DSP, 2 cortex M4, 2 PRU's and a partridge in a pear tree! Just Crazy.Each different ISA requiring a different compiler and tool chain. who needs that complexity headache.I see at least 4 market segments where RISC-V has a unique value proposition.1. Very low cost high volume commodity controllers where the ARM licence cost is a dead weight and every penny counts.2. companies like Western Digital who have high volume internal needs and want to be free from ARM licencing control and cost.3. commodity manufactures who want to be immune to capricious changes in export law/sanctions4.High security PC applications and server market, those that want to be free from back-doors like Intel's management engine

author: brucehoult
author_rank: Super Contributor
timestamp: August 28, 2019, 07:46:16 am
content: Quote from: chickenHeadKnob on August 28, 2019, 06:06:44 amI'd say you missed a few.1. anything where a custom instruction tightly integrated into the processor (i.e. take one or two register values, compute something, write the result to a register, all in 1 clock cycle) can significantly improve performance and energy efficiency on some task. ARM won't allow you to do that at any price. A coprocessor or memory-mapped device are the best they'll allow. This is ARM policy rather than physics or mathematics, so they could choose to change this.2. anything that wants a microcontroller level of area / performance / energy consumption but wants 64 bit addressing, for example because you're an I/O controller in the corner of a bigger chip. ARM doesn't offer small 64 bit cores comparable to Cortex M0 or even M3. Again, this is more policy than anything, though they'd also want to define a subset of Aarch64, which is not currently allowed. RV64I cores can be very small -- and there seems to be demand for RV64E (16 registers only) also.3. anything that wants 64 bit with code density comparable to Thumb2. Aarch64 code is much bigger than Thumb2 (though smaller than original ARM). This is hard to fix. There is insufficient room in the A64 encoding to add on 16 bit opcodes so you'd need either an awkward mode change as with original Thumb, or else an entirely new instruction encoding. MIPS, incidentally, seem to have done a good job of this with NanoMIPS which has 2, 4, and 6 byte instructions and both 32 bit and 64 bit. It looks to be virtually stillborn though, with only a single 32 bit chip announced 15 months ago, and no inclusion in their Open Source offering.

author: coppice
author_rank: Super Contributor
timestamp: August 28, 2019, 11:45:12 am
content: Quote from: chickenHeadKnob on August 28, 2019, 06:06:44 amI agree with you about some of the weird mixed core chips on the market, requiring a variety of software tool chains and other complexities. However, the NXP chip is designed as an either/or device. You can choose which core to use, and completely ignore the other one. Its completely benign.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 28, 2019, 03:02:18 pm
content: ARM has design centers in the US and other countries that are part of NATO, so many ARM IPs, partly or as a whole, have been designed in those. That alone can enable the US to set the rules when it comes to dealing with "unwanted" countries.

author: brucehoult
author_rank: Super Contributor
timestamp: August 28, 2019, 04:15:17 pm
content: Sipeed are releasing a $4.90 board called the Longan Nano using this GD32VF103CBT6 chip. Board and chip specs in English and SDK are all here:http://dl.sipeed.com/LONGAN/Nano/Orders here:https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.htmlGood reliable company. Many here will already be familiar with their boards using the Kendryte K210 RISC-V chip.They say the chip has 32 KB SRAM (double the largest mentioned in the first post in this thread), and 128 KB Flash.The standard SDK is Eclipse-based, but they are also supporting PlatformIO, which is now sponsored by SiFive and Western Digital making the full version with debugging free for everyone (not only RISC-V users).

author: nctnico
author_rank: Super Contributor
timestamp: August 28, 2019, 05:09:11 pm
content: Quote from: PCB.Wiz on August 27, 2019, 11:56:46 pmThe layout of the documents looks exactly like the documents from Freescale. This is very interesting because it may hint NXP is working on a new breed of non-ARM microcontrollers and maybe even SOCs.

author: brucehoult
author_rank: Super Contributor
timestamp: August 29, 2019, 06:41:55 am
content: A story on the Longan Nano here, although I don't think there's any new info:https://www.cnx-software.com/2019/08/29/longan-nano-gd32v-risc-v-development-board-comes-with-lcd-display-and-enclosure/And apparently the "Bumblebee" core is actually Andes N22. There's a story here:https://www.cnx-software.com/2019/08/28/andescore-n22-risc-v-core-rv32imac-rv32emac-instruction-sets/This story doesn't seem to quite match the Gigadevice/Sipeed docs, for example the Sipeed docs say that PMP (Physical Memory Protection .. basically a set of several base&bound registers so you can detect things such as stack overflow or protect machine mode things from user mode code) is not implemented.

author: mac.6
author_rank: Regular Contributor
timestamp: September 01, 2019, 05:16:08 pm
content: Quote from: hansd on August 27, 2019, 11:35:42 pmRV32M1 is not a true 4 core, it's 2+2, ie you use either ARM CM4/CM0+ or RI5CY/ZeroRISCY pair (and I think ARM/RISC-V hybrid also).

author: brucehoult
author_rank: Super Contributor
timestamp: September 12, 2019, 05:05:15 am
content: Just had a short conversation with Sipeed on twitter. They've just received the 2nd batch of 1000 Longan Nano boards, they have over 3000 ordered. The next batch is going to be about three or four weeks away -- which ties in with the delivery date on my order being October 9.They said once they've caught up on board orders they'll be making the bare chips available too.

author: coppice
author_rank: Super Contributor
timestamp: September 12, 2019, 11:45:11 am
content: Quote from: brucehoult on August 29, 2019, 06:41:55 amThey arrived just in time for longan season.

author: mac.6
author_rank: Regular Contributor
timestamp: September 16, 2019, 01:57:45 pm
content: Quote from: brucehoult on August 29, 2019, 06:41:55 amI have sources in China that says gigadevice is using Nuclei RISC-V IP and not Andes. Look athttps://www.riscv-mcu.com, FPGA page refers to Nuclei.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 16, 2019, 02:47:19 pm
content: Anyway, it's always nice to see new RISC-V entrants, but I personally don't care much for those small/borderline copycat MCUs (except for the core). Not my thing nor my needs at all. Of course they cover a significant market, just not mine.I would like to see more of completely original, and a little more powerful RISC-V MCUs (such as the ones SiFive provides, but with more off-the-shelf variants).The Kendryte initiative was pretty interesting. I got unfortunately disappointed with the lack of documentation and support.What I would personally be interested in:- Ultra-low power RISC-V MCUs. There are some that are reasonably low-power now, but still can't compete with ARM-Cortex-based ULP MCUs, and often by far,- On the other end of the spectrum, beefier (but with still reasonable power consumption) ones, like in the 200-400 MHz range, and a sensible set of peripherals,- And the absolute ideal: either of the above, but with additional reconfigurable logic blocks (such as a limited number of slices of a typical small FPGA)!

author: brucehoult
author_rank: Super Contributor
timestamp: September 16, 2019, 05:05:08 pm
content: Quote from: mac.6 on September 16, 2019, 01:57:45 pmIt's right there in the datasheet P14:"Note: The Bumblebee core used for this MCU is jointly developed by Nuclei System Technologyand Taiwanese Andes Technology, and Nuclei System Technology provides authorization andtechnical support services.At present, Nuclei System Technology can license the mass-proven N200series of ultra-low-power commercial processor cores, as well as research a variety of highperformance embedded processor series, and provide customers with customized services."http://dl.sipeed.com/LONGAN/Nano/DOC/Bumblebee%20core%20intro_en.pdf

author: ale500
author_rank: Frequent Contributor
timestamp: November 09, 2019, 11:58:23 am
content: I ordered a couple of longan nano board from aliexpress as soon as I saw that they were available. Let's see when they show up...Regarding the sw, the longan ide installer seems to include platformio, the compiler (so no need to install it extra... ) I already have vs code installed... I just wonder what is lightweight about this vs code...

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: November 09, 2019, 06:26:52 pm
content: Note - although this works on PlatformIO - it doesn't work on a Mac. You'll need Windows.I ordered my Longan nano withe little LCD for a fiver. It took a while to find out how to drive the LCD, I found this helped:https://github.com/Kevin-Sangeelee/gd32v_test

author: hansd
author_rank: Contributor
timestamp: November 11, 2019, 02:12:11 pm
content: A new toyIt never stops.https://www.seeedstudio.com/SeeedStudio-GD32-RISC-V-Dev-Board-p-4302.html

author: GromBeestje
author_rank: Frequent Contributor
timestamp: November 11, 2019, 02:27:45 pm
content: Oooh! new toys. But I've got to get my "Sipeed Longan Nano" running yet. I can connect to it using JLinkExe, but I haven't managed to get OpenOCD connecting to it.

author: hansd
author_rank: Contributor
timestamp: November 11, 2019, 03:19:38 pm
content: Which probe are you using with OpenOCD? It works with JLink.

author: GromBeestje
author_rank: Frequent Contributor
timestamp: November 11, 2019, 06:15:35 pm
content: I have an J-Link EDU Mini, and it works with the Seggers JLinkExe tool. At least I've tested connecting, halting, resetting and dumping the flash.The problem with OpenOCD is probably that I need to find out what configuration file I need. I'm using a git build from the official repository. I've been able to connect, and it reports it recognised 1 hart, but it doesn't reset/halt. And once I got the core working, I also need to figure out the flash.

author: trailp
author_rank: Newbie
timestamp: November 13, 2019, 07:31:34 am
content: hi folksI received a few Lonan-Nano devices a few weeks ago.I am using Linux, a text editor, Makefile and the installed DFU bootloaderThe example code and firmware driver code is quite well laid out andseems to have an examples for all the peripherals and a most of thecapabilites of the peripherals. The SDK seems to be Eclipse basedbut that is not my cup of tea.One thing that caught me out was that you need a modified 'dfu-util'program to suppoet this chip (at least for Linux). See this forkhttps://github.com/riscv-mcu/gd32-dfu-utilsI did a pin-toggle speed test and with some unravelling of the examplecode 27 MHz can be done in a while loop with the default 108 MHz systemclock. (Might be possible to do 54 MHz but my inline assembly is notdoing it yet - should be just one line if it is possible)ADC, DAC, USART, DMA, timer - so fae everything seem to workAt the moment I am having issues getting printf working properly. Aftertesting and some thought, I feel the problem is likely to be that I an idiot.cheersphil

author: ale500
author_rank: Frequent Contributor
timestamp: November 24, 2019, 07:35:06 am
content: I got my boards a few days ago. I did not order a specific programmer because I though with the JLink I could connect. My HW Version is 9.3 (I have the EDU version) and I updated to the latest software (6.56). When I try to connect via Jlink commander, I get a "this J-Link does not support RISCV over JTAG" and it outputs the following through the console:Code:TotalIRLen = 10, IRPrint = 0x0021JTAG chain detection found 2 devices:#0 Id: 0x1000563D, IRLen: 05, RV32#1 Id: 0x790007A3, IRLen: 05, Unknown deviceDebug architecture:RISC-V debug: 0.13AddrBits: 7DataBits: 32IdleClks: 7Memory access:Via system bus: NoVia ProgBuf: Yes (2 ProgBuf entries)DataBuf: 4 entriesautoexec implemented: YesDetected: RV32 coreCSR access via abs. commands: NoConfigTargetSettings() startConfigTargetSettings() endTotalIRLen = 10, IRPrint = 0x0021JTAG chain detection found 2 devices:#0 Id: 0x1000563D, IRLen: 05, RV32#1 Id: 0x790007A3, IRLen: 05, Unknown deviceCannot connect to target.It offers though two other variants SWD and cJTAG, via SWD says:Code:Device "GD32VF103CBT6" selected.Connecting to target via SWDConfigTargetSettings() startConfigTargetSettings() endConfigTargetSettings() startConfigTargetSettings() endConfigTargetSettings() startConfigTargetSettings() endConfigTargetSettings() startConfigTargetSettings() endCannot connect to target.J-Link>Assuming the SWD is the same as in the ARM variant, SWDIO (pin 7 of the JLInk connector) should be connected to JTMS (on the target side) and SWCLK (pin 9) should be connected to (TCK on the target side).cJTAG says:Code:Selected interface (cJTAG) is not supported by the connected probe.@: GromBeestjeHow did you get it to connect ?

author: mac.6
author_rank: Regular Contributor
timestamp: November 24, 2019, 08:39:20 am
content: Debug subsystem is not the "standard" sifive implementation, you I guess you need to use software provided by GD.

author: hansd
author_rank: Contributor
timestamp: November 24, 2019, 01:28:34 pm
content: You need J-Link HW version 10+ unfortunately. I have the EDU 10.1 and use Segger Embedded Studio with good results.

author: westfw
author_rank: Super Contributor
timestamp: November 25, 2019, 06:54:55 am
content: QuoteWhat? Why? I thought JTAG was JTAG, and it was only a matter of software whether you could program a given device?

author: ataradov
author_rank: Super Contributor
timestamp: November 25, 2019, 06:57:47 am
content: Quote from: westfw on November 25, 2019, 06:54:55 amI don't konw about this specific case, but Segger really likes to hard-code device IDs into their firmware on limited versions of the hardware (like EDU, SAM-ICE).

author: iMo
author_rank: Super Contributor
timestamp: November 25, 2019, 09:07:49 am
content: Platformio lists the compatible programmers:https://docs.platformio.org/en/latest/boards/gd32v/sipeed-longan-nano.html#uploading

author: hansd
author_rank: Contributor
timestamp: November 25, 2019, 12:18:08 pm
content: Have a look athttps://riscv.org/specifications/debug-specification/I tried GNU MCU Eclipse plugins and they didn't work all the time. The Segger setup works and is free and fast (except the edu) for non commercial use. The best is it works all the time. Downloading code can also be done via the GD32 DFU tool. I am sure over time there will be more support.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: November 25, 2019, 12:26:38 pm
content: Quote from: hansd on November 11, 2019, 02:12:11 pmHe who dies with the most toys wins.https://m5stack.com/collections/m5-core/products/stickv

author: wnorcott
author_rank: Regular Contributor
timestamp: November 25, 2019, 01:19:05 pm
content: Hello friends. I have the Microsoft VSCode and Platformio installed and running on Manjaro Linux (an Arch-based distro) and it runs fine and I can upload programs to the Longan Nano. I bought one from Amazon Prime and is has the 4x2 pin JTAG header pins populated on the board. Do the ones direct from seeed studio have these pins soldered on? The product photo just shows unpopulated solder pads.If anyone is interested I took notes on how to set up the tool stack on Manjaro, it all works. Next to try is debugging with an Altera USB Blaster clone.

author: brucehoult
author_rank: Super Contributor
timestamp: November 25, 2019, 01:54:15 pm
content: Quote from: GeorgeOfTheJungle on November 25, 2019, 12:26:38 pmThat's why I've ordered both the new SparkFun RISC-V boards ... and their ESP32 board just to make the order up to enough to get free shipping...

author: andersm
author_rank: Super Contributor
timestamp: November 25, 2019, 03:24:00 pm
content: Quote from: westfw on November 25, 2019, 06:54:55 amTwo options come to mind: The J-Link dongles are supposed to contain some smarts, which needs device-specific support. IIRC the MCU in the revision 10 is significantly more capable than in the previous version, so it's possible they just ran out of space. The more sinister possibility is forcing a wave of hardware upgrades ahead of the Next Big Thing.

author: coppice
author_rank: Super Contributor
timestamp: November 25, 2019, 04:11:58 pm
content: Quote from: andersm on November 25, 2019, 03:24:00 pmJ-Link is a rather deceptive name. It implies a single product when it was actually been a succession of products, several of which have obsoleted the previous ones for many users.

author: ale500
author_rank: Frequent Contributor
timestamp: November 25, 2019, 06:57:19 pm
content: The list of compatible devices list the altera usb blaster, something I also have. I'll try with that and report back. If only this Platformio wouldn't what to install itself every time I run it...

author: ale500
author_rank: Frequent Contributor
timestamp: December 10, 2019, 06:53:23 pm
content: The altera usb blaster didn't work either. In the mean time I ordered two of this sipeed rv debuggers and they showed up today.After switching the driver from ftdi to winusb using Zadig, the adaptor was recognized and the chip programmed:Code:Verbose mode can be enabled via `-v, --verbose` optionCONFIGURATION: https://docs.platformio.org/page/boards/gd32v/sipeed-longan-nano.htmlPLATFORM: GigaDevice GD32V 1.0.0 > Sipeed Longan NanoHARDWARE: GD32VF103CBT6 108MHz, 32KB RAM, 128KB FlashDEBUG: Current (sipeed-rv-debugger) External (altera-usb-blaster, gd-link, jlink, sipeed-rv-debugger, um232h)PACKAGES: framework-gd32vf103-sdk 1.0.0, tool-openocd-gd32v 0.1.1, tool-gd32vflash 0.1.0, toolchain-gd32v 9.2.0LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldfLDF Modes: Finder ~ chain, Compatibility ~ softFound 0 compatible librariesScanning dependencies...No dependenciesBuilding in release modeChecking size .pio\build\sipeed-longan-nano\firmware.elfAdvanced Memory Usage is available via "PlatformIO Home > Project Inspect"DATA: [= ] 7.0% (used 2300 bytes from 32768 bytes)PROGRAM: [ ] 1.9% (used 2530 bytes from 131072 bytes)Configuring upload protocol...AVAILABLE: altera-usb-blaster, gd-link, jlink, serial, sipeed-rv-debugger, um232hCURRENT: upload_protocol = sipeed-rv-debuggerUploading .pio\build\sipeed-longan-nano\firmware.elfGNU MCU Eclipse OpenOCD, 64-bitOpen On-Chip Debugger 0.10.0+dev-00593-g23ad80df4-dirty (2019-06-18-08:21)Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmlWarn : Transport "jtag" was already selectedjtagadapter speed: 1000 kHzInfo : clock speed 1000 kHzInfo : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)Error: Trying to use configured scan chain anyway...Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3"Warn : Bypassing JTAG setup events due to errorsInfo : datacount=4 progbufsize=2Info : Exposing additional CSR 3040Info : Exposing additional CSR 3041Info : Exposing additional CSR 3042Info : Exposing additional CSR 3043Info : Exposing additional CSR 3044Info : Exposing additional CSR 3045Info : Exposing additional CSR 3046Info : Exposing additional CSR 3047Info : Exposing additional CSR 3048Info : Exposing additional CSR 3049Info : Exposing additional CSR 3050Info : Exposing additional CSR 3051Info : Exposing additional CSR 3052Info : Exposing additional CSR 3053Info : Exposing additional CSR 3054Info : Exposing additional CSR 3055Info : Exposing additional CSR 3056Info : Exposing additional CSR 3057Info : Exposing additional CSR 3058Info : Exposing additional CSR 3059Info : Exposing additional CSR 3060Info : Exposing additional CSR 3061Info : Exposing additional CSR 3062Info : Exposing additional CSR 3063Info : Exposing additional CSR 3064Info : Exposing additional CSR 3065Info : Exposing additional CSR 3066Info : Exposing additional CSR 3067Info : Exposing additional CSR 3068Info : Exposing additional CSR 3069Info : Exposing additional CSR 3070Info : Exposing additional CSR 3071Info : Examined RISC-V core; found 1 hartsInfo : hart 0: XLEN=32, misa=0x40901105Info : Listening on port 3333 for gdb connectionsInfo : device id = 0x19060410Info : flash_size_in_kb = 0x00000040Info : flash size = 64kbytescleared protection for sectors 0 through 63 on flash bank 0Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)Error: Trying to use configured scan chain anyway...Warn : Bypassing JTAG setup events due to errors** Programming Started **auto erase enabledwrote 3072 bytes from file .pio\build\sipeed-longan-nano\firmware.elf in 1.622513s (1.849 KiB/s)** Programming Finished **** Verify Started **verified 2548 bytes in 0.176993s (14.059 KiB/s)** Verified OK **Info : Hart 0 unexpectedly reset!Info : Note: Hart is halted due to the halt-on-reset bit is set,please continue your program by appropriate debugger commands or operations!!The test code doesn't run but at least, it programmed.

author: wnorcott
author_rank: Regular Contributor
timestamp: December 10, 2019, 09:22:51 pm
content: I have one of the Sipeed RV debuggers too. You can also with a spare Sipeed Longan Nano board, burn the firmware so it becomes a debugger for other Longan Nano boards, using the JTAG header already on the board. Just need a ribbon cable to connect the two. That method is supported by PlatformIO too for the Longan Nano board.

author: techman-001
author_rank: Frequent Contributor
timestamp: January 24, 2020, 03:11:02 am
content: Quote from: bilibili on August 24, 2019, 01:50:16 pmLiterature package for GD32VF103:https://sourceforge.net/projects/mecrisp/files/Target%20literature%20package%20for%20GD32VF103.tar.gz(25.0 MB)├── Bumblebee\ Core\ Architecture\ Manual.pdf├── Bumblebee\ Core\ Brief\ Manual.pdf├── GD32VF103C-START-V1.0.pdf├── GD32VF103_Datasheet_Rev\ 1.1.pdf├── GD32VF103_User_Manual_EN_V1.2.pdf├── Longan\ Nano\ Pinout.png├── Longan\ Nano\ Pinout.svg├── Longan\ nano\ 2663(Assembly\ drawing).pdf├── Longan\ nano\ 2663(Schematic).pdf├── RISCVGreenCardv8-20151013.pdf├── STM32F103\ Reference\ Manual.pdf├── STM32F103.pdf├── riscv-privileged-20190608-1.pdf├── riscv-spec.pdf└── tool-gd32vflash-v0.1.0-linux.tar.gz

author: techman-001
author_rank: Frequent Contributor
timestamp: January 24, 2020, 04:42:58 am
content: Quote from: oPossum on August 24, 2019, 03:01:19 amAs many now know, GD have made their own STM32F10x 'compatible' peripherals and the pinouts of the 64 pin flatpack are compatible between GD and STM.I've made up a (ongoing) page comparing the peripherals of two chips and some other details :https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103-vs-gd32vf103.htmlOne current issue I'm trying to resolve is resetting the peripherals to default with a software command.I can find no reference to SYSRESETREQ in the GD literature other than the reset-logic pic in the GD32VF103 User Manual V1.2 PDF which I suspect is just paste from the GD32F103 PDF. What this means is there seems to be no simple way to reset all the GD32VF103 peripherals to power-up-defaults as can be done on STM32.This is achieved in the GD32VF103 sample factory code using a long list of individual peripheral register resets but I'm after a simple method as with the STM32F10x.Does anyone have any experience with this issue and the GD32VF103 ?

author: hansd
author_rank: Contributor
timestamp: January 24, 2020, 09:15:46 am
content: A system resetis generated by the following events:A power reset (POWER_RSTn).An external pin reset (NRST).A window watchdog timer reset (WWDGT_RSTn).A free watchdog timer reset (FWDGT_RSTn).The SYSRESETREQ bit in RISC-V Application Interrupt and Reset Control Register is set (SW_RSTn).Reset generated when entering Standby mode when resetting nRST_STDBY bit in User Option Bytes (OB_STDBY_RSTn).Reset generated when entering Deep-sleep mode when resetting nRST_DPSLP bit in User Option Bytes (OB_DPSLP_RSTn).A system reset resets the processor core and peripheral IP components except for the JTAGcontroller and the Backup domain.Page 61 GD32VF103_User_Manual_EN_V1.2 fromhttps://gd32mcu.21ic.com/en/indexI hope this helps.

author: ale500
author_rank: Frequent Contributor
timestamp: February 13, 2020, 07:39:51 pm
content: Have someone made any progress on linux, with platformio and a spipeed-rv-debugger ?. I have the latest packages from platform io (1.1.2) fot the gigadevices chips but still no dice regarding programming. Maybe the example code doesn't work. Here what I get in the console after "upload":Code:Processing sipeed-longan-nano (platform: gd32v; framework: gd32vf103-sdk; board: sipeed-longan-nano)------------------------------------------------------------------------------------Verbose mode can be enabled via `-v, --verbose` optionCONFIGURATION: https://docs.platformio.org/page/boards/gd32v/sipeed-longan-nano.htmlPLATFORM: GigaDevice GD32V 1.1.2 > Sipeed Longan NanoHARDWARE: GD32VF103CBT6 108MHz, 32KB RAM, 128KB FlashDEBUG: Current (sipeed-rv-debugger) External (altera-usb-blaster, gd-link, jlink, rv-link, sipeed-rv-debugger, um232h)PACKAGES: framework-gd32vf103-sdk 1.0.0, tool-openocd-gd32v 0.1.1, tool-gd32vflash 0.1.0, toolchain-gd32v 9.2.0LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldfLDF Modes: Finder ~ chain, Compatibility ~ softFound 0 compatible librariesScanning dependencies...No dependenciesBuilding in release modeChecking size .pio/build/sipeed-longan-nano/firmware.elfAdvanced Memory Usage is available via "PlatformIO Home > Project Inspect"DATA: [= ] 7.0% (used 2310 bytes from 32768 bytes)PROGRAM: [= ] 5.0% (used 6572 bytes from 131072 bytes)Configuring upload protocol...AVAILABLE: altera-usb-blaster, gd-link, jlink, rv-link, serial, sipeed-rv-debugger, um232hCURRENT: upload_protocol = sipeed-rv-debuggerUploading .pio/build/sipeed-longan-nano/firmware.elfOpen On-Chip Debugger 0.10.0+dev-00911-gcfbca74bd (2019-09-12-09:31)Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmlWarn : Transport "jtag" was already selectedjtagadapter speed: 1000 kHzInfo : clock speed 1000 kHzInfo : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)Warn : JTAG tap: riscv.cpu UNEXPECTED: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)Error: JTAG tap: riscv.cpu expected 1 of 1: 0x1e200a6d (mfg: 0x536 (Nuclei System Technology Co.,Ltd.), part: 0xe200, ver: 0x1)Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)Error: Trying to use configured scan chain anyway...Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3"Warn : Bypassing JTAG setup events due to errorsInfo : datacount=4 progbufsize=2Info : Exposing additional CSR 3040Info : Exposing additional CSR 3041Info : Exposing additional CSR 3042Info : Exposing additional CSR 3043Info : Exposing additional CSR 3044Info : Exposing additional CSR 3045Info : Exposing additional CSR 3046Info : Exposing additional CSR 3047Info : Exposing additional CSR 3048Info : Exposing additional CSR 3049Info : Exposing additional CSR 3050Info : Exposing additional CSR 3051Info : Exposing additional CSR 3052Info : Exposing additional CSR 3053Info : Exposing additional CSR 3054Info : Exposing additional CSR 3055Info : Exposing additional CSR 3056Info : Exposing additional CSR 3057Info : Exposing additional CSR 3058Info : Exposing additional CSR 3059Info : Exposing additional CSR 3060Info : Exposing additional CSR 3061Info : Exposing additional CSR 3062Info : Exposing additional CSR 3063Info : Exposing additional CSR 3064Info : Exposing additional CSR 3065Info : Exposing additional CSR 3066Info : Exposing additional CSR 3067Info : Exposing additional CSR 3068Info : Exposing additional CSR 3069Info : Exposing additional CSR 3070Info : Exposing additional CSR 3071Info : Examined RISC-V core; found 1 hartsInfo : hart 0: XLEN=32, misa=0x40901105Info : Listening on port 3333 for gdb connectionsInfo : device id = 0x19060410Info : flash_size_in_kb = 0x00000040Info : flash size = 64kbytesInfo : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)Warn : JTAG tap: riscv.cpu UNEXPECTED: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)Error: JTAG tap: riscv.cpu expected 1 of 1: 0x1e200a6d (mfg: 0x536 (Nuclei System Technology Co.,Ltd.), part: 0xe200, ver: 0x1)Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)Error: Trying to use configured scan chain anyway...Warn : Bypassing JTAG setup events due to errors** Programming Started **** Programming Finished **** Verify Started **** Verified OK **Info : Hart 0 unexpectedly reset!***  Error 1============================  Took 3.07 seconds ============================And the blinky doesn't blink.(Note: On another computer, with another longan nano, with a jlink 10.1, with embedded studio for RISCV, blinky works).I'll try my board on segger's IDE with a Jlink 10.1.

author: ale500
author_rank: Frequent Contributor
timestamp: February 14, 2020, 06:30:29 pm
content: I found the problem(s):The devices I have have the GD32F103C8T6. Advertised where GD32VF108CBT6. Note the number eight after the C and the letter B. The '8' means 64 kBytes Flash and 20 kBytes RAM. The 'B' means 128 kBytes Flash and 32 kBytes RAM.With the Segger Studio, changing between the two is not a problem two executable files will be generated with different RAM sizes, each works on the correct device (I got a CB board for testing purposes).On the PlatformIO side, I can choose the device, compile and upload seem to work but I still get the exception... more digging is necessary.

author: lundmar
author_rank: Frequent Contributor
timestamp: February 15, 2020, 11:00:20 am
content: Hi guys,For those who want to get started with the GD32VF103 chip in the most simplest way, have a look at my github repo:https://github.com/lundmar/riscv-gd32vf103-demoThis is the first time I get hands on with a RISC-V chip and I was curious to see how it compares to ARM, in particular concerning the required boot code. I've created a demo software that includes the simplest possible boot code to get a single threaded system running including the Newlib C library and the GD32VF103 driver library.Simply install the appropriate RISC-V toolchain via crosstool-ng and you will be able to compile the demo software.

author: brucehoult
author_rank: Super Contributor
timestamp: February 15, 2020, 02:05:42 pm
content: Quote from: lundmar on February 15, 2020, 11:00:20 amLooks good!My only quibble is that both your readme and the makefile say rv32ima while the Bumblebee core actually implements rv32imac. That will work fine, but you're missing out on saving typically 25% to 30% in program size (i.e. getting 35% to 40% more program code into a ROM of a given size) by using the optional 16 bit "C" opcodes.I also dislike overly-abstracted code, so it's great to have this and I'll try it on my Longan Nano soon. But I have an ATtiny85 project to do first :-)

author: lundmar
author_rank: Frequent Contributor
timestamp: February 15, 2020, 05:11:50 pm
content: Quote from: brucehoult on February 15, 2020, 02:05:42 pmMy good sir, you are of course correct. I will not tolerate such quibbles on your mind!Let's go full feature and use the compressed ISA instead - I have updated the repository and the binary output file is now precisely 13.8% smaller (.text size went down 14.7%).The only reason I left it at "ima" was that I wanted the pure 32-bit experience for my first meet with the RISC-V ISAAlso, my own quibbles or disappointment with the GD32VF103 aka Bumblebee core is that it does not implement mtvec.mode = 0x3 which allows for the vector table to be implemented in pure C by pointer functions (hw will jump to addresses instead of executing jump instructions), in the same way many cortex-M does it. This is an optional feature of the RISC-V standard and I believe that RISC-V chips such as the SiFive one implements it. You may notice that I have left code implementation for both ways.

author: brucehoult
author_rank: Super Contributor
timestamp: February 15, 2020, 08:41:19 pm
content: Quote from: lundmar on February 15, 2020, 05:11:50 pmI'm guessing this program is sooo small it's dominated by the table of interrupt vectors.QuoteA perfectly good reason.QuoteMeh. Jump instructions as interrupt/trap vectors saves a fair bit of complexity in the implementation, especially on something that doesn't otherwise have an indirect addressing mode (as RISCs don't). And it works fine as long as you can put all the service routines within 1 MB of the vector table.I tend to prefer using a single handler function that does the bookkeeping such as saving registers inline and then uses a regular C switch or table of function pointers to choose the handler. You can also preprocess the trap number to avoid having a few dozen pointers to the default "wtf?" handler.It makes very little difference in speed either way.

author: westfw
author_rank: Super Contributor
timestamp: February 16, 2020, 04:40:29 am
content: Is the interrupt mechanism considered part of the ISA, or part of the implementation for a RISC-V processor?I guess for ARM Cortex the NVIC is considered part of the core that is external to the CPU, but they seem sometimes-depressingly tightly coupled and non-RISCy.

author: brucehoult
author_rank: Super Contributor
timestamp: February 16, 2020, 07:19:40 am
content: Quote from: westfw on February 16, 2020, 04:40:29 amI'll say "part of the ISA, but optional".The standard privileged architecture specifies a basic interrupt handler that must be present, though it has optional features. Each privilege level that supports handling interrupts (M, S if it exists, U if it exists and the "N" extension is implemented) has a set of interrupt registers including the PC to return to, the exception cause, the exception data, and exception handler base address.The exception handler base address is constrained to be a multiple of 4, and the bottom two bits indicate the mode. Mode 00 means all exceptions go to a single handler located at baseAddress. Mode 01 means synchronous exceptions (system call, illegal instruction, illegal memory access etc) go to baseAddress while interrupts go to baseAddress plus 4 * interrupt number, where you will normally put a jump instruction to the actual handler. Modes 10 and 11 are reserved.An implementation can choose to support only mode 00, only mode 01, or both modes. An implementation can choose to use a fixed base address, or allow the user to set it. As usual in RISC-V you find the capabilities by trying to write what you want to the CSR then read it back and see if you get back the same thing you tried to write.The proposed "Fast interrupts extension" aka CLIC (Core Local Interrupt Controller) uses mode 11. This mode loads a pointer to the handler from baseAddress plus 4 * interrupt number or 8 * interrupt number (64 bit systems). Another mechanism allows to specify (with a bitmap) for each interrupt individually whether it will use its own vector or a common handler at interrupt vector 0.There is a whole lot more detail, far too much to go into here. If interested then read the specifications on github :-)Embedded software might be written to expect and need one particular interrupt controller mode. The Linux kernel will I believe work fine as long as at least one of modes 00, 01, or 11 is implemented.The very simplest implementations can support a single exception handler function at at fixed address (0, for example), and call themselves compatible with the RISC-V Privileged ISA, and things will work. The Linux kernel for example can discover that only mode 00 is supported, and can read back the fixed interrupt handler address from the CSR. Supporting higher modes can require a bit more hardware but provide higher performance.

author: Noopy
author_rank: Super Contributor
timestamp: April 21, 2020, 05:23:59 pm
content: Hi all,I have die pictures of the GD32VF103 for you:https://richis-lab.de/STM32_10.htmThere also is a flash die on top of the controller.It´s similar but smaller than the flash in the GD32F103:https://richis-lab.de/STM32_06.htmI assume they put the kind of flash die in the package they have around at this time."CHICAGO"?POWER! MORE POWER!

author: ale500
author_rank: Frequent Contributor
timestamp: April 22, 2020, 04:49:57 am
content: I was wondering about this. That means that executes from RAM the same way the GS32F103 does. Now we need some benchmarks !! And a way to unlock the extra SRAM.Danke Noopy !

author: GromBeestje
author_rank: Frequent Contributor
timestamp: April 22, 2020, 07:47:43 am
content: Has anyone ever succeeded unlocking any RAM in the GD32F10x? Back in the day there was some speculation, but I've never seen a continuation of this.

author: ale500
author_rank: Frequent Contributor
timestamp: April 26, 2020, 08:08:13 am
content: I have been wondering a while about this flash/sram concept that the GD32VF103 seems to use. Starting with the blinky test created by platformio, I modified the code to test the throughput of the processor.At least for code around ~1024 bytes, there seems to be no penalties, what makes me think that maybe the code is really loaded into SRAM, I mean, the whole code. That could only be tested with a larger function. I saw in one of the threads about the GD32F103 that the flash is loaded into a cache. So you see the load process when a new cache line has to be filled. I do not see this here, yeah, the code is a bit simple. In a x86, similar code exposes the memory architecture thus I tried a similar approach here...Code:RiscV GD32VF103 Instruction throughput tests:GPIOC 13 LED, test pinCPU Clock 108 MHz (default setting). 9.52 ns/clockCodestatic void __attribute__((noinline, naked)) main_loop_15MHz( void ){asm volatile(" lui a5, 0x40011 \n\t" // GPIOC" addi a3, a5, 16 \n\t"" lui a4, 0x2 \n\t""1: \n\t"" sw a4, 20(a5) \n\t"" addi a3, a5, 16 \n\t"" sw a4, 16(a5) \n\t"" addi a3, a5, 16 \n\t"" j 1b \n\t");}Tek0000.csvSignal freqnecy 15.49 MHzHigh width 47.20 ns - 2 opcodes + jumpLow width 17.68 ns - 2 opcodestrying to match the jump width------------------------------30 ns ~ 3 clocks at 108 Mhzstatic void __attribute__((noinline, naked)) main_loop_10MHz( void ){asm volatile(" lui a5, 0x40011 \n\t" // GPIOC" addi a3, a5, 16 \n\t"" lui a4, 0x2 \n\t""1: \n\t"" sw a4, 20(a5) \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" sw a4, 16(a5) \n\t"" addi a3, a5, 16 \n\t"" j 1b \n\t");}Match !Tek0001.csvSignal freqnecy 10.89 MHzHigh width 46.9 ns - 2 opcodes + jumpLow width 45.8 ns - 2 opcodesThe low pulse is consistently 1 ns shorter as the high pulseThe addi opcodes are 32 bit opcodes, it seems that there is nodifference between the width of the opcodes and the executiontime. Using the same target register seems to not imposeany penalties.Check for chache line size, go for > 64 byte code-------------------------------------------------static void __attribute__((noinline, naked)) main_loop( void ){asm volatile(" lui a5, 0x40011 \n\t" // GPIOC" addi a3, a5, 16 \n\t"" lui a4, 0x2 \n\t""1: \n\t"" sw a4, 20(a5) \n\t" // low" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" sw a4, 16(a5) \n\t" // high" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" j 1b \n\t");}Tek0002.csvSignal freqnecy 4.156 MHzHigh width 121.2 ns - 11 opcodes + jump (+2) // 9.32 ns/opcodeLow width 120.7 ns - 13 opcodes = ~ 9.28 ns/opcodeNo cache line fill detectedTry longer code > 128 bytes---------------------------static void __attribute__((noinline, naked)) main_loop( void ){asm volatile(" lui a5, 0x40011 \n\t" // GPIOC" addi a3, a5, 16 \n\t"" lui a4, 0x2 \n\t""1: \n\t"" sw a4, 20(a5) \n\t" // low" addi a3, a5, 16 \n\t" // 44 times !" sw a4, 16(a5) \n\t" // high" addi a3, a5, 16 \n\t" // 42 times" j 1b \n\t");}Tek0003.csv44e - 2f6 = 344 bytesSignal freqnecy 1.200 MHzHigh width 417.6 ns - 43 opcodes + jump (+2) // 9.28 ns/opcodeLow width 415.8 ns - 45 opcodes = ~ 9,24 ns/opcodeTry longer code > 1024 bytes---------------------------static void __attribute__((noinline, naked)) main_loop( void ){asm volatile(" lui a5, 0x40011 \n\t" // GPIOC" addi a3, a5, 16 \n\t"" lui a4, 0x2 \n\t""1: \n\t"" sw a4, 20(a5) \n\t" // low" addi a3, a5, 16 \n\t" // ** 172 times !" sw a4, 16(a5) \n\t" // high" addi a3, a5, 16 \n\t" // ** 170 times" j 1b \n\t");}Tek0004.csv84e - 2f6 = 1368 bytesSignal freqnecy 312.2 kHzHigh width 1602 ns - 171 opcodes + jump (+2) // 9.28 ns/opcodeLow width 1601 ns - 173 opcodes = ~ 9,25 ns/opcodeThe Binky code is then:Code:/*!\file main.c\brief running led\version 2019-6-5, V1.0.0, firmware for GD32VF103*//*Copyright (c) 2019, GigaDevice Semiconductor Inc.Redistribution and use in source and binary forms, with or without modification,are permitted provided that the following conditions are met:1. Redistributions of source code must retain the above copyright notice, thislist of conditions and the following disclaimer.2. Redistributions in binary form must reproduce the above copyright notice,this list of conditions and the following disclaimer in the documentationand/or other materials provided with the distribution.3. Neither the name of the copyright holder nor the names of its contributorsmay be used to endorse or promote products derived from this software withoutspecific prior written permission.THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUTNOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, ORPROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITYOF SUCH DAMAGE.*/#include "gd32vf103.h"#include "systick.h"#include <stdio.h>/* BUILTIN LED OF LONGAN BOARDS IS PIN PC13 */#define LED_PIN GPIO_PIN_13#define LED_GPIO_PORT GPIOC#define LED_GPIO_CLK RCU_GPIOCstatic void main_loop( void );void longan_led_init(){/* enable the led clock */rcu_periph_clock_enable(RCU_GPIOA);/* configure led GPIO port */gpio_init(GPIOA, GPIO_MODE_OUT_PP, GPIO_OSPEED_50MHZ, GPIO_PIN_1);GPIO_BC(GPIOA) = GPIO_PIN_1;gpio_init(GPIOA, GPIO_MODE_OUT_PP, GPIO_OSPEED_50MHZ, GPIO_PIN_2);GPIO_BC(GPIOA) = GPIO_PIN_2;/* enable the led clock */rcu_periph_clock_enable(LED_GPIO_CLK);/* configure led GPIO port */gpio_init(LED_GPIO_PORT, GPIO_MODE_OUT_PP, GPIO_OSPEED_50MHZ, LED_PIN);GPIO_BC(LED_GPIO_PORT) = LED_PIN;}void longan_led_on(){GPIO_BOP(LED_GPIO_PORT) = LED_PIN;}void longan_led_off(){GPIO_BC(LED_GPIO_PORT) = LED_PIN;}/*!\brief main function\param none\param none\retval none*/int main(void){longan_led_init();main_loop();}// and here paste one of the main_loop functions

author: brucehoult
author_rank: Super Contributor
timestamp: April 26, 2020, 08:38:14 am
content: Interesting investigation, thanks!I've got a few Longan Nano boards (at $4.90 each plus $50 shipping might as well get more than one) but didn't find a chance to play with them yet.You're never going to detect cache lines by making the code bigger than a cache line -- you have to make it bigger than the entire cache.However, the datasheet...https://dl.sipeed.com/LONGAN/Nano/DOC/GD32VF103_Datasheet_Rev1.0.pdf... says it read program code directly from flash with no wait states.That's probably what limits it to 108 MHz. I'm sure the rest of it could go faster.Interesting that it seems every taken branch uses 3 clock cycles i.e. a pipeline flush.So, no cache, no branch prediction.Sadly there is no information about instruction timing in the datasheet.If would be interesting to see if a conditional branch for the loop takes the same time as the Jump. The timing on JALR (e.g. function return) would also be interesting. Are shift all single-cycle regardless of the shift count?

author: ale500
author_rank: Frequent Contributor
timestamp: April 26, 2020, 08:55:35 am
content: May be the wording on my part was poorly selected. You are right, of course.What the datasheet says, regarding the flash can be ignored. We know it is being serially loaded. The question I wanted answered was if the whole flash gets mirrored or not. And if not how big is the "cache". It seems to be bigger than 8 kBytes. The code crosses now the first 4 kbytes boundary and doesn't seem to expose any loading latency (I extended the function to ~ 3.4 kBytes and crosses the 4 kbytes boundary. Most probably it is loaded completely. That means that there are some "hidden" registers that make the mirror SRAM writable. And some hidden ROM too. It would have been nice to see to which pins the flash was connected to guess on the interface type, the EXTI doesn't support serial memories. Now that I think of it, it doesn't support QPI either, so it is probably just SPI.

author: brucehoult
author_rank: Super Contributor
timestamp: April 26, 2020, 09:16:26 am
content: Quote from: ale500 on April 26, 2020, 08:55:35 amHow do we know it is being serially loaded?The datasheet says there is an AHB bus to the flash. In fact it says there are two AHB ports to the flash, one for the address, one for the data. All the other peripherals, including the main SRAM memory are on a 3rd "system" AHB bus.Why do you think they are lying?

author: brucehoult
author_rank: Super Contributor
timestamp: April 26, 2020, 09:58:56 am
content: I suggest you read up on "Parallel NOR Flash". For examplehttps://www.cypress.com/file/202491/downloadI see the sequential access time there is 9 ns. What's the clock cycle time on the GD32VF103? 9 ns. Interesting.Note that the main business of GigaDevice is making and selling flash memory. Microcontrollers are somewhat of a side-line. I'm sure they can make flash as well as Cypress can.

author: brucehoult
author_rank: Super Contributor
timestamp: April 26, 2020, 10:24:13 am
content: So, there is 128k of program memory, right? That's 1 M bits. Likely arranged in a 1024x1024 array, with a 1024 bit (128 byte) row buffer. Say it takes 18 ns to read a row into the buffer but then 9 ns to read something else from the same row. And the bus back to the CPU is 32 bits wide.If you're running code sequentially, or even jumping around in the same 128 bytes then you get 9 ns access.When you cross or jump to a new row (whether random or sequential) you get a 18 ns access instead of 9 ns.So your test with 345 instructions and 1376 bytes in the loop is going to cross row boundaries 10 times, plus the jump. So 334 instructions will take 9 ns and 11 instructions will take 18 ns. Total 3204 ns or 9.287 ns per instruction on average.3204 ns per loop is 1e9/3204 = 312.11kHz.Is that compatible with what you're seeing?YES

author: ale500
author_rank: Frequent Contributor
timestamp: April 26, 2020, 12:22:01 pm
content: I understand what you mean, but, if you look at the picture Noopy posted, most likely a flash, like in the GD32F103, is in an extra die that only has 10 pins. Meaning, even with a hyperbus or similar you are several clocks away from 32 bits of data.If they had flash on die then what you say would apply, no discussion. Before Noopy posted the picture I thought we had a flash on die.Let's say I'm mistaken, I have another idea: the RiscV core used has instructions and cycle counters.Let's extend the test and use these counters. This is getting very interesting !Edit:Something with the counters doesn't seem to work, I read the same values before and after some instructions:I get 0x00003171 for the cycles counter and 0x000021B0 for the instret counter, both times.Code:static void __attribute__((noinline, naked)) main_loop( uint32_t *countersptr ){asm volatile(" rdcycle a5 \n\t"" sw a5, 0(a0) \n\t"" rdinstret a5 \n\t"" sw a5, 4(a0) \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" rdcycle a5 \n\t"" sw a5, 20(a0) \n\t"" rdinstret a5 \n\t"" sw a5, 24(a0) \n\t"" lui a5, 0x40011 \n\t" // GPIOC" addi a3, a5, 16 \n\t"" lui a4, 0x2 \n\t""1: \n\t"" sw a4, 20(a5) \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" addi a3, a5, 16 \n\t"" sw a4, 16(a5) \n\t"" addi a3, a5, 16 \n\t"" j 1b \n\t");}Edit: The simple solution seems to fail. The counters are disabled.After enabling the counters I get:There are 35 instructions between both rdcycle and rdinstret.Cycles before 0x4769, after 0x478e, diff : 37Intructions retired before 0x32ba, after 0x32de, diff : 36The last store word doesn't get count.I think that it executes from some very fast memory without any wait states. (unless they do not count as cycles, what seems improbable given previous tests).@brucehoult: What do you think ?

author: brucehoult
author_rank: Super Contributor
timestamp: April 26, 2020, 01:52:29 pm
content: Hmm .. ok I've found some better pics of GD32F103 with ARM and it really does look like it's got 128k of SRAM to copy the flash into and 20k of SRAM for the program to use.Nuts!I guess technically the "Flash Memory Controller" box could contain 128k of SRAM.The DG32VF103 start up time from reset is 132 ms, and 118.8 ms to wake from 7 uA standby mode. Wake from "deep sleep" 400 uA mode is 6 us. So that's almost 15000 times longer from standby mode. And 60x lower power consumption. Only "backup registers" are retained in standby mode, CPU registers and SRAM contents are lost.That 118.8 ms to wake is enough time to copy 128k of flash to SRAM at 1.11 MB/sec, 8.8 Mbps. One byte every 900 ns. One bit every 112.5 ns. Even stupidly cheap flash is faster than that. The external SPI flash on the HiFive1 can run at 133 MHz doing 4 bits per cycle (QSPI), or 66 MB/sec.For comparison, an STM32F103 wakes up from stop 13 uA mode in 5 us, and from standby 2 uA mode in 50 us. So it comes out of the lowest power consumption mode over 2000 times faster.I seem to recall AVRs have similar wakeup times to the STM chip.So yeah, ok, call me convinced.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 26, 2020, 02:59:14 pm
content: Yup, those were some of my points as well. Crazy start up and wake up times, not that great in terms of power consumption either.But yeah this flash chip+SRAM solution is likely considerably cheaper. They just stack a very low cost flash chip (hence why it's likely so slow) die on their MCU die. It's likely not even QSPI. Integrating flash memory directly on the same die, and being able to run from it at a reasonable speed would be a lot more expensive.All in all, it seems there aren't any RISC-V-based MCUs on the market yet that can really compete with existing ARM-based MCUs, at least for a number of key factors such as power consumption/efficiency of low-power modes/etc.That's too bad, since due to the simplicity of RISC-V, there's clear potential to design MCUs that are even lower power (possibly by a large margin) than their ARM "counterparts". But I haven't seen such an MCU yet on the market.

author: brucehoult
author_rank: Super Contributor
timestamp: April 26, 2020, 03:05:54 pm
content: I tried your code on the HiFive1 with the following modifications:Used...Code:" csrr a5, mcycle \n\t"" sw a5, 0(a0) \n\t"" csrr a5, minstret \n\t"" sw a5, 4(a0) \n\t"... instead of rdcycle and rdinstret because the FE310-G000 doesn't support those user mode instructions.Added a "ret" before your infinite loop.Added a mainCode:int main(){uint32_t counts;printf("Starting\n", 13);for (int i=0; i<5; ++i){main_loop(counts);printf("ins=%d cycles=%d\n", counts-counts, counts-counts);}printf("Done\n");return 0;}The results are:Code:02:55:57.864 -> core freq at 259004825 Hz02:56:57.864 -> Starting02:56:57.864 -> ins=36 cycles=1851602:56:57.864 -> ins=36 cycles=4002:56:57.864 -> ins=36 cycles=4002:56:57.864 -> ins=36 cycles=4002:56:57.864 -> ins=36 cycles=4002:56:57.864 -> Done02:56:57.864 ->02:56:57.864 -> Progam has exited with code:0x00000000You can see that on the first execution it takes quite some time to load the code from SPI flash into the instruction cache.

author: brucehoult
author_rank: Super Contributor
timestamp: April 26, 2020, 03:49:18 pm
content: Changing the csr reading to...Code:" csrr a5, mcycle \n\t"" csrr a6, minstret \n\t"" sw a5, 0(a0) \n\t"" sw a6, 4(a0) \n\t"... drops the cycles from 40 to 37.

author: ale500
author_rank: Frequent Contributor
timestamp: April 30, 2020, 03:05:38 pm
content: Now, I'd like to know how the flash gets loaded into SRAM. From the skinny description of the FMC registers, it doesn't look promising, probably some key opens some more registers.The wait states register doesn't seem to make any difference in the execution time from SRAM, so I don't really know what it means.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 02, 2020, 11:19:49 pm
content: Quote from: brucehoult on April 26, 2020, 01:52:29 pmYes, certainly specs like a Boot-From-Flash design.There are a few of reasons to do this* Mask sets and process are much cheaper, so for a development part, this can make sense (easier sign off from bean counters)* It can allow a Higher MHz operation, as SRAM is faster than FLASH (but needs a lot more die area, so much larger memory could prove an issue )The way it is spec'd, they could flip to a FLASH part in the future.Maybe they gauge the market to see if MHz matters more ? - I see ARM family go up to 2048k Flash, which is too large for a on chip SRAM solution.

author: bson
author_rank: Unknown
timestamp: May 03, 2020, 12:05:19 am
content: Finally received my Longan Nano boards. These have the "B" variety CPU.

author: westfw
author_rank: Super Contributor
timestamp: August 03, 2020, 05:16:00 am
content: Still no supported Mac toolchain :-(

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: August 03, 2020, 10:19:57 am
content: Quote from: westfw on August 03, 2020, 05:16:00 amOMG. Thanks for pointing it out!

author: zl2wrw
author_rank: Regular Contributor
timestamp: September 03, 2020, 07:47:59 pm
content: I had trouble buildinghttps://github.com/riscv-mcu/riscv-openocdSo I cloned "mainline" riscv-openocd and backported GD32VF103 flash support:https://github.com/ZL2WRW/riscv-openocdI've got a pull request in process to include my changes into riscv-openocd:https://github.com/riscv/riscv-openocd/pull/518Hopefully this is useful to you.