Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #31527

Re: Another STM32F103 clone?

From antispam@math.uni.wroc.pl
Newsgroups comp.arch.embedded
Subject Re: Another STM32F103 clone?
Date 2023-01-13 02:28 +0000
Organization Aioe.org NNTP Server
Message-ID <tpqfk0$77v$1@gioia.aioe.org> (permalink)
References <tpddc3$1565$1@gioia.aioe.org> <tpi7l4$qe3$1@gioia.aioe.org> <tpic2h$b04f$1@dont-email.me>

Show all headers | View raw


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

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-08 03:30 +0000
  Re: Another STM32F103 clone? Paul Rubin <no.email@nospam.invalid> - 2023-01-08 11:38 -0800
    Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-09 03:06 +0000
  Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-09 23:23 +0000
    Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-09 17:38 -0700
      Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-13 02:28 +0000
        Re: Another STM32F103 clone? Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-15 20:09 -0800
          Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-17 00:43 +0000
            Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-16 19:39 -0700
              Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-16 19:44 -0700
            Re: Another STM32F103 clone? Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-16 21:07 -0800
              Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-17 06:04 +0000
                Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-17 00:10 -0700
              Re: Another STM32F103 clone? David Brown <david.brown@hesbynett.no> - 2023-01-17 13:48 +0100
                Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-17 17:05 +0000
                Re: Another STM32F103 clone? David Brown <david.brown@hesbynett.no> - 2023-01-17 19:42 +0100
            Re: Another STM32F103 clone? Paul Rubin <no.email@nospam.invalid> - 2023-01-17 11:07 -0800
        Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-15 23:47 -0700
          Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-17 05:41 +0000
            Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-17 00:04 -0700

csiph-web