ch32v307, risc-v minicore with ethernet

[bingo600]

WCH tools are installing a driver that's doing the switch. Their openocd on windows has also a hard dependency on this driver.

Does that mean the "mode" switchin is retained or forgotten on "dongle reboot" ?

I'll be using the dongle on linux.
But might dig up a WIN PC    , for the mode switching.

/Bingo

I think its not persistent.

One more thing you could try is minichlink https://github.com/cnlohr/ch32v003fun/tree/master/minichlink, not sure how it handles this button less module.

I found a Win10 PC , and used : WCH-LinkUtility to switch mode on my "Buttonless" WCHLINK to RiscV mode
It seemed to reflash the WCHLINK (V2.10) , and is now in RiscV mode. Also after a disconnect/Connect.

I have succesfully programmed the 307 board , with both the WCHLINK , and the WCHLINK-E
According to Doc , you need the WCHLINK-E to program the small 20-pin ssop, but both can program a 307


Edit:
While at it ... You might want to do a "Conect to WCHLINK" , in the utility , for all your programmers.
My WCHLINK-E. was updated to a later firmware (2.11) 

/Bingo

[bingo600]

There's a bit of definitions in the : WCHISPTool_CMD.ZIP     - Commandline programmer

Some source and API headers , but the "Goodies" is in a library w. no src

Maybe someone can deduct some info from the API include files
I'm especially thinking how2 set flash/mem partitioning on linux.

Seems like the "Config file" needed can be made/saved in the

The configuration file is generated by the "Save UI Config" function of WchIspStudio.exe

/Bingo

[jnk0le]

I found a Win10 PC , and used : WCH-LinkUtility to switch mode on my "Buttonless" WCHLINK to RiscV mode
It seemed to reflash the WCHLINK (V2.10) , and is now in RiscV mode. Also after a disconnect/Connect.

Does it remain when moved to linux pc, or just the driver?

[bingo600]

I found a Win10 PC , and used : WCH-LinkUtility to switch mode on my "Buttonless" WCHLINK to RiscV mode
It seemed to reflash the WCHLINK (V2.10) , and is now in RiscV mode. Also after a disconnect/Connect.

Does it remain when moved to linux pc, or just the driver?

It reprograms the programmer.
And it remains RiscV - When moved/connected to linux


Edit:
My wchlink programmer also registers as an usb uart ttyACM0
Helps a lot with an uart for messages.

Might be why there was a ch3xx Win driver included.

Linux doesn't need a driver.

[bingo600]

ddrown wrote something interesting about the flash/ram partitioning here

https://github.com/cnlohr/ch32v003fun/issues/232#issuecomment-1694923415

Edit ....

Based on that  (3f,ff,bf,7f)

Code: [Select]

128k.txt:81:06:08:02:3f:ff:ff:ff:ff:ff:ff
32k.txt:81:06:08:02:ff:ff:ff:ff:ff:ff:ff
64k.txt:81:06:08:02:bf:ff:ff:ff:ff:ff:ff
96k.txt:81:06:08:02:7f:ff:ff:ff:ff:ff:ff

It could be that this command (two upper bits) controls a 64K (bit 7 = 0) and 32K (bit 6 = 0) Ram bank

If the MCU always has 32K Ram , then you can switch in an extra 64K and/or 32K by setting the cooresponding bit to ZERO

I have no idea (yet) if these are MCU register bits or Programmer "instructions

[SiliconWizard]

I am able to read the bootloader. The first instruction is jal x0, 5842. Haven't disassembled it fully yet.
Haven't tried writing to this area yet. For all I know, it may be possible to write to it just like any other area of the Flash on the CH32V30x. Something I'll try later on.

I am going however to try defining a section in the Flash in the non-zero-wait area, place some data in it, and see how it goes. I'll also try running code from there after that, although I'm less positive it'll work. We'll see.

The only doubt I have is the total amount available depending on the version of the chip. The CH32V305 for instance has less available RAM and Flash (according to the DS), but it's unclear if it's just an artificial limitation and the chip may still have the full 320KB RAM and 480KB Flash as well.

[SiliconWizard]

* NOTE for everyone using the SDK linker script or a modified version thereof. *

They have defined the .bss section with the following memory placement:

Code: [Select]

>RAM AT>FLASH , as for the .data section.
I think this is pretty wrong. It should be only

Code: [Select]

>RAM as far as I know. Otherwise, it will eat space in Flash for the unitialized data. It's possible that it'll be optimized out by the linker eventually, although I'm not completely sure.

For people skilled at writing linker scripts, let me know your thoughts.

[wilhe_jo]

There are other quirks in there as well... LTO doesn't work because interrupts get "optimized" out.

At the first glance, everything should do, but I'm sure I missed some attribute for the prototypes/vector tables.

Up to now I se just 30k, so not enough motivation ATM to investigate this issue further.

The Mounriver studio is missing C++ as well...

All in all, it's fine to get some first prototype ready, but needs some polishing... Similar to all other Dev environments I used so far.... None is perfect.

But the peripheral libs all seem sound so far...way better than eg. STM hal or non-standard stuff in esp-idf.

73

[SiliconWizard]

There are other quirks in there as well... LTO doesn't work because interrupts get "optimized" out.

It's not really specific to this I think. I've seen that with ARM MCUs as well The usual treatment is to add the "used" attribute to prevent the linker from pruning code/variables that it thinks are not referenced. Try that and let us know. I usually don't use LTO on embedded stuff, so I haven't encountered that, but this attribute should help.

[wilhe_jo]

I've seen that with ARM MCUs as well

That's what I meant with "none are perfect"

My guess is, that there's also some problem with the weak definitions.
If "used" is missing, there should be a unknown reference as well and/or the vector should be missing.
Need to dig into the lst and map files at some point ...

73

[HwAoRrDk]

They have defined the .bss section with the following memory placement:

Code: [Select]

>RAM AT>FLASH , as for the .data section.
I think this is pretty wrong. It should be only

Code: [Select]

>RAM as far as I know. Otherwise, it will eat space in Flash for the unitialized data. It's possible that it'll be optimized out by the linker eventually, although I'm not completely sure.

I've been trying to learn about linker scripts, and I noticed this same thing in the CH32V003 linker script supplied by WCH when I was trying to understand it. I did think it was odd that the BSS section would have a load address (LMA) specified, when there is nothing to load for BSS (because of course it's the startup code that zeroes out this section in RAM). So I'm not sure it matters, because there will be no actual content for that section.

With that said though, checking the map file output by the linker for a CH32V003 project of mine using this linker script, it says that my .bss section is 228 bytes in size and has a load address of 0x3310; that address does actually exist in my output firmware image, but it is a single 0x00 byte at the very end. So I guess technically it is "eating" space in flash. I wonder where this single byte comes from, or if it is perhaps just an artefact of "if the section exists, there has to be something in it".

[SiliconWizard]

Probably. It's best to fix the linker script and make it clean.

Using the NZW Flash area with a dedicated section is doable - the small hiccup right now is that this area of Flash is *not* mapped right after the normal code area (which is remapped at address 0), so it must be accessed from its base address, which is an offset of 0x0800_0000. No problem, you just need to define the origin appropriately, like this for instance:

Code: [Select]

FLASH_NZW (rx) : ORIGIN = 0x08000000 + LENGTH(FLASH), LENGTH = 480K - LENGTH(FLASH)
Then add a section like this:

Code: [Select]

.flash_nzw_data :
{
. = ALIGN(4);
*(.flash_nzw_data)
. = ALIGN(4);
} >FLASH_NZW
And there you go. Almost.

Now, since the code area and this NZW area will be far apart from the perspective of the linker, that will generate a huge .bin file, if you use binary files. With this, you can't. It would be much too large (> 128MB with most of it zero.)
So you'll have to stick to elf or hex. Which is still all fine for the most part. But now you need a programming tool that can Flash different non-consecutive blocks in a smart way rather than as a contiguous block, and there is not much that can do this at the moment. A small issue, but no real tool for flashing, unless you write your own. The wlink tool (written in Rust) that I'm using can't do that, but there is a ticket for this as a feature request. We'll see. Maybe openocd can do this, I'm not sure, haven't tried it yet.

Otherwise, we would have to stick to other approaches, a bit less convenient - the problem is kinda similar to the typical bootloader + user app in a single object file thing.

[tellurium]

They have defined the .bss section with the following memory placement:

Code: [Select]

>RAM AT>FLASH , as for the .data section.
I think this is pretty wrong. It should be only

Code: [Select]

>RAM as far as I know. Otherwise, it will eat space in Flash for the unitialized data. It's possible that it'll be optimized out by the linker eventually, although I'm not completely sure.

For people skilled at writing linker scripts, let me know your thoughts.

Correct. BSS should not occupy any space in the compiled binary, and should not take any space on flash.

[wilhe_jo]

Using the NZW Flash area with a dedicated section is doable - the small hiccup right now is that this area of Flash is *not* mapped right after the normal code area (which is remapped at address 0), so it must be accessed from its base address, which is an offset of 0x0800_0000. No problem, you just need to define the origin appropriately, like this for instance:

IIRC, you can tell the linkerfile where code lives in the binary and where it would execute (I seldomly have the need to dig that deep).

Hence, it should be possible, to have all the flash starting at 0x08... in the binary (1 block) and have 2 sections executing in different places.
But you could just move everything into the 0x08... range.

I mean what could go wrong?
The cpu resets, maps 0x08.. to 0x00.. (I read the manual, that this memory lives in 2 locations as for eg. the Cortex M) and loads an address in the 0x08... region.
That should be executeable as well and therefore it should "just" work, right?

Worst case would be to use -fPIC...

This would be a massively interesting thing... use the full 480k flash and 128k ram.

73

[bingo600]

I have just "enhanced" minichlink (for the wchlink(-e) dongle) with ram partitioning  - On programming.
Thanx to ddrown for doing the hard work.

See attachments


I have only tested 64K Ram for now.
That's what ddrown's lwip example uses in the linker.


/Bingo

[wilhe_jo]

<edit>
ok.. I played around... it may really, really work...

I added a mapped section:

Code: [Select]

MAPPED(rx) : ORIGIN = 0x00000000, LENGTH = 288K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 480K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32K
Then I switched ">FLASH AT>FLASH" to ">MAPPED AT>FLASH"

next, I switched the openocd stuff

Code: [Select]

#interface wlink
adapter driver wlinke
adapter speed 3000
transport select sdi

wlink_set_address 0x08000000
set _CHIPNAME wch_riscv
sdi newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x00001

set _TARGETNAME $_CHIPNAME.cpu

target create $_TARGETNAME.0 wch_riscv -chain-position $_TARGETNAME
$_TARGETNAME.0 configure  -work-area-phys 0x20000000 -work-area-size 10000 -work-area-backup 1
set _FLASHNAME $_CHIPNAME.flash

flash bank $_FLASHNAME wch_riscv 0x08000000 0 0 0 $_TARGETNAME.0

echo "Ready for Remote Connections"

Now programming works as if everything was at 0x00, it runs (at least for me) and you should be able to put section not into the mapped region (ie. into the first 192...288k flash).
If you execute from the 0x08 region, wired stuff happend... I dunno if this is because you shoudn't, or I was just stupid...


73

[bingo600]

ddrown talks about interrupts here, and how to get "stock" riscv-gcc to do "fast interrupt"
https://blog.dan.drown.org/ch32v307-dev-board-part-2/


/Bingo

[brucehoult]

ddrown talks about interrupts here, and how to get "stock" riscv-gcc to do "fast interrupt"
https://blog.dan.drown.org/ch32v307-dev-board-part-2/

This issue has been extensively discussed here in the past.

If you are going to call such a heavyweight thing as printf() then there is no point worrying about a few cycles more or less in the interrupt handler prologue and epilogue -- just use a standard RISC-V interrupt attribute (option 1) and don't enable WCH's "fast interrupt" (HPE) feature (or it doesn't matter if you do, just a little more wasted work).

Option 1 is also a good option is you delete the printf() as the code will only use 3 registers, which take very little time to save and restore. Not as fast as using HPE, but close, and a couple of cycles quicker than Option 2.

Option 1 is the ONLY CORRECT choice if your handler -- or anything it calls -- uses floating point. Do you *know* that printf() won't use FP at all? It probably won't but if it does then the interrupted code will be very very unhappy.

WCH's fast interrupt mode DOES NOT support using FP in the interrupt handler. This is not a concern on the CH32V003, but it is on the 307.


Option 2 is functionally equivalent to using WCH's patched compiler, and is slower only by two instructions jal, and ret.

User @jnk0le has an official proposal in for a "prestacked" attribute to be implemented in __attribute__((interrupt)) in gcc and llvm which will allow you to use Option 1 without redundantly saving and restoring a0-a7,t0-t6,ra. 

[wilhe_jo]

WCH's fast interrupt mode DOES NOT support using FP in the interrupt handler. This is not a concern on the CH32V003, but it is on the 307.

Hmmm this must be the reason for using softfp as the default...

Regards

[martinribelotta]

WCH's fast interrupt mode DOES NOT support using FP in the interrupt handler. This is not a concern on the CH32V003, but it is on the 307.

While this is mostly true, it is not entirely correct:

The GCC provided by MounRiver push correctly the FPU registers in the stack via software when you indicate -march=rv32imafc -mabi=ilp32f but this behaviour break the advantage of fast interrupt when hardware-stacked registers.

In fact, you can use hardware-stacked registers and FPU interrupt but don't expect much improvement between "WCH-FastInterrupt" and standard "interrupt"

[wilhe_jo]

Seems similar to cortex-m....

I really need to dig into risc-v ...
But 10y of cortex-m vs first 2 projects in parallel with CH32...
There're some things to learn about this new architecture

All in all the ASM looks already semi intuitive.

But I'm not sure about some "instabilities" during debugging.
Time to time a power cycle seems needed in order to fix debugging problems (single stepping stops working).
I'm not sure if it's EMI, user stubitity, soft- or hardware problems.

Anyhow. I'm positively surprised so far.

Moving this stuff to upstream GCC (what about llvm on risc-v? I tend to like the llvm warnings/errors better) comes next...
One of the projects will go open-source (6ghz power sensor).
That'll definitely move...
But first I need to get the last bits semi tidy.
For now, the hardware is verified and most of the firmware architecture has fallen into place (TinyUSB works pretty easily and performs adequately well... but has it's own quirks).

73

[brucehoult]

Seems similar to cortex-m....

Technically, the RV32IMAFC instruction set used by the CH32V307 is very similar to Cortex-M4F. Both use a mix of 2-byte and 4-byte instructions for great code density and have single precision FP.

Being not actually the same ISA they made some different decisions and each has some small advantage over the other in some specific area e.g. Arm has more addressing modes which can save a couple of instructions on array accesses, while RISC-V has single instruction compare-and-branch which is used more often in most code. RISC-V has 32 integer and 32 FP registers compared to ARMv7-M's 16 integer registers and 32 FP registers. RISC-V has more registers that need saving on an interrupt, but in the absence of interrupts often runs faster because more variables can be kept in registers not on the stack. Also, WCH's HPE option (which is not standard RISC-V) allows the CH32V307 to save all needed registers instantly to a set of shadow registers.  Note: RISC-V has a RV32E variant with only 16 integer registers, and this is used in the low end CH32V003.

Moving this stuff to upstream GCC (what about llvm on risc-v? I tend to like the llvm warnings/errors better) comes next...

LLVM has supported RISC-V for quite some time. I published the first ready-to-build LLVM supporting RISC-V just over four years ago:

https://github.com/sifive/riscv-llvm

Many many improvements and new features have been added in the last four years and LLVM is now the preferred compiler for RISC-V for many projects. It definitely gets support for new ISA extensions faster (not that this is relevant to microcontrollers using only very core instructions)

[bingo600]

openvch just updated EVT sdk,boards & schematics
https://github.com/openwch/ch32v307

[mikeselectricstuff]

WCH's fast interrupt mode DOES NOT support using FP in the interrupt handler. This is not a concern on the CH32V003, but it is on the 307.

While this is mostly true, it is not entirely correct:

The GCC provided by MounRiver push correctly the FPU registers in the stack via software when you indicate -march=rv32imafc -mabi=ilp32f but this behaviour break the advantage of fast interrupt when hardware-stacked registers.

In fact, you can use hardware-stacked registers and FPU interrupt but don't expect much improvement between "WCH-FastInterrupt" and standard "interrupt"

If you're using FP in an interrupt handler you're probably doing things wrong.

[wilhe_jo]

Well, if you have a FPU the floating point operations aren't that expensive.
I don't see too many reasons why you shouldn't do floats in interrupts at all.

I mean, the difference is pushing some more registers...
It all depends on the architecture and the algorithms you need to implement.

But you're right.
A bazooka would be a bad tool to get a hole for a screw anchor into a wall.
OTOH, if you're tasked to quickly convert a house into dust, it may actually work in some regions of this world...

Btw, anyone knows if wch has some information on clocks per instruction?
The QingKeV4 manual misses these details...

73