More RAM!

So... STM32F103RC chips (as used in Espruino) are supposed to have 48kB of RAM.

However, I just tried this:

>peek32(0x20000000+(64*1024)-4)  
=2549694936
>poke32(0x20000000+(64*1024)-4,0)   
=undefined
>peek32(0x20000000+(64*1024)-4)  
=0

It kind of implies that there's more RAM there than you'd expect. On my chip, using a value higher than 64 crashes it, so it looks like there's 64kB.

I guess it's not unexpected - processor manufacturers don't use different dies for different processors. It's cool though - after I tried to get RD chips and couldn't, it looks like that's what we have anyway - they've just got RC stamped on the top!

Just to add, you can check out the flash too (be careful though as if you use the wrong address you can kill the bootloader!).

// On RHS
var adr = 0x08000000 + (512*1024) - 4; 
var f = require("STM32F1Flash");

// On LHS
>f.read(adr)                           
=4294967295
>f.unlock()
=undefined
>f.write(adr,42) 
=undefined
>f.read(adr)   
=42

So the chip I have here has 512kb of flash - TWICE AS MUCH as it's supposed to!

WOW Gordon, that's pretty cool. 16KB more is a good amount where it should be possible to complete my project. I can't wait to use it.

Sacha

Confirmed. Both checks are positv!

Sacha

Awesome. Now I've just got to figure out how much RAM I have at runtime - I already have an issue open for dynamic memory sizing: https://github.com/espruino/Espruino/issues/340

The problem is that if you get it wrong, the ARM hangs (on a segfault or something)... It'd be cool if someone could figure out a way of doing this.

Maybe it possible to detect the ARM Chip version itself without testing to write to memory ? When the chip is wrong "stamped" it could idetentify it self right ?

It seems not. I can't find a register for RAM, but there is one for flash - peek16(0x1FFFF7E0). This reports 256 even though 512kB is available :(

Arg. If it's not possible to detect without crashing, maybe you could do some peek and poke in WebIDE. Wenn the board is not responding. Ask for a reset and you know that it has failed.

Sacha

Just tested on my boards, both checks are positiv!

I tried the RAM check, it is positive for me too! The second check required a SD card which I dont have lying around at the moment.

@Alex - just paste the top 2 lines into the right-hand side of the Web IDE and click 'send to espruino' first...

That's all really promising! I just need to find a nice way of detecting at run-time though!

Ah yes, that one is positive as well. Sounds good! :)

o_o
Wow...

If anyone has any solutions for detecting the RAM automatically, I'd be really interested :)

I posted up here to see if anyone has any ideas:

http://stackoverflow.com/questions/23411824/determining-arm-cortex-m3-ram-size-at-run-time

The problem is that when you access something out of range, you get (probably) a BusFault interrupt, and I'm struggling to see a way to recover from it.

Somewhere there must be an example of doing it, but I can't find one.

By the way, you can also check if the RAM is Ok. It's possible that the chips were binned as the 'C' variant because there was a problem with the RAM or Flash higher up the address range:

for (var i=48*1024;i<64*1024;i+=4) {
  poke32(0x20000000+i, 0xAAAAAAAA);
  var v = peek32(0x20000000+i);
  if (v != 0xAAAAAAAA) console.log("Got "+v+" not 0xAAAAAAAA");
  poke32(0x20000000+i, 0x55555555);
  var v = peek32(0x20000000+i);
  if (v != 0x55555555) console.log("Got "+v+" not 0x55555555");
}

I tried this and it says =undefined after uploading it so I assume it was succesful.

More verbose check:

var success = true;
for (var i=48;i<64;i++) {
  console.log("checking:",i);
  for (var j=0; j < 1024; j+=4) {
    var dataPointer = i * 1024 + j;
    poke32(0x20000000+dataPointer, 0xAAAAAAAA);
    var v = peek32(0x20000000+dataPointer);
    if (v != 0xAAAAAAAA) {
      console.log("Got "+v+" not 0xAAAAAAAA");
      success = false; 
    }
    poke32(0x20000000+dataPointer, 0x55555555);
    var v = peek32(0x20000000+dataPointer);
    if (v != 0x55555555) {
      console.log("Got "+v+" not 0x55555555");
      success = false; 
    }
  }
}

if (success == true) {
  console.log("check was successful");
}

Great!

If anyone wants to do a compile with this, it's as easy as just changing the boards/ESPRUINOBOARD.py file to reflect the increased amount of RAM (and also tweaking the variable count upwards).

I'm still trying to find a nice way to check for memory without crashing if we find a chip with less RAM :)

It does crash (or stop outputting in any case) if I want to check from i = 0 but I'll assume that would be overwriting part of the code that's running..

@Alex: yes! The stack grows down from 48kB - so actually you shouldn't be able to go below 48 at all without causing some serious problems :)

Has anyone built and tried this out and could share the binary? I don't have a build environment set up yet.

In general, I'd worry about including functionally to use this extra ram in the default firmware, even it could be detected. It would be a Bad Thing if say, 5% of the chips had bad ram cells in that upper 16k, and the webide defaulted to flashing firmware that would try to use it (and brick an espruino whose owner might know what do). Imo, it's safer to make available a second version of each firmware image for the espruino board that would try to use the high 16.

It seems, for me at least, that

peek32(0x20000000+(64*1024)-4)

varies quite a bit. My first board reruns 1833295557 and my second returns 72728256 and my third board 822341633. However the flash test returns 4294967295 on all three Eespruinos.

Does it return bogus values after you poke something in there?
I think when the device starts up, unused ram can have random bits in it (until you put something else there)

poke32(0x20000000+(64*1024)-4,0x55555555);
peek32(0x20000000+(64*1024)-4);

I'd love to start playing with these extra 16kb of ram, but I can't seem to build working Espruino firmwares x_x.

Hi DrAzzy,

I would also love to use the additional 16kb. Gordon, please please build us a version that supports the additional 16kb. Thanks in advance.

Sacha

@Ducky: yes, the RAM contents will probably be random on startup. In its erased state, flash will be all 1s = 0xFFFFFFFF = 4294967295

I won't personally be supporting another build - it just gets too difficult really quickly - what about the people who've put the 96kB chip on, and then maybe I need separate versions with WIZnet support too?

It's really not that hard to set up a built environment - there's a thread on it here but at some point I'll try and document step by step what you need to do.

What would actually be better? Build instructions for a VM, or for a Raspberry Pi?

Instructions for setting it up on a linux system (not necessarily a VM). Not everyone has a Raspberry Pi

Hi Gordon,

It sounds a bit odd. What about a hardware hack to tell your firmeware during boot that we have a cpu with more RAM ? Like a jumper between 3.3v and A1 ? Or solder something to a unused/unsupported pin ?

Sacha