wch new chip

[ftg]

The "backdoor" for dumping firmware could be related to something like this?

[BadeBhaiya]

What a beast. Dual core too. Massive package too it seems. I just hope it's not a BGA

Any details about the ADC? If it's a fast one, we me really have a winner in our hands

[__george__]

The "backdoor" for dumping firmware could be related to something like this?

I don't think that this is the same, no. Ψ was talking about a backdoor, this seems like a legit vulnerability.

Funny thing is that this exact vulnerability described in the video exists(or existed at least) for LPC1343 as described in 3.3 section in this paper:
https://pure-oai.bham.ac.uk/ws/portalfiles/portal/115385806/fillyourboots.pdf

Its kind of a shame to copy vulnerabilities from other companies. You need to create your own unique ones

[PhilYoung]

it must be qfn

[Psi]

To be clear, I have no proof there is any backdoor in the chip.
But I would be extremely shocked if there wasn't.

[BrokeEngineering]

To be clear, I have no proof there is any backdoor in the chip.
But I would be extremely shocked if there wasn't.

American chip manus are notorious for leaving backdoors for NSA, CIA and the likes so I doubt it would be any different, the only difference is who has the backdoor

[bywqdq]

I think it is meaningless to deliberately add backdoors to chips of this level. What makes sense is to add backdoors to the CPU or PLC of the computer. I think the biggest problem with WCH is that there is no errata in the chip manual. I made an openFPGALoader for ch347, but it didn't work. The final reason was the chip version problem, and I bought a new version of the chip to solve the problem.

[artag]

If a chip mfg put in a back door, who for? The CCP? That would make sense, but all these chips are vulnerable to methods like VCC pulsing.

Anybody withj enough money / political power.
Just like any business.

[ftg]

I think it is meaningless to deliberately add backdoors to chips of this level. What makes sense is to add backdoors to the CPU or PLC of the computer. I think the biggest problem with WCH is that there is no errata in the chip manual. I made an openFPGALoader for ch347, but it didn't work. The final reason was the chip version problem, and I bought a new version of the chip to solve the problem.

Yeah it is annoying that they don't log the changes to the datasheets. The datasheets just get a new revision with stuff added or removed.

[tszaboo]

I think it is meaningless to deliberately add backdoors to chips of this level. What makes sense is to add backdoors to the CPU or PLC of the computer. I think the biggest problem with WCH is that there is no errata in the chip manual. I made an openFPGALoader for ch347, but it didn't work. The final reason was the chip version problem, and I bought a new version of the chip to solve the problem.

PCBAs are reverse engineered by taking off the parts and measuring them or identifying the part numbers.
PCBs are reverse engineered by milling them layer by layer.
And the programmable parts have a backdoor, where you can just read out the last piece of IP. Which might contain HASH keys for passwords or something else important.
It does matter, someone can copy your product with such little effort.

[alex_pribor]

Horribly slow flash memory.
for(uint32_t i=0;i<10000;i++){ } empty loop executed from FLASH 19.43ms
for(uint32_t i=0;i<10000;i++){ } empty loop executed from RAM 83µs
This code was run on a 400MHz 5F core. Loops cannot be placed in flash memory. This processor can only run fast if all code is placed in RAM, but there's not much memory for that.

[westfw]

Horribly slow flash memory.

Did you remember to turn on any caching that might be present?

I'm only asking because a major hobbyist vendor released some SAMD51 sotfware without turning on its cache (presumably assuming that it was "on by default" like the "flash acceleration" in earlier parts)...

[SiliconWizard]

We'll assume alex_pribor was compiling his empty loops at -O0 or -O1, otherwise they would just yield no code at all (current GCC 16.1).

For the 83µs execution time, that looks about right at 400 MHz. We'd need to know if it was compiled with -O0 or -O1: if -O0, that's very good performance considering what the compiled code is. If -O1, the loop should be only 2 instructions (L2: addi a5,a5,-1 ; bne a5,zero,.L2) and ~3.3 cycles per iteration would look rather average, unless branch prediction was not enabled.

For flash execution, it's very obvious he didn't enable instruction cache.

I suspect those 2 results were obtained with very baremetal code, to the point that neither branch prediction nor cache were enabled, and that would make sense as both need to be enabled explicitely using some CSRs.

[alex_pribor]

__attribute__((section(".highcode")))
void emptyLoopInRam(void){
    GPIOD->BSHR = GPIO_Pin_2;
   for(uint32_t i=0;i<10000;i++){
      __asm volatile("nop");
   }
    GPIOD->BCR = GPIO_Pin_2;      104uS
}

void emptyLoopInFlash(void){
    GPIOD->BSHR = GPIO_Pin_2;
   for(uint32_t i=0;i<10000;i++){
      __asm volatile("nop");
   }
    GPIOD->BCR = GPIO_Pin_2;         37,85mS
}

static void startTask(void) {
   while(1){
      vTaskDelay(50);
      emptyLoopInFlash();   
      vTaskDelay(1);
      emptyLoopInRam();
      
   }
}

Below is the dissemler code

emptyLoopInRam()
   33: GPIOD->BSHR = GPIO_Pin_2;
   0x200a204c  lui   a5,0x40011
   0x200a2050  addi  a5,a5,1024      # 0x40011400
   0x200a2054  li    a4,4
   0x200a2056  sw    a4,16(a5)
   34: for(uint32_t i=0;i<10000;i++){
   0x200a2058  lui   a5,0x2
   0x200a205a  addi  a5,a5,1808      # 0x2710
   35: __asm volatile("nop");
   0x200a205e  nop
   34: for(uint32_t i=0;i<10000;i++){
   0x200a2060  addi  a5,a5,-1
   0x200a2062  bnez  a5,0x200a205e <emptyLoopInRam+18>
   37: GPIOD->BCR = GPIO_Pin_2;
   0x200a2064  lui   a5,0x40011
   0x200a2068  addi  a5,a5,1024      # 0x40011400
   0x200a206c  li    a4,4
   0x200a206e  sw    a4,20(a5)


emptyLoopInFlash()
   41: GPIOD->BSHR = GPIO_Pin_2;
   0x000123a8  lui   a5,0x40011
   0x000123ac  addi  a5,a5,1024      # 0x40011400
   0x000123b0  li    a4,4
   0x000123b2  sw    a4,16(a5)
   42: for(uint32_t i=0;i<10000;i++){
   0x000123b4  lui   a5,0x2
   0x000123b6  addi  a5,a5,1808      # 0x2710
   43: __asm volatile("nop");
   0x000123ba  nop
   42: for(uint32_t i=0;i<10000;i++){
   0x000123bc  addi  a5,a5,-1
   0x000123be  bnez  a5,0x123ba <emptyLoopInFlash+18>
   45: GPIOD->BCR = GPIO_Pin_2;
   0x000123c0  lui   a5,0x40011
   0x000123c4  addi  a5,a5,1024      # 0x40011400
   0x000123c8  li    a4,4
   0x000123ca  sw    a4,20(a5)

[Xiamatsu]

CH32H417 
iCache  -  enable ?

[alex_pribor]

CACHE_STRTG_CTLR = 0x0F000003;

[SiliconWizard]

Ok, ICACHE seems enabled. But you seem to be using FreeRTOS? Not sure why it would make a difference here, but have you tried running the same without FreeRTOS?

[__george__]

CACHE_STRTG_CTLR = 0x0F000003;

>>> bin(0x0F000003)
'0b1111000000000000000000000011'

Based on what  Xiamatsu posted isn't that wrong? I see that bit 1 is set which should disable the cache.
Don't you need to enable the RAM/FLASH cache like this?
CACHE_STRTG_CTLR = (0x1 << 24) | (0x1 << 25);

[SiliconWizard]

Seems you're right - didn't notice this global disable bit (other bits, which enable cache for various memory areas, are all set to enable cache, so I didn't notice this global bit with reverse logic, and maybe alex didn't either).
So, yes, in the end, ICACHE, as we suspected, seems disabled.

Which is odd, as I would expect it to be enabled in the startup code. But again he seems to be using FreeRTOS and we don't know what the overall project looks like. I don't know if he uses the WCH SDK. I'm going to have a look at the SDK and see if they maybe forgot to enable ICACHE in their startup code. Or maybe he uses custom startup code that misses that as well.

Edit: I checked the startup code given in their SDK (startup_ch32h417_v5f.S).
It indeed lacks any configuration of this CSR, so it must have its default value, which has ICACHE disabled on reset (bit: ic_disable).
They do configure CSRs 0xBC0, 0xBC1, 0x804 and mstatus, but nothing about 0xBC2.

A bit shocking. I haven't tested the CH32H417 but was planning to, and I would probably have run into that quite quickly as well.
The fix should be to add this in startup_ch32h417_v5f.S, for instance after setting the 0xBC1 CSR:

Code: [Select]

/* Enable I-CACHE */
li t0, 0x0F000001
csrw 0xBC2, t0


[brucehoult]

SEdit: I checked the startup code given in their SDK (startup_ch32h417_v5f.S).
It indeed lacks any configuration of this CSR, so it must have its default value, which has ICACHE disabled on reset (bit: ic_disable).
They do configure CSRs 0xBC0, 0xBC1, 0x804 and mstatus, but nothing about 0xBC2.

A bit shocking. I haven't tested the CH32H417 but was planning to, and I would probably have run into that quite quickly as well.
The fix should be to add this in startup_ch32h417_v5f.S, for instance after setting the 0xBC1 CSR:

Code: [Select]

/* Enable I-CACHE */
li t0, 0x0F000001
csrw 0xBC2, t0


CH32Fun ftw...

https://github.com/cnlohr/ch32fun/blob/fd47378cb91161131d29a39a2a85084fda0322c4/ch32fun/ch32fun.c#L1312

Code: [Select]

#elif defined(CH32H41x)

void __ITCM setup_cache( void ) {
asm volatile(
" beqz a7, 3f\n"
"li a0, 0x1000003\n\
csrw 0xbc2, a0\n"
"li a0, 0x0\n\
csrw 0xBD0, a0\n" // supposed to clear cache, clearly not doing it
"li a0, 0x1000001\n\
csrw 0xbc2, a0\n"
"3:"
);
}

Called from handle_reset() if FUNCONF_ICACHE_EN which seems to default to true.

[alex_pribor]

Pomolo CACHE_STRTG_CTLR 0xF000001

CACHE_STRTG_CTLR 0xF000003 nS
emptyLoopInFlash 18200 nS
emptyLoopInITCM 100 nS
CACHE_STRTG_CTLR 0xF000001 nS
emptyLoopInFlash 101 nS
emptyLoopInITCM 100 nS

I tried setup_cache, but it causes HardFault_Handler for me.

FreeRtos has no effect. LVGL is now running fast. A 320*240 (spi) screen redraws in about 100 ms.
There's one odd thing: I already tried setting CACHE_STRTG_CTLR to 0xF000001, and the emptyLoopInFlash execution time increased. Now it's running fast. In general, the Mounriver Studio + WCH-LinkE combo is quite a finicky one. There are times when you need to disconnect the WCH-LinkE and then reconnect it to USB. Sometimes you need to reset the processor by disconnecting the power for a few seconds, but the reset pin may not help.

[__george__]

I also did some experiments today using the 417 dev board and the Mounriver Studio and the results seem to be the same as alex_pribor.
The empty loop took:
~100μs in ITCM
~18ms in FLASH with cache disabled
~100μs in FLASH with cache enabled

Also I second what he said about the Mouriver Studio, it is quite bad. I run it in a Windows VM and the behavior is very inconsistent. Multiple times I had to disconnect the LinkE (which also provides power) just to run the program. Other times it just runs after downloading. Debugging seems to work sometimes as well.

They provide toolchains and debugger for linux, if I find some time I will give it a try to see if it is a more consistent setup.

[SiliconWizard]

With that said, Mounriver or not, if you use WCH SDK (which Mounriver probably uses), as I mentioned, the default startup code they provide does not enable ICACHE, which is a bit surprising and explains why alex ran into this issue and why I probably would have too when first evaluating this chip.

https://github.com/openwch/ch32h417/blob/main/EVT/EXAM/SRC/Startup/startup_ch32h417_v5f.S

Digging a bit in their SDK, the only example they provide that enables ICACHE in the startup code is this particular example (EXAM/CPU/ICache):

https://github.com/openwch/ch32h417/blob/main/EVT/EXAM/CPU/ICache/Common/Startup/startup_ch32h417_v5f.S

Why they decided not to enable ICACHE in their "default" startup code, who knows. Maybe they had a specific reason, although I can't see a single reason to make that default.

We may have the beggining of a lead to their rationale with this issue: https://github.com/openwch/ch32h417/issues/7

It would seem that most of their examples copy code to RAM rather than enable ICACHE and run from Flash. Your bet is as good as mine, this issue has been open since January.

[westfw]

I wonder if enabling the cache can cause coherency problems with all that code that is copied to RAM?
Sometimes (frequently?) writing instructions to cached memory, and then expecting to run that code, can require "advanced" manipulation of the cache controller.

Some of you are not being careful with either your prefixes or your optimizations.
Running a loop 10000 times in 100ns (nanoseconds) implies that the loop has been optimized away.
100us (microseconds) is a much more reasonable time.
19ms (milliseconds) means something is seriously wrong (a 16MHz AVR does about 3ms)

[__george__]

I wonder if enabling the cache can cause coherency problems with all that code that is copied to RAM?
Sometimes (frequently?) writing instructions to cached memory, and then expecting to run that code, can require "advanced" manipulation of the cache controller.

Some of you are not being careful with either your prefixes or your optimizations.
Running a loop 10000 times in 100ns (nanoseconds) implies that the loop has been optimized away.
100us (microseconds) is a much more reasonable time.
19ms (milliseconds) means something is seriously wrong (a 16MHz AVR does about 3ms)

I think that you read that wrong westfw, we are not talking about nanoseconds here, we are talking about microseconds(μs). As you say 100 microseconds are expected and this is what we are seeing.

This is my disassembly section for the nop loop:

Code: [Select]

1002a: 0001        nop
1002c: 17fd        addi a5,a5,-1
1002e: fff5        bnez a5,1002a

3 instructions per iteration. 2.5ns clock cycle (since it is 400Mhz) and 10000 iterations.  2.5 * 10000 * 3 = 75000ns or 75 microseconds only for the loop so ~100 microseconds indeed seems right.

With that said, Mounriver or not, if you use WCH SDK (which Mounriver probably uses), as I mentioned, the default startup code they provide does not enable ICACHE, which is a bit surprising and explains why alex ran into this issue and why I probably would have too when first evaluating this chip.

Mouriver is just the IDE, and for some reason they decided to build all their samples based on this. The SDK is part of the chip package which has the samples. I just noticed by the way that the one that I downloaded from their website is actually outdated compared that you one that you shared in github, so thanks for sharing!