ch32v307, risc-v minicore with ethernet

[SiliconWizard]

Well, not saving the FP registers in the hardware stacks is not an unreasonable decision. That's half of the space for a reasonable compromise. While FP instructions could be used in ISRs in some cases, not using them is not a huge deal.
And again, as Bruce said, if you absolutely want to use them, don't rely on the hardware stacks, just use the regular 'interrupt' attribute. Solved.

[brucehoult]

And again, as Bruce said, if you absolutely want to use them, don't rely on the hardware stacks, just use the regular 'interrupt' attribute. Solved.

If you're using upstream gcc, yes.

If you're using WCH's patched gcc then it depends on whether they implemented __attribute__((WCH-Interrupt-fast)) as "normal function that uses mret instead of ret (and possibly also doesn't save ra if another function is called) or as "__attribute__((interrupt)) that doesn't save ra,a0-a7,t0-t6".

A comment by martinribelotta appears to indicate it is the latter.

[SiliconWizard]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

[brucehoult]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

They're not going to duplicate the entire code generation apparatus, but just patch a little bit in the prologue and epilog generation. The question is which existing version their new attribute builds on.

[SiliconWizard]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

They're not going to duplicate the entire code generation apparatus, but just patch a little bit in the prologue and epilog generation. The question is which existing version their new attribute builds on.

I would have thought that keeping the original behavior of the 'interrupt' attribute itself, and only changing it for the new, vendor attribute 'WCH-Interrupt-fast' - would have made sense. Breaking existing behavior is bad.
Without it having to mean a particularly complicated patch. So that one could still use either and have either behavior. But what have they done, who knows. Where is the patch (if you or someone else has a link?)

[brucehoult]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

They're not going to duplicate the entire code generation apparatus, but just patch a little bit in the prologue and epilog generation. The question is which existing version their new attribute builds on.

I would have thought that keeping the original behavior of the 'interrupt' attribute itself, and only changing it for the new, vendor attribute 'WCH-Interrupt-fast' - would have made sense. Breaking existing behavior is bad.
Without it having to mean a particularly complicated patch. So that one could still use either and have either behavior. But what have they done, who knows. Where is the patch (if you or someone else has a link?)

FFS. It DOES NOT break existing behaviour. With the patch you have normal functions, __attribute__((interrupt)) functions, and __attribute__((WCH-Interrupt-fast)) functions.

The QUESTION is: which of the first two is the latter a modification of?

Clear enough?

[SiliconWizard]

I'm not sure I understand your reply regarding using the 'interrupt' attribute. Did the patched version change the behavior of the 'interrupt' attribute itself?
I'd have assumed they had only *added* a specific attribute (WCH-Interrupt-fast), but didn't change the existing 'interrupt' behavior, so that one could use either, even with their patched version, and the latter without any change compared to mainline gcc. Is it not the case?

They're not going to duplicate the entire code generation apparatus, but just patch a little bit in the prologue and epilog generation. The question is which existing version their new attribute builds on.

I would have thought that keeping the original behavior of the 'interrupt' attribute itself, and only changing it for the new, vendor attribute 'WCH-Interrupt-fast' - would have made sense. Breaking existing behavior is bad.
Without it having to mean a particularly complicated patch. So that one could still use either and have either behavior. But what have they done, who knows. Where is the patch (if you or someone else has a link?)

FFS. It DOES NOT break existing behaviour. With the patch you have normal functions, __attribute__((interrupt)) functions, and __attribute__((WCH-Interrupt-fast)) functions.

The QUESTION is: which of the first two is the latter a modification of?

Clear enough?

Not really. I'm sure it comes from a misunderstanding of what exactly each other means, adding to that the fact that you have worked on GCC, so some things may look obvious to you when they aren't necessarily to others.

What I was meaning by "existing behavior" is the behavior of mainline GCC when using the interrupt attribute with a RISC-V rv32imafc target. I'm assuming that it has a common behavior in all cases, unless you specify another attribute than the bare "interrupt" one. Maybe that's not exactly how things are implemented for RISC-V targets, so let me know if this isn't the case.

Going from there, my assumption was that if WCH's patched version behaves identically to mainline GCC when using the bare "interrupt" attribute, then it should not make any difference whether you use mainline GCC or their patched version, if using this attribute. That sounds logical to me. Maybe it isn't to GCC. Or maybe we weren't talking about the same thing.

You last question "which of the first two is the latter a modification of?" leaves me puzzled instead of being clear to me, but that's possibly because you have hands-on experience developing back-ends for GCC when I don't.
As a user - not a GCC developer - I would logically think that WCH would have piggybacked on the existing RISC-V back-end, leaving the "interrupt" behavior as is, and switching to their own behavior when specifying the "WCH-Interrupt-fast" attribute instead. So I don't understand the question. But that may again be because something extremely obvious to you in the way GCC back-ends are structured in general, and the status with the RISC-V one in particular, is not to me.

So without a detailed knowledge of GCC internals, my naive view is that if the "interrupt" attribute on their patched version doesn't exactly behave as the "interrupt" attribute on mainline GCC, then that's what I was calling "breaking existing behavior". The only thing that may be the missing piece here - again probably 100% obvious to you and not to me - is that the bare "interrupt" behavior may be dependent on the extra extensions WCH has defined (when using -march=rv32imacxw), while I'm sticking to "rv32imafc". If so, that would look a bit messy to me. If not, then I still don't get it, and so I'm probably dense. (Btw, I suppose their extension is "w", but what is "x"? or maybe it's "xw"? Oh and they don't seem to enable FP support in their example makefiles. Go figure.)

And with all that said, it looks like WCH still hasn't released the source code for their patch, unless I've missed it. At least that's what appears to be the case on their openwch github, with an unanswered ticket from some user. Which doesn't bode too well to me. But I'll stick to mainline GCC anyway. At least until they relase their patch. And if they have, I'll be glad to have a look. Popcorn time.

[brucehoult]

Not really. I'm sure it comes from a misunderstanding of what exactly each other means, adding to that the fact that you have worked on GCC, so some things may look obvious to you when they aren't necessarily to others.

Nothing to do with gcc specifically, just standard software development practices.

What I was meaning by "existing behavior" is the behavior of mainline GCC when using the interrupt attribute with a RISC-V rv32imafc target. I'm assuming that it has a common behavior in all cases, unless you specify another attribute than the bare "interrupt" one.

Yes, of course.

Going from there, my assumption was that if WCH's patched version behaves identically to mainline GCC when using the bare "interrupt" attribute, then it should not make any difference whether you use mainline GCC or their patched version, if using this attribute.

Yes, of course.

You last question "which of the first two is the latter a modification of?" leaves me puzzled instead of being clear to me, but that's possibly because you have hands-on experience developing back-ends for GCC when I don't.

Nothing to do with gcc, just standard software development practices.

As a user - not a GCC developer - I would logically think that WCH would have piggybacked on the existing RISC-V back-end, leaving the "interrupt" behavior as is, and switching to their own behavior when specifying the "WCH-Interrupt-fast" attribute instead.

Yes, of course.

Except it's not a choice between "interrupt" and "WCH-Interrupt-fast", it's a choice between both of those and normal non-interrupt C functions.

So I don't understand the question.

The question is: is "WCH-Interrupt-fast" more similar to standard C functions (just replace `ret` with `mret`), or is it more similar to "Interrupt"?

But that may again be because something extremely obvious to you in the way GCC back-ends are structured in general, and the status with the RISC-V one in particular, is not to me.

Nothing to to with gcc, just standard software development practices.

You don't write code from scratch if you can avoid it. You copy-and-paste existing code (bad), or add some if/then/else to existing code (good).

So without a detailed knowledge of GCC internals

No knowledge of gcc required, just standard software development practices.

if the "interrupt" attribute on their patched version doesn't exactly behave as the "interrupt" attribute on mainline GCC, then that's what I was calling "breaking existing behavior".

Of course. And of course it does not break existing behaviour, as I've said repeatedly. Why would it? That would be stupid.

The only thing that may be the missing piece here - again probably 100% obvious to you and not to me - is that the bare "interrupt" behavior may be dependent on the extra extensions WCH has defined (when using -march=rv32imacxw), while I'm sticking to "rv32imafc".

No. The I'm sure the only relevant WCH extension is the CSR bit that tells it to save ra,a0-a7,t0-t6 (or the implemented subset of those on the '003) before calling the interriupt handler in the standard way.

And with all that said, it looks like WCH still hasn't released the source code for their patch

I don't know. I haven't looked for it, and don't use their compiler.

That's why I'm speculating about which existing functionality (standard C function, or "interrupt" function) "WCH-Interrupt-fast" handling is more similar to, rather than stating the behaviour as fact.

[ali_asadzadeh]

Guys has any one done any example project with FreeRTOS, Ethernet and USB Device CDC combined? I'm trying to combine these, and I get lot's of crashes and headaches

[ali_asadzadeh]

Here the FreeRTOS and Ethernet port try, it would not do anything on Ethernet, see the modified  project, it would not even ping!

I have combined the FreeRTOS and Ethernet webserver examples, in order to do that I had to modify the
Delay_Ms and Delay_Us functions in debug.c file like this

void Delay_Us(uint32_t n)
{
    uint32_t i;
    for(i=0;i<p_us*n;i++);
}


void Delay_Ms(uint32_t n){
  vTaskDelay(n);
}

[jnk0le]

Code: [Select]

void Delay_Us(uint32_t n)
{
    uint32_t i;
    for(i=0;i<p_us*n;i++);
}
This is not going to work. Will be optimized away at any optimization level.

[brucehoult]

Code: [Select]

void Delay_Us(uint32_t n)
{
    uint32_t i;
    for(i=0;i<p_us*n;i++);
}
This is not going to work. Will be optimized away at any optimization level.

Adding asm volatile ("") as the body of the loop will prevent that.

But it's still a VERY VERY bad idea because the correct value of p_us will depend on the exact CPU, the optimisation level, the compiler being used, and the phase of the moon.

e.g. with current RISC-V gcc with -O{1,2,3} the body of the loop is:

Code: [Select]

.L3:
        addi    a5,a5,1
        bne     a5,a0,.L3
        ret

... but with -Os ...

Code: [Select]

.L2:
        bne     a0,a5,.L3
        ret
.L3:
        addi    a5,a5,1
        j       .L2

... which will have very different timing, possibly something like 5 cycles vs 3 per loop (3 stage pipeline, no branch prediction)

At the very least, write it in assembly language so you know what instructions are being run and with what scheduling. That avoids all but the first problem above.

[Sueco]

Hi all,

I've been playing around with the CH32V307VCT6 flash memory, so far I've been unable to execute code from the flash proper, but that might require some deep digging, should be doable since the BLE examples provided for the similar CH32V208 seem to use the full memory range. What I've able to do is take advantage of the extra flash beyond the  288KB max boundary by tweaking slightly the linker script, I added a new memory region:

Code: [Select]

FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 288K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32K
ROM (r) : ORIGIN = 0x00048000, LENGTH = 192K
Of course this could be easily altered to any of the available combinations 256K+64K, leaving 224K for ROM, etc

I removed .rodata from .text:

Code: [Select]

.text :
{
. = ALIGN(4);
*(.text)
*(.text.*)
*(.gnu.linkonce.t.*)
. = ALIGN(4);
} >FLASH AT>FLASH
And defined a new section .constants:

Code: [Select]

.constants :
{
. = ALIGN(4);
*(.rodata)
*(.rodata*)
. = ALIGN(4);
} >ROM
   
This results in all constants declared in all the code (including implicit constant strings used in printf) to be stored in NZW flash, freeing some space for code. This might be quite useful if a lot of constant non executable data is required for a particular application such as http server, LUTs, etc... It's so effective that I think it should be included by default in the example linker scripts. Unless this might result in something unexpected that I failed to foresee?

Just one oddity, there was some speculation about the absurdity of .data and .bss being allocated as >RAM AT>FLASH. Well I switched .data to >RAM and the program crashes, why I'm not sure as yet.

Of course if executing from FLASH at 0x800 0000 is possible I'd very much like to get the full 480K plus 320K of RAM, I'd probably accept slower execution in exchange for the extra resources, I'm thinking of something in the line of placing a jump to somewhere at 0x0800 0000+ right in the reset vector, but so far I've only got hard faults doing that.

[mikeselectricstuff]

Code: [Select]

void Delay_Us(uint32_t n)
{
    uint32_t i;
    for(i=0;i<p_us*n;i++);
}
This is not going to work. Will be optimized away at any optimization level.

for(i=0;i<p_us*n;i++) asm("nop");
will work

[HwAoRrDk]

Well I switched .data to >RAM and the program crashes, why I'm not sure as yet.

I'm not surprised. By removing "AT>FLASH" you just told it that the contents of .data don't need to be loaded and initialised from flash at startup. That is, all your global/static variables with default values won't have them anymore.

[brucehoult]

Well I switched .data to >RAM and the program crashes, why I'm not sure as yet.

I'm not surprised. By removing "AT>FLASH" you just told it that the contents of .data don't need to be loaded and initialised from flash at startup. That is, all your global/static variables with default values won't have them anymore.

That might work immediately after you download the app as openocd will literally write the default values into RAM. They'll be gone if you power off, of course, or maybe even if you reset, and even if reset doesn't nuke them, on a 2nd run they'll not be set back to initial values but whatever they ended up as.

[bingo600]

I just had a headscratcher with some new ch32v307 boards

I got a few of these boards - And they came with flash protection enabled from the factory.
https://www.aliexpress.com/item/1005004350410929.html

Since i was lazy and wanted to use DFU Programming , i had to do some trickery to solve that.

See here
https://www.eevblog.com/forum/microcontrollers/ch32v307-modbus-web-ui-firmware/msg5312677/#msg5312677

/Bingo

[LM2023]

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

Here you can find an excellent description of V20x and V30x versions that have "reconfigurable" ram/flash mapping:
https://github.com/cnlohr/ch32v003fun/issues/280
You just need to write to Option Byte Register (FLASH_OBR) to select how much flash is copied and remapped into sram at next reboot (its value is preserved in user option bytes flash region).

FLASH_OBR and other configuration registers are initialized at reset by reading the option byte flash region
(see "32.6 User Option Bytes" in CH32FV2x_V3xRM.PDF reference manual covering CH32F2xx, CH32V2xx and CH32V3xx).

Option Bytes can be rewritten at runtime (You need to "unlock" them by writing to specific registers, etc. see descriptions in 32.6.xx  ) and have a different format compared to the registers they remap to, usually you just use the WCH utility to
configure the option bytes and just compile and link your code based on the expected configuration, but it is also possible to implement a "self-configuring" firmware by having a bootloader that checks if FLASH_OBR has the expected mapping and if not, rewrites the Option Bytes and reset the chip so at next boot the mapping will be correct.
(i.e. you code the bootloader configured for the "worst case" configuration of only 32KB of R/W SRAM and map it in the first 192KB of R0WAIT flash, after is successfully pass the SRAM/R0WAIT flash configuration check, before initializing the actual application firmware it remaps stack, etc. to the actual application's memory mapping).

For CH32V307 (RC, WC or VC) you have 320KB sram and 480KB flash and the bits in FLASH_OBR select how much flash gets copied into sram that gets remapped as R0WAIT flash.

FLASH_OBR bit9,bit8	"accessible" SRAM size	"remapped" R0WAIT_FLASH size	"slow" flash size [N.B. starts at 0x0800 0000 + (R0WAIT_FLASH size)]
00	128KB	192KB	288KB
01	96KB	224KB	256KB
10	64KB	256KB	224KB
11	32KB	288KB	192KB

Edit: Got the register <--> option bytes dependency wrong, corrected it and added more details.

[John Celo]

Does this chip stack well against STM32H750 price/feature wise?

STM32H750 has ethernet MAC and roughly 3 eur a piece for 10 units.
ch32v307 are only slightly cheaper at low volumes (2.75eur a piece for 10)?

Or does ch32v307 have more fully featured ethernet implementation? Or something else?

[ataradov]

STM32H750 has ethernet MAC and roughly 3 eur a piece for 10 units.

Where are you getting it at that price? It normally goes for about $10 @ 10 pcs.

Ok, I see LQFP-100 version on LCSC for $3.3 @ 10 pcs.

If you can reliably get STM32 at this price, I'd go with STM32.  But I'm not sure how reliable is LCSC supply. And you are not getting it for $3 from Mouser or any other common distributor.