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

Groups > comp.arch.embedded > #31537

Re: Another STM32F103 clone?

Show all headers | View raw

Rick C <gnuarm.deletethisbit@gmail.com> wrote:
> On Monday, January 16, 2023 at 8:43:58 PM UTC-4, anti...@math.uni.wroc.pl wrote:
> > Rick C <gnuarm.del...@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. 
> 
> Maybe I didn't read the thread well enough, but I thought this was just a way to generate addresses to test RAM, no?
            ^^^^^^^^^
Rather values to store.  Addresses are incremented in sequential way.

>  The only specific property I've seen is that it be "relatively prime" to the memory address space.  LFSR certainly can manage that.  Heck, a Grey code can probably manage that.  
> 
> With 17 bits, I can generate a PR sequence that is relatively prime to powers of 2 and of length 82,677.  
> 
> Am I missing something important? 

Don Y wrote that PRNG is generally usable for other problems.  But
for simulations and Monte Carlo computations statistical properties
are important.  Lousy PRNG-s are major source of erros in such
computations.

And yes, for memory testing good randomness is not needed.  As I
explained in other posts for testing _presence_ of memory I think
that already relatively simple counter is good enough.

-- 
                              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