Advanced hack for more RAM (chip upgrade) #3792
Replies: 1 comment
-
Posted at 2014-03-15 by DrAzzy 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. Posted at 2014-03-15 by Jscott 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." Posted at 2014-03-15 by @gfwilliams 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 Posted at 2014-03-15 by Jscott 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). Posted at 2014-03-17 by @gfwilliams Great, I look forward to it. Which chip are you using? Posted at 2014-03-18 by RichTen 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. Posted at 2014-03-18 by RichTen Gordon, to answer your question earlier to JScott, we are using STM32F103RFT6 with 768 kB flash and 96kB RAM. Posted at 2014-03-18 by RichTen
Posted at 2014-03-18 by @gfwilliams 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 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 :) Posted at 2014-03-18 by RichTen 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. Posted at 2014-03-25 by Jscott
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!!! Posted at 2014-03-25 by @gfwilliams 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:
Posted at 2014-03-26 by Jscott 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,"history":11,"stackEndAddress":536909496,"flash_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 = { 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? Posted at 2014-03-26 by @gfwilliams 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 Posted at 2014-04-19 by Sacha 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 Posted at 2014-04-19 by DrAzzy 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. Posted at 2014-04-20 by @gfwilliams 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. Posted at 2014-04-20 by Sacha Empty reply ? Posted at 2014-04-20 by @gfwilliams Fixed now :) Posted at 2014-04-20 by Sacha Perfect Gordon, Please produce a version with the 96KB! Can´t wait buying this boards Sacha Posted at 2014-04-20 by Jscott 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. Posted at 2014-04-20 by DrAzzy 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 Posted at 2014-04-21 by mikewop 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. Posted at 2014-04-22 by @gfwilliams @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! Posted at 2014-04-23 by Sacha Hi Gordon, DrAzzy, Autodetection in Espruino would be very nice. I think i could solder the CPU to the board by my self. Maybe you can point me to the right place where i can buy a few STM32 Chips with 96KB. But i don´t want to build espruino myself everytime a fine new version comes out. My current wish is that Gorden has built in support, we have to solder it by our own until Gorden sells them too. Thanks Sacha Posted at 2014-04-23 by DrAzzy The part is STM32F103RGT6 or STM32F103RFT6 Digikey sells them individually, and they can be had on ebay too (the G is hard to find on ebay, but the F is not). They seem pretty readily available. Posted at 2014-04-23 by Sacha Thanks DrAzzy Posted at 2014-04-24 by @gfwilliams Ok, I've just made an issue for this here: espruino/Espruino#340 I don't know when I'll get around to it I'm afraid... Posted at 2014-04-24 by Sacha Hello Gordon, Thanks again. Sacha Posted at 2014-04-24 by Alex The chips you mentioned have a maximum clock speed of 36Mhz, do you overclock these to 72? Posted at 2014-04-24 by @gfwilliams @alex I'm not sure where you saw that - but I just checked the datasheet for 103F/G and the very first line says:
Posted at 2014-04-24 by Alex @gfwilliams, Mouser specs: http://no.mouser.com/ProductDetail/STMicroelectronics/STM32F103RGT6/?qs=9CYplWqnH7H2%252bxyt3bktHg== and the espruino one: EDIT: sorry, must be wrong on the mouser site, the datasheets on there say its 72Mhz as well. Nevermind my comment. Posted at 2014-04-24 by @gfwilliams Or straight from ST: http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF247494 I think Mouser have it wrong - it wouldn't be the first time ;) Posted at 2014-05-02 by Alex Hi Gordon, I was wondering (hoping) if you have any idea as to when we might expect an espruino 2.0 edition. With 2.0 I mean with one of the bigger chips mentioned in this thread. From your other posts I gather that you're running into boundaries for the firmware as well so I do see this to be the next step. That is ofcourse, assuming we cannot safely assume all current chips have 64kb ram and 512kb flash :). I'm planning to buy about 30 espruino's around July, so it would be awesome if those could be the new (future proof?) boards. If the CC3000 issues are ironed out probably 60 more around September. Here's to wishful thinking :). Posted at 2014-05-02 by @gfwilliams Hi Alex, I don't have any idea at the moment - it's really not that high on my priority list I'm afraid, and it depends a lot on distributors and the volume of boards that I sell. There's an optimisation that will make normal arrays of numbers twice as efficient, and there's another that will add another 20% more variables. They're all things that I think should take priority, as they benefit even existing users. The existing parts will be future proof. The whole point of Espruino is to provide a JavaScript interpreter that runs on cheap microcontrollers - I don't intend to start requiring more complex parts any time soon. I'm not really running into boundaries with the existing firmware either... I use some compile flags which means it only just fits, but that's intentional. I can get another 50kB if I need just by changing one character in the Makefile, and there's still plenty of room for optimisation in Espruino's innards too. It's really surprising how few people are actually hitting memory issues right now. You can actually do a hell of a lot with what's available, and I wonder how many projects would fit in 96kB that wouldn't fit in 48. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-03-15 by Jscott
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!
Beta Was this translation helpful? Give feedback.
All reactions