RISC-V microcontrollers from GigaDevice

[brucehoult]

I tried your code on the HiFive1 with the following modifications:

Used...

Code: [Select]

        "   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 main

Code: [Select]

int main()
{
  uint32_t counts[7];
  printf("Starting\n", 13);
  for (int i=0; i<5; ++i){
    main_loop(counts);
    printf("ins=%d cycles=%d\n", counts[6]-counts[1], counts[5]-counts[0]);
  }
  printf("Done\n");
  return 0;
}

The results are:

Code: [Select]

02:55:57.864 -> core freq at 259004825 Hz
02:56:57.864 -> Starting
02:56:57.864 -> ins=36 cycles=18516
02:56:57.864 -> ins=36 cycles=40
02:56:57.864 -> ins=36 cycles=40
02:56:57.864 -> ins=36 cycles=40
02:56:57.864 -> ins=36 cycles=40
02:56:57.864 -> Done
02:56:57.864 ->
02:56:57.864 -> Progam has exited with code:0x00000000

You can see that on the first execution it takes quite some time to load the code from SPI flash into the instruction cache.

[brucehoult]

Changing the csr reading to...

Code: [Select]

        "   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.

[ale500]

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.

[PCB.Wiz]

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.

Yes, 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.

[bson]

Finally received my Longan Nano boards.  These have the "B" variety CPU.

[westfw]

Still no supported Mac toolchain :-(

[GeorgeOfTheJungle]

Still no supported Mac toolchain :-(

OMG. Thanks for pointing it out!

[zl2wrw]

I had trouble building https://github.com/riscv-mcu/riscv-openocd
So I cloned "mainline" riscv-openocd and backported GD32VF103 flash support: https://github.com/ZL2WRW/riscv-openocd

I've got a pull request in process to include my changes into riscv-openocd: https://github.com/riscv/riscv-openocd/pull/518

Hopefully this is useful to you.