FNIRSI GC-01 (CH32): Battery reading in 2.2beta5/board v.02

[PlasmaHH]

Starting with the desire to test 2.2b5 I went on a little detour regarding the battery level reading, since the device at the startup right away shuts down because it thinks the battery is low.

There seem to be multiple variants of the board around and I think I might have a version that doesn't support proper battery reading.

I wen to the readBatteryVoltage() function and modified it for me so that I can set the channel with a debugger. Then I ran the device once with 3.7V and once with 4.2V as the battery voltage. I cycled over the channels 0-17 and this is the result:

(I know its an stm32f103 clone but use stm32 in my notes everywhere)

Channel	Reading 3,7V	Reading 4,2V	STM32F103 PIN
0	580	580	14
1	581	580	15
2	581	580	16
3	581	580	17
4	580	580	20
5	580	580	21
6	580	580	22
7	581	580	23
8	581	584	26
9	578	575	27
10	576	578	8
11	581	582	9
12	580	580	10
13	581	583	11
14	581	581	24
15	574	576	25
16	1817	1818	TEMP
17	1535	1532	VREFINT

As one can clearly see, for none of the pins there is a difference.

I went to the device itself and checked that VDDA gets 3.3V but also PA0 which gets used for battery voltage check seems to get the 3.3V?

Now the idea of the usual VREFINT is that it is at 1.2V. The LQFP64 version uses VDDA as VREF and as such for VDDA of 3.3V the 1535 matches well enough given how unstable the devices voltage generally is.

All the other readings would amount to ~.468V which seems super strange (about one diode) so... what am I missing here? Even if the hardware is done in a way that it seems the input voltage or a fraction of it does not reach PA0, then I would at least expect a different adc reading than seen in the table. I checked GPIOA.CRL MODE0=0 and CNF0=0

Really not sure whats going on, thought I could fix that battery reading but I can't see a way to get a proper reading here...

[PlasmaHH]

Ok, after realizing it works on the 2.2b2 I compared all the peripheral registers of both versions and figured out that disabling adc_enable_temperature_vref_channel call does the trick... My guess here is that the VREFINT thing doesnt do the same as on th stm32 in the clone

[Gissio]

Thanks for the report!