Another STM32F103 clone?

I have bought few Blue Pills on Aliexpress.  I expected to receive
boards with some of known clones.  But what I get does not look
like any clone that I have heard of:
 - Cortex M4 with no FPU
 - 32k RAM
 - 128k flash
 - set of devices like STM32F103C8T6

Chip seems to be resonable compatible, but I noticed notable
difference in I2C peripherial: bit 14 in OAR1 (own address register 1)
seem to be stuck at 1 (this is reserved bit which in original chips
is 0).  Peripherial address decoding seem to be partial, I can access
registers at address incremented by 0x100, 0x200 or 0x300.  Similarly,
RAM shows in 128k range, incrementing address by 32k modifies the
same memory.

Most clones seem to use Cortex-M3.  GD has GD32E103 with Cortex-M4,
but GD docs claim extra features, apparently not present in this chip.

Does anybody heard of/seen chip with features above?

-- 
                              Waldek Hebisch

antispam@math.uni.wroc.pl writes:
> Most clones seem to use Cortex-M3.  GD has GD32E103 with Cortex-M4,
> but GD docs claim extra features, apparently not present in this chip.
> Does anybody heard of/seen chip with features above?

https://www.cnx-software.com/2022/08/12/4-9-can-bus-module-features-gd32e103-cortex-m4-microcontroller/  ?

Paul Rubin <no.email@nospam.invalid> wrote:
> antispam@math.uni.wroc.pl writes:
> > Most clones seem to use Cortex-M3.  GD has GD32E103 with Cortex-M4,
> > but GD docs claim extra features, apparently not present in this chip.
> > Does anybody heard of/seen chip with features above?
> 
> https://www.cnx-software.com/2022/08/12/4-9-can-bus-module-features-gd32e103-cortex-m4-microcontroller/  ?

I normally do not use CAN, but when I enabled clock to CAN I was
able to write to CAN memory on my chip.  So CAN seem to be there.
In fact, usual F103C8 devices (SPI-s, I2C-s, UART-s, timers, DMA) do at
least something resonable, while other devices present in bigger
STM models and some clone chips seem to be not present (using
debugger to read registers give 0, attempt to write are ignored).

There is resonably strong hint that this is not a GD device, namely
JEDEC id is like in STM chips:

(gdb) x/8xw 0xE00FFFE0
0xe00fffe0:	0x00000010	0x00000004	0x0000000a	0x00000000
0xe00ffff0:	0x0000000d	0x00000010	0x00000005	0x000000b1

ROM table is:

(gdb) x/8xw 0xe00ff000
0xe00ff000:	0xfff0f003	0xfff02003	0xfff03003	0xfff01003
0xe00ff010:	0xfff41003	0xfff42003	0x00000000	0x00000000

Report in the net say that GD chips have GD id.  HK also is reported
to have its id.  Another clone has 0.

ATM I only found report about CS/CKS chips to present STM id.  However, there
is claim that CS and CKS are the same chip and my CKS shows non-STM id
(59, I do not have id table to say what it means).  OTOH id may be in flash,
in such case different chip batches may have different id-s...

-- 
                              Waldek Hebisch

antispam@math.uni.wroc.pl wrote:
> I have bought few Blue Pills on Aliexpress.  I expected to receive
> boards with some of known clones.  But what I get does not look
> like any clone that I have heard of:
>  - Cortex M4 with no FPU
>  - 32k RAM
>  - 128k flash
>  - set of devices like STM32F103C8T6
> 
> Chip seems to be resonable compatible, but I noticed notable
> difference in I2C peripherial: bit 14 in OAR1 (own address register 1)
> seem to be stuck at 1 (this is reserved bit which in original chips
> is 0).  Peripherial address decoding seem to be partial, I can access
> registers at address incremented by 0x100, 0x200 or 0x300.  Similarly,
> RAM shows in 128k range, incrementing address by 32k modifies the
> same memory.
> 
> Most clones seem to use Cortex-M3.  GD has GD32E103 with Cortex-M4,
> but GD docs claim extra features, apparently not present in this chip.
> 
> Does anybody heard of/seen chip with features above?

Info on internet mentions about 15 diffrenet Chinese manufacturers
cloning STM chips.  One of them is Flashchip.  My chip seem to
match id of FCM32F103C:

(gdb) x/2xw 0x1FFFF7C0
0x1ffff7c0:	0x46433332	0x0046103c

which appears in FSM32F103C migration note.  This is one of few
F103 compatible processors with M4 core, has 128kB flash.  The
migration note claims 20 kB RAM, my test indicate 32kB.  More
precisely, my test routine wrote to words from 0x20000400 to
0x20008000 and checked that written value is there.  This was
repeated for two different values.  So I have rather strong
indication that chip really have 32kB RAM (ok, test only covered
31kB, but first 1kB contained test program which apparently
run correctly).  Maybe manufactures claim 20kB because this
is all what STM32F103CB has.

-- 
                              Waldek Hebisch

On 1/9/2023 4:23 PM, antispam@math.uni.wroc.pl wrote:
> antispam@math.uni.wroc.pl wrote:
>> I have bought few Blue Pills on Aliexpress.  I expected to receive
>> boards with some of known clones.  But what I get does not look
>> like any clone that I have heard of:
>>   - Cortex M4 with no FPU
>>   - 32k RAM
>>   - 128k flash
>>   - set of devices like STM32F103C8T6
>>
>> Chip seems to be resonable compatible, but I noticed notable
>> difference in I2C peripherial: bit 14 in OAR1 (own address register 1)
>> seem to be stuck at 1 (this is reserved bit which in original chips
>> is 0).  Peripherial address decoding seem to be partial, I can access
>> registers at address incremented by 0x100, 0x200 or 0x300.  Similarly,
>> RAM shows in 128k range, incrementing address by 32k modifies the
>> same memory.
>>
>> Most clones seem to use Cortex-M3.  GD has GD32E103 with Cortex-M4,
>> but GD docs claim extra features, apparently not present in this chip.
>>
>> Does anybody heard of/seen chip with features above?
> 
> Info on internet mentions about 15 diffrenet Chinese manufacturers
> cloning STM chips.  One of them is Flashchip.  My chip seem to
> match id of FCM32F103C:
> 
> (gdb) x/2xw 0x1FFFF7C0
> 0x1ffff7c0:	0x46433332	0x0046103c
> 
> which appears in FSM32F103C migration note.  This is one of few
> F103 compatible processors with M4 core, has 128kB flash.  The
> migration note claims 20 kB RAM, my test indicate 32kB.  More
> precisely, my test routine wrote to words from 0x20000400 to
> 0x20008000 and checked that written value is there.  This was
> repeated for two different values.  So I have rather strong
> indication that chip really have 32kB RAM (ok, test only covered
> 31kB, but first 1kB contained test program which apparently
> run correctly).  Maybe manufactures claim 20kB because this
> is all what STM32F103CB has.

Build a random number generator with a long, relatively prime period.
Fill memory with successive values from that RNG.  (The primeness
ensures the pattern doesn't repeat at intervals that might be
related to the addressing decoder)

Reseed the RNG and run it, again -- this time checking values
read from sequential locations against the computed random number.
The first fault indicates an unexpected decoder error (i.e.,
the address space "wrapping" at that value), a fault in the
memory (I use this technique as a quick memory test) *or*
the end of physical memory.

[You can, of course, do this ad hoc with a pattern that you
create that has some relatively prime periodicity.  But, it
will likely have no subsequent value in your toolkit.]

Don Y <blockedofcourse@foo.invalid> wrote:
> On 1/9/2023 4:23 PM, antispam@math.uni.wroc.pl wrote:
> > antispam@math.uni.wroc.pl wrote:
> >> I have bought few Blue Pills on Aliexpress.  I expected to receive
> >> boards with some of known clones.  But what I get does not look
> >> like any clone that I have heard of:
> >>   - Cortex M4 with no FPU
> >>   - 32k RAM
> >>   - 128k flash
> >>   - set of devices like STM32F103C8T6
> >>
> >> Chip seems to be resonable compatible, but I noticed notable
> >> difference in I2C peripherial: bit 14 in OAR1 (own address register 1)
> >> seem to be stuck at 1 (this is reserved bit which in original chips
> >> is 0).  Peripherial address decoding seem to be partial, I can access
> >> registers at address incremented by 0x100, 0x200 or 0x300.  Similarly,
> >> RAM shows in 128k range, incrementing address by 32k modifies the
> >> same memory.
> >>
> >> Most clones seem to use Cortex-M3.  GD has GD32E103 with Cortex-M4,
> >> but GD docs claim extra features, apparently not present in this chip.
> >>
> >> Does anybody heard of/seen chip with features above?
> > 
> > Info on internet mentions about 15 diffrenet Chinese manufacturers
> > cloning STM chips.  One of them is Flashchip.  My chip seem to
> > match id of FCM32F103C:
> > 
> > (gdb) x/2xw 0x1FFFF7C0
> > 0x1ffff7c0:   0x46433332      0x0046103c
> > 
> > which appears in FSM32F103C migration note.  This is one of few
> > F103 compatible processors with M4 core, has 128kB flash.  The
> > migration note claims 20 kB RAM, my test indicate 32kB.  More
> > precisely, my test routine wrote to words from 0x20000400 to
> > 0x20008000 and checked that written value is there.  This was
> > repeated for two different values.  So I have rather strong
> > indication that chip really have 32kB RAM (ok, test only covered
> > 31kB, but first 1kB contained test program which apparently
> > run correctly).  Maybe manufactures claim 20kB because this
> > is all what STM32F103CB has.
> 
> Build a random number generator with a long, relatively prime period.
> Fill memory with successive values from that RNG.  (The primeness
> ensures the pattern doesn't repeat at intervals that might be
> related to the addressing decoder)
> 
> Reseed the RNG and run it, again -- this time checking values
> read from sequential locations against the computed random number.
> The first fault indicates an unexpected decoder error (i.e.,
> the address space "wrapping" at that value), a fault in the
> memory (I use this technique as a quick memory test) *or*
> the end of physical memory.

Long period is easy: I used a counter, actually 3 versions
of counter.  One version of counter used large increment which
ensured that all bytes were changing quickly (with low increments
there were long streches were high bytes were the same).

I also tried 3 lousy random number generators,
but in this problem I do not think that much more testing is
needed: AFAICS to pass my test with less memory chip would need
quite complicated address remapping working at bit level.
It does not make sense to put such circuit on the chip and
probably it is infeasible with chip technology.

I double that lousy random number generators will be of
much use in future.  But writing a good one is more work,
and even linking to some has disadvantage of size: memory
taken by test program was excluded from modification so
I wanted test program to be as small as possible.  My program
was 680 bytes which together with varibles and stack comfortably
fit in 1kB of RAM...


-- 
                              Waldek Hebisch

On Thursday, January 12, 2023 at 10:28:21 PM UTC-4, anti...@math.uni.wroc.pl wrote:
> Don Y <blocked...@foo.invalid> wrote: 
> > On 1/9/2023 4:23 PM, anti...@math.uni.wroc.pl wrote: 
> > > anti...@math.uni.wroc.pl wrote: 
> > >> I have bought few Blue Pills on Aliexpress. I expected to receive 
> > >> boards with some of known clones. But what I get does not look 
> > >> like any clone that I have heard of: 
> > >> - Cortex M4 with no FPU 
> > >> - 32k RAM 
> > >> - 128k flash 
> > >> - set of devices like STM32F103C8T6 
> > >> 
> > >> Chip seems to be resonable compatible, but I noticed notable 
> > >> difference in I2C peripherial: bit 14 in OAR1 (own address register 1) 
> > >> seem to be stuck at 1 (this is reserved bit which in original chips 
> > >> is 0). Peripherial address decoding seem to be partial, I can access 
> > >> registers at address incremented by 0x100, 0x200 or 0x300. Similarly, 
> > >> RAM shows in 128k range, incrementing address by 32k modifies the 
> > >> same memory. 
> > >> 
> > >> Most clones seem to use Cortex-M3. GD has GD32E103 with Cortex-M4, 
> > >> but GD docs claim extra features, apparently not present in this chip. 
> > >> 
> > >> Does anybody heard of/seen chip with features above? 
> > > 
> > > Info on internet mentions about 15 diffrenet Chinese manufacturers 
> > > cloning STM chips. One of them is Flashchip. My chip seem to 
> > > match id of FCM32F103C: 
> > > 
> > > (gdb) x/2xw 0x1FFFF7C0 
> > > 0x1ffff7c0: 0x46433332 0x0046103c 
> > > 
> > > which appears in FSM32F103C migration note. This is one of few 
> > > F103 compatible processors with M4 core, has 128kB flash. The 
> > > migration note claims 20 kB RAM, my test indicate 32kB. More 
> > > precisely, my test routine wrote to words from 0x20000400 to 
> > > 0x20008000 and checked that written value is there. This was 
> > > repeated for two different values. So I have rather strong 
> > > indication that chip really have 32kB RAM (ok, test only covered 
> > > 31kB, but first 1kB contained test program which apparently 
> > > run correctly). Maybe manufactures claim 20kB because this 
> > > is all what STM32F103CB has. 
> > 
> > Build a random number generator with a long, relatively prime period. 
> > Fill memory with successive values from that RNG. (The primeness 
> > ensures the pattern doesn't repeat at intervals that might be 
> > related to the addressing decoder) 
> > 
> > Reseed the RNG and run it, again -- this time checking values 
> > read from sequential locations against the computed random number. 
> > The first fault indicates an unexpected decoder error (i.e., 
> > the address space "wrapping" at that value), a fault in the 
> > memory (I use this technique as a quick memory test) *or* 
> > the end of physical memory.
> Long period is easy: I used a counter, actually 3 versions 
> of counter. One version of counter used large increment which 
> ensured that all bytes were changing quickly (with low increments 
> there were long streches were high bytes were the same). 
> 
> I also tried 3 lousy random number generators, 
> but in this problem I do not think that much more testing is 
> needed: AFAICS to pass my test with less memory chip would need 
> quite complicated address remapping working at bit level. 
> It does not make sense to put such circuit on the chip and 
> probably it is infeasible with chip technology. 
> 
> I double that lousy random number generators will be of 
> much use in future. But writing a good one is more work, 
> and even linking to some has disadvantage of size: memory 
> taken by test program was excluded from modification so 
> I wanted test program to be as small as possible. My program 
> was 680 bytes which together with varibles and stack comfortably 
> fit in 1kB of RAM... 

What's wrong with an LFSR?  They are very simple and have relatively good pseudo-random properties.  What, by your definition, is a "good" or a "lousy" RNG? 

-- 

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On 1/12/2023 7:28 PM, antispam@math.uni.wroc.pl wrote:
>> Build a random number generator with a long, relatively prime period.
>> Fill memory with successive values from that RNG.  (The primeness
>> ensures the pattern doesn't repeat at intervals that might be
>> related to the addressing decoder)
>>
>> Reseed the RNG and run it, again -- this time checking values
>> read from sequential locations against the computed random number.
>> The first fault indicates an unexpected decoder error (i.e.,
>> the address space "wrapping" at that value), a fault in the
>> memory (I use this technique as a quick memory test) *or*
>> the end of physical memory.
> 
> Long period is easy:

"Long" isn't the critical aspect.  What you want is a period that is
"relatively prime" wrt the likely address decoding.  So, a write of
"random value X" to location N can't appear at any LIKELY "bad decode"
or that address, elsehwere in the address space you are probing.

> I used a counter, actually 3 versions
> of counter.  One version of counter used large increment which
> ensured that all bytes were changing quickly (with low increments
> there were long streches were high bytes were the same).

A generic random number generator doesn't confine changes
to "local regions" of the value.  E.g.,
00000101
00001010
00010100
00101001
01010011
10100110
The goal being that bits/bytes don't repeat "regularly"
and that every bit sees some activity, in any set of
consecutively generated values.

> I also tried 3 lousy random number generators,
> but in this problem I do not think that much more testing is
> needed: AFAICS to pass my test with less memory chip would need
> quite complicated address remapping working at bit level.

Quite possible.  I was merely offering a tool that one can
fall back on in these sorts of problems.  I use this to
size and grossly test memory at POST; some number of passes
of writes with LATER read-verifies to ensure data is
retained and there are no decode failures (e.g., caused
by passing the end of physical memory).

I learned this trick from a friend from school, in the video
(arcade) game heyday -- you don't have a lot of resources
*or* time to do comprehensive tests.  Yet, you have to have
a reasonable level of confidence that the game is working
properly (folks get mad if you accept their coins and
don't deliver the product/experience!)

[When the memory being tested is a frame-buffer, the
displayed values resemble a textured "carpet" of colors]

> It does not make sense to put such circuit on the chip and
> probably it is infeasible with chip technology.
> 
> I double that lousy random number generators will be of
> much use in future.  But writing a good one is more work,
> and even linking to some has disadvantage of size: memory
> taken by test program was excluded from modification so
> I wanted test program to be as small as possible.  My program
> was 680 bytes which together with varibles and stack comfortably
> fit in 1kB of RAM...

The RNG isn't a big piece of code.  And, can be parameterized
to fit your future needs.

Rick C <gnuarm.deletethisbit@gmail.com> wrote:
> On Thursday, January 12, 2023 at 10:28:21 PM UTC-4, anti...@math.uni.wroc.pl wrote:
> > Don Y <blocked...@foo.invalid> wrote: 
> > > On 1/9/2023 4:23 PM, anti...@math.uni.wroc.pl wrote: 
> > > > anti...@math.uni.wroc.pl wrote: 
> > > >> I have bought few Blue Pills on Aliexpress. I expected to receive 
> > > >> boards with some of known clones. But what I get does not look 
> > > >> like any clone that I have heard of: 
> > > >> - Cortex M4 with no FPU 
> > > >> - 32k RAM 
> > > >> - 128k flash 
> > > >> - set of devices like STM32F103C8T6 
> > > >> 
> > > >> Chip seems to be resonable compatible, but I noticed notable 
> > > >> difference in I2C peripherial: bit 14 in OAR1 (own address register 1) 
> > > >> seem to be stuck at 1 (this is reserved bit which in original chips 
> > > >> is 0). Peripherial address decoding seem to be partial, I can access 
> > > >> registers at address incremented by 0x100, 0x200 or 0x300. Similarly, 
> > > >> RAM shows in 128k range, incrementing address by 32k modifies the 
> > > >> same memory. 
> > > >> 
> > > >> Most clones seem to use Cortex-M3. GD has GD32E103 with Cortex-M4, 
> > > >> but GD docs claim extra features, apparently not present in this chip. 
> > > >> 
> > > >> Does anybody heard of/seen chip with features above? 
> > > > 
> > > > Info on internet mentions about 15 diffrenet Chinese manufacturers 
> > > > cloning STM chips. One of them is Flashchip. My chip seem to 
> > > > match id of FCM32F103C: 
> > > > 
> > > > (gdb) x/2xw 0x1FFFF7C0 
> > > > 0x1ffff7c0: 0x46433332 0x0046103c 
> > > > 
> > > > which appears in FSM32F103C migration note. This is one of few 
> > > > F103 compatible processors with M4 core, has 128kB flash. The 
> > > > migration note claims 20 kB RAM, my test indicate 32kB. More 
> > > > precisely, my test routine wrote to words from 0x20000400 to 
> > > > 0x20008000 and checked that written value is there. This was 
> > > > repeated for two different values. So I have rather strong 
> > > > indication that chip really have 32kB RAM (ok, test only covered 
> > > > 31kB, but first 1kB contained test program which apparently 
> > > > run correctly). Maybe manufactures claim 20kB because this 
> > > > is all what STM32F103CB has. 
> > > 
> > > Build a random number generator with a long, relatively prime period. 
> > > Fill memory with successive values from that RNG. (The primeness 
> > > ensures the pattern doesn't repeat at intervals that might be 
> > > related to the addressing decoder) 
> > > 
> > > Reseed the RNG and run it, again -- this time checking values 
> > > read from sequential locations against the computed random number. 
> > > The first fault indicates an unexpected decoder error (i.e., 
> > > the address space "wrapping" at that value), a fault in the 
> > > memory (I use this technique as a quick memory test) *or* 
> > > the end of physical memory.
> > Long period is easy: I used a counter, actually 3 versions 
> > of counter. One version of counter used large increment which 
> > ensured that all bytes were changing quickly (with low increments 
> > there were long streches were high bytes were the same). 
> > 
> > I also tried 3 lousy random number generators, 
> > but in this problem I do not think that much more testing is 
> > needed: AFAICS to pass my test with less memory chip would need 
> > quite complicated address remapping working at bit level. 
> > It does not make sense to put such circuit on the chip and 
> > probably it is infeasible with chip technology. 
> > 
> > I double that lousy random number generators will be of 
> > much use in future. But writing a good one is more work, 
> > and even linking to some has disadvantage of size: memory 
> > taken by test program was excluded from modification so 
> > I wanted test program to be as small as possible. My program 
> > was 680 bytes which together with varibles and stack comfortably 
> > fit in 1kB of RAM... 
> 
> What's wrong with an LFSR?  They are very simple and have relatively good pseudo-random properties.  What, by your definition, is a "good" or a "lousy" RNG? 
> 

"lousy" RNG fails relatively simple statistic tests.  That includes
LFSR in its usual incarnations.  By chance, I have found paper
about random number generators which presents results of some
tests and proposes a different generator.  There is related site:

https://pcg-random.org

I am not sure if this one is really good, but the material they
present shows weaknesses of many others.

-- 
                              Waldek Hebisch

On 1/16/2023 5:43 PM, antispam@math.uni.wroc.pl wrote:
> "lousy" RNG fails relatively simple statistic tests.  That includes
> LFSR in its usual incarnations.  By chance, I have found paper
> about random number generators which presents results of some
> tests and proposes a different generator.  There is related site:
> 
> https://pcg-random.org
> 
> I am not sure if this one is really good, but the material they
> present shows weaknesses of many others.

You don't really care if the data is random.  In fact, it isn't,
and you don't want it to be (because you want to be able to
reconstruct the exact same sequence to VERIFY the contents of
the memory you've just filled with it!

What you are after is a non-repeating pattern that could mask address
decode errors or failed memory cells.

E.g., if you run the RNG three times, you would expect each bit in the
memory to have seen a '1' and a '0' value -- without having to verify
that assumption analytically.

"Truly" random numbers are hard to come by as they need a source
of entropy that can not be "influenced" by external conditions.

In the 60's and 70's, electromechanical pinball machines had a
"match" feature that rewarded "lucky" players with a free game
at the end of their game.  This was awarded if the last two digits
of the player's score "matched" the two digits "randomly"
generated by the machine.  As the rightmost of those digits was
always '0', this basically gave you a 1-in-10 chance of winning.

But, the "random number generator" was a sequencer mechanism that
was pulsed (advanced) by discrete events that happened during the
game.  E.g., every time the ball hit this target.  Or, that.  Or,
some combination.  As the ball travels at finite, observable
speeds, a player could predict (reliably!) what the current
mechanical position of that mechanism happened to be.  So, when
your current score happened to coincide with the current *setting*,
you simply TILTed the game (so no further action would influence
that mechanism).  And, "won" a free game!

If you visit gaming establishments (casinos), you will find
all sorts of losers^H^H^H users who are *sure* they know
how their machine works and are "priming" it for the next
payout:  "It's just about ready to hit!"  Or, someone
who walks away from a machine and watches the next player "hit"
a megajackpot:  "Oh, if I had just played one more coin..."

No, there's nothing you can do to influence the randomness
of the game.  If there was, the casino operator would be at
risk of that "secret" getting out and changing the returns
on his machines!

Part of the design process is to ensure you have a "truly"
random number generator as the rest of the machine is just
"decoration" to present that random number in a way that
convinces you of your luck (or misguided EFFORT).  Entertainment
value.  The machine already knows if you've won or lost long
before the results are "displayed".

[Amusingly, some machines try to play on the expectations
of the player unfairly.  E.g., displaying playing cards
as if the game followed the same rules as a deck of cards
(when, in fact, it doesn't; it could show 4 aces with
a probability of 1/100^4 instead of 1/(52*51*50*49) and
payout at some rate that doesn't represent the "real world"
odds of achieving that feat!).  How many U's in "sucker"?]