Advanced hack for more RAM (chip upgrade)

Our group is experimenting with an extreme hack to increase the RAM on one of our Espruino boards. One of our engineers replaced the pre-installed Cortex chip with a pin-compatible one with more RAM. Being a software person myself, I'm looking for advice on how to reinstall the interpreter on such a board. Any input is appreciated. Thx!

Woah, if there's a pin compatible chip with more ram.... I gotta get me some of that!

Not sure about the flashing process, though.

Okay, that was me being stupid. There are two pages on the Espruino site about using the serial bootloader, which I assume is required since we swapped the chip out. Still curious about how to restore the Espruino boatloader after we're done. I gather this from the statement "Note: Espruino boards have a USB implementation of the STM32 bootloader protocol built in."

The bootloader is actually in the images you download, so if you use the instructions for serial flashing then it'll work fine.

Only issue is getting Espruino to recognise the extra memory. For that you'll have to change boards/ESPRUINOBOARD.py and then recompile... Otherwise it is quite straightforward.

Once again, thank you Gordon. You rock! This all makes perfect sense. Should have news in a few days on how it all went (everyone's gone for the weekend).

Great, I look forward to it. Which chip are you using?

I'm working with JScott on this hack, and we just want to confirm if either of the USART1 pins are considered a "default", or if we can wire up either USART1 pin for our USB-TTL cable. Does it matter which USART1 pin we use for this?

Also, can anyone confirm that the USART1 pins are 5V tolerant? My guess is that they are, but please share if you know this to be true. Thanks for all help and comments.

Gordon, to answer your question earlier to JScott, we are using STM32F103RFT6 with 768 kB flash and 96kB RAM.

Gordon, to answer your question earlier to JScott, we are using STM32F103RFT6 with 768 kB flash and 96kB RAM.

Use A9/A10 for the USART - I think the bootloader probably defaults to the non-alternate-function USART but I'm not sure - it'll be in the datasheet.

A9/A10 are 5v tolerant - just FYI anything that isn't is marked with 3.3 on this page: http://www.espruino.com/ReferenceESPRUIN­OBOARD

Personally I'd try flashing a 100% normal Espruino first to make sure you've got it all right. Then you can flash the modified one with the original flash image (which should work fine) - and then move on to the one that handles the extra RAM :)

thanks Gordon, that should get us to the next steps, and I'll let you know if we succeed, or blow ourselves up. It should work fine.

1. Just wanted say thank you Gordon for your help thus far.
   
2. Below is our progress, along with an issue I encountered near the end. So I need a bit of help.
   ---
   Remember that our goal was to have an Espruino board with more RAM. In summary, we mod an Espruino board to replace the MCU, modify ESPRUINOBOARD.py to specify the correct values, build the firmware, then install it via the serial bootloader.
   ---
   a. We have the STM32F103RFT6 chip with 96kB RAM on the Espruino board. This results in a board with no firmware.
   
   

b. We had to remove the bluetooth module to allow our TTL interface to work on USART1 A9/A10.

c. We setup the board with pins and jumpers so that we can enable the serial bootloader.

d. I put the board into bootloader mode and used the ST Flash Loader Demonstrator via VirtualBox to write the original firmware version 1v58; just to ensure that everything worked as before. I had better results with the Demonstrator and not with the stm32loader.py script.

e. One caveat was that afterwards, I had to use the USB-TTL setup to connect to the Web IDE, then issue a reset();. At this point, everything started to work normally and I could connect via the onboard USB port to run programs and flash firmware. Basically, the blue and red LEDs stayed dimly lit and the board remained "stuck" until I connected the Web IDE via the chip's USART interface and entered a reset(); command.

f. I pulled the 'cutting edge' latest firmware from Github, and modified ESPRUINOBOARD.py, along with a Makefile tweak to ensure that everything builds on my Vagrant/VirtualBox/linux instance. (Thx Forums for that setup!)

g. With my new binary, I used the stm32loader.py script to flash the modded firmware that has the new memory settings. Sadly, I get Verification FAILED after the writes. I can easily restore version 1v58 and it works; but the modded firmware won't install. Any ideas why the verification is failing? Do the nightly builds typically install fine; or do they just build?

Any help is appreciated. We're so close!!!
Thx!

Great!

e) Make sure you do a full erase with the ST Flash Loader - that might well fix any issues. I'd really advise just using the python flasher though - I use this all the time without issues and in fact all the boards are flashed with it at the factory.

g) Ahh, you're using the wrong command for the flash loader, so it loads to the wrong address and tries to overwrite the bootloader (and the bootloader won't overwrite itself).

Either:

• Put the board into USB bootloader mode (pulsing blue LED), and run ESPRUINO_1V3=1 make serialflash (this writes to 0x08002800, not 0x08000000)
  
• Run scripts/create_espruino_image_1v3.sh, which will create a full image (including bootloader) which can be written to 0x08000000 with whatever flasher that you want.
  

This was extremely helpful Gordon. Thank you!

It really helps to thoroughly understand the build scripts, make file, and build process. I have a much better understanding and was successful in one pass. I ran the script (against your latest release), then used the Python script and everything was perfect with no kludge.

The new processor works!!!

Now for my really stupid question/issue. When I do a process.memory(); I don't see much of a change. It outputs:

{"free":1781,"usage":19,"total":1800,"hi­story":11,"stackEndAddress":536909496,"f­lash_start":134217728,"flash_binary_end"­:134458912,"flash_code_start":134967296,­"flash_length":786432}

Here are the changes I made to ESPRUINOBOARD.py. Notice the doubled RAM, flash, and part number mods.

chip = {
'part' : "STM32F103RFT6",
'family' : "STM32F1",
'package' : "LQFP64",
'ram' : 96,
'flash' : 768,
'speed' : 72,
'usart' : 5,
'spi' : 3,
'i2c' : 2,
'adc' : 3,
'dac' : 2,
};

I noticed there is a "variables" setting under the info hash assigned to 1800. Should I change this to increase the number of available jsVars? Am I barking up the wrong tree here? What's a good number?

Ahh - yes, sorry - forgot to mention that :)

I've tended to manually set JsVars per device, because often you have different memory usage or want to leave a different amount of stack.

Each variable is 20 bytes, so 1800*20 = 36000 (leaving 12k for stack and statically allocated variables). I'd change to (96000-12000)/20 = 4200

Hi Jscot,

Any news on your project ? In my projects i allways fighting against the memory usage. I wonder if Gorden could produce a board with this or another CPU to at leased double the memory. I'm sure that Gorden will address advanced users who likes a supported board with more memory. I also think that this premium could have it's price. This could help building more income.

Without such an option projects/users with more memory need will tend to tessel.

Happy Easter

Sacha

I'm also wondering if this ever wound up working - I expect RAM usage to be a problem on several of my planned projects, and the thought of 4200 memory units makes me drool :-P

The chips don't look that expensive - I see them for under $10 shipped individually, and I'd gladly pay a $10 premium for a board with more RAM.

If this all worked, I'd be tempted to do it myself... I think I could solder the new chip on myself (with difficulty and tedium), but I'm less optimistic about getting the old chip off leaving the board in good condition.

There's no reason why it wouldn't work... I'll maybe see if I can get a batch of the new revision made with the G-spec chip (96kB RAM).

Just to add that it's possible that Espruino could be modified so that the same binary auto-detected the chip (within the F103 family) and used the correct amount of memory. That way different recompiles wouldn't be needed.

Having said all that, I have some plans that would really increase memory efficiency on existing chips. Making simple arrays 2x more efficient, and hopefully pushing the variable count up to 2250 from 1800 as well. I wonder if that's a better use of my time right now.

Empty reply ?

Fixed now :)

Perfect Gordon,

Please produce a version with the 96KB! Can´t wait buying this boards

Sacha

Chip auto-detection would be awesome!

The new chip on our boards has been incredible. With uglify magnification, we're currently at about 12KB of JS and growing. And the Espruino platform has been performing like a champ.

We still pay very close attention to number of objects, concise well-organized code, etc. to utilize every bit of additional RAM. Just because we have double the size, we aren't wasteful.

Still, it really demonstrates the power and coolness of this platform.

Also note that we're employing some techniques with the SD and eval() to "swap-in/out" JS functions/objects. I'm sure something similar could be accomplished with the module cache; be we needed a custom implementation. This technique has really maximized the RAM and capability.

Whoo!

Can't wait till the board with the G-spec part is available. Is that the one one step up from the version that Jscott used? (ie. STM32F103RGT6, with 96k ram 1m flash, vs the STM32F103RFT6 with 96k ram, 768k flash)

Jscott - glad to hear it's working out so well

I would also like to see an Espruino board with more "headroom", that is one of the reasons why I haven't bought one yet. The STM32F103RGT6 is about $3.50 more in small quantities on mouser.com, I'd gladly pay more for a board that has some room to grow, since I am planning to use Ethernet/Wifi and nRF24L01+ connectivity.

@DrAzzy yes, the G has 1MB, but F has 768kB - The F might be more sensible given that the flash will only be 1/3 used anyway though!