STM32F429I-DISC1 with external memory

[ponyatov]

I'm trying to port Espruino (latest 2v25, going to merge fresh 2v26 next week) to STM32F429I-DISC1 Discovery board with on-board external SDRAM (IS42S16400J 64Mbit (8MB) SDRAM).

As first, I tried to integrate new HAL initialization code above (StdLib legacy) code from targets/stm32 & targetlibs/srm32f4.

Spent a very long time forced to build every tiny change from scratch with make BOARD=F429DISCO clean all as build scripts does not see small file changes.

But the main problem, I see that ExRAM partially works, as readings returns some random bit blocks, with some of bit groups increments one by one in series of reading in a loop.

[ponyatov]

It looks like merging StdLib and HAL code (code including USB HS and some peripherals on dev board) is not a good variant. I'm thinking about alternate fork with full HAL usage for platform-specific code, and fixed build using CMake and few adapted Python scripts (build_linker.py etc).

@gfwilliams How you think, it is a big work pile to rewrite targets/stm32 and other platform-specific code from StdLib to new HAL and CubeMX-generated startup?

Maybe someone already tried to extend Espruino memory with external RAM on other Cortex-M boards?

PS: Some months ago I also tried STM32L496 board with smaller external RAM, but it has dead USB so I moved it into a bedside box for a while. Maybe it were a same problem with unsupported USB HS which in turn requires some HAL-generated USB stack, and moving to HAL will run this devboard too.

[gfwilliams]

and fixed build using CMake

To be honest we've been using the current Makefile build for 10 years and it works pretty well as long as you know to rebuild when you change an include file or device. I feel like switching to CMake is likely to be a huge effort without that much real payback.

CubeMX-generated startup?

The problem with this as far as I know is that CubeMX really wants to initialise all the peripherals up front, which is the exact opposite of what you want with Espruino where the JS should initialise most of them?

Also presumably you'll need a new CubeMX file for each board you support?

I'm not sure I've seen what the latest ST HAL is like, so I can't really comment on how easy/hard it'd be.

I feel like if you've got the external RAM set up in jshInit and you do a normal firmware build in internal RAM, and you can peek/poke to that external RAM, you should then just be able to stick the jsVars array in there and you'll be sorted. It's just going to be getting that external RAM set up in the first place - but realistically once you know how to do it it's probably just a matter of poking a few registers.