2v22 broke Nucleo F411

Hi, looks like 2v22 broke the Nucleo F411 build. Seems to work on 2v21.
Both my Espruino Wifi and Pico seems to work with 2v22, and those have the same / similar uC.

Nucleo on 2v21:

>reset(1)
Erasing saved code.
Done!
=undefined
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v21 (c) 2023 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>require("Storage").eraseAll()
=undefined
>process.memory
=function () { [native code] }
>process.memory()
={ free: 7379, usage: 44, total: 7423, history: 9,
  gc: 0, gctime: 7.37596428571, blocksize: 13, stackEndAddress: 536970128, stackFree: 30528,
  flash_start: 134217728, flash_binary_end: 134548632, flash_code_start: 134610944, flash_length: 524288 }
>process.env
={
  VERSION: "2v21",
  GIT_COMMIT: "8f3a9cb52",
  BOARD: "NUCLEOF411RE",
  RAM: 131072, FLASH: 524288, STORAGE: 131072,
  SERIAL: "51005f00-0f513534-39343936",
  CONSOLE: "Serial2",
  MODULES: "Flash,Storage,hea" ... "etworkJS,neopixel",
  EXPTR: 134522176 }
>process.memory()
={ free: 7379, usage: 44, total: 7423, history: 15,
  gc: 0, gctime: 7.37960714285, blocksize: 13, stackEndAddress: 536970128, stackFree: 30528,
  flash_start: 134217728, flash_binary_end: 134548632, flash_code_start: 134610944, flash_length: 524288 }

After update via the built-in STLink:

>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v22 (c) 2024 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>process.env
Uncaught [object Object]
 at line 1 col 8
process.env
       ^

Some basic commands work, but looks like even the simplest function call fails

>2+3
=5
>a="alma"
="alma"
>a+5
="alma5"
>b = {x:1}
={ x: 1 }
>b
={ x: 1 }
>b.x
=1
>print(b)
Uncaught [object Object]
 at line 1 col 1
print(b)
^
> 
>print('x')
Uncaught [object Object]
 at line 1 col 1
print('x')
^
> 
>LED1.toggle()
Uncaught [object Object]
 at line 1 col 5
LED1.toggle()
    ^
> 

I will try to dig deeper, haven't built the firmware yet :)

Update: looks like this https://github.com/espruino/Espruino/commit/29a243226ea2ec15a68f8aed9bd3c7ff736c185c is the issue. Sent a PR

It is quite likely just the DESPR_PACKED_SYMPTR bit. maybe on STM32 flash memory addresses don't start at zero like nrf5x so don't fit into the packed lower bits. Then the packed way still could be used, just with some base offset - maybe 0x08000000?

As I mentioned on the PR, those changes were made to reduce flash memory usage so we could continue to build for the board - ideally we don't just revert them all.

But I guess that's the issue @fanoush - although the other STM32 boards (the original Espruino board and Pico) work absolutely fine!

Just fixed the issue if you build again now - when the board didn't have a bootloader we were using 0x08000000 as the base address (although using 0 works too).

Looks like DESPR_PACKED_SYMPTR is not used on the Espruino Wifi or Pico. Only used in the original EspruinoBoard's build file (from STM32 boards). Or is it included from somewhere else?
Removing that fixes the F411 Nucleo.
Adding DESPR_PACKED_SYMPTR to Wifi's board file breaks that the same way.

For size the missing piece was really 'optimizeflags' : '-Os',. Had it in my board file, but not in the PR, my wrong.
The F411 Nucleo has the same amount of flash as the Espruino Wifi, so as long as the Wifi build fits, the F411 Nucleo build will fit too with plenty of free space because the official boards include a lot of libraries. Same goes for the Nucleo F401 and Espruino Pico pair.

@Gordon In the commit the modifications #'place_text_section' : 0x00010000, are on a commented out line :)

Now with those changes the ST-Link just refuses to flash the built binary into the Nucleo. Flashes a couple of times, and a "FAIL.TXT" appears on the Nucleo's drive saying The application file format is unknown and cannot be parsed and/or processed

This board file was working for the F411 Nucleo before saw your commit:

'build' : {
   'optimizeflags' : '-Os',
   'libraries' : [
     'NET',
     'GRAPHICS',
     'NEOPIXEL'
   ],
   'makefile' : [
     'WRAPPERSOURCES+=targets/nucleo/jswrap_nucleo.c',
     'DEFINES+=-DUSE_USB_OTG_FS=1',
     'DEFINES+=-DPIN_NAMES_DIRECT=1', # Package skips out some pins, so we can't assume each port starts from 0
     'STLIB=STM32F411xE',
     'PRECOMPILED_OBJS+=$(ROOT)/targetlibs/stm32f4/lib/startup_stm32f401xx.o'
   ]
  }

Plenty of free flash: PASS - size of 221120 is under 393216 bytes
And does work after flashing.

Looks like DESPR_PACKED_SYMPTR is not used on the Espruino Wifi or Pico

I know - pretty sure I checked the Pico with that flag added in though - as far as I can see the issue is the 0x08000000 base address only if there's no bootloader

@Gordon In the commit the modifications #'place_text_section' : 0x00010000, are on a commented out line :)

I know that! The important bit is the other line in builld_linker

For size the missing piece was really 'optimizeflags' : '-Os'

But that's on by default for RELEASE=1 already??

Now with those changes the ST-Link just refuses to flash the built binary into the Nucleo

How are you sending the file? It worked fine for my using st-util (STLink) which uses the binary.

I know you're fine on the F411, but the F401 would fail. Even now it's:

PASS - size of 372344 is under 393216 bytes

And I want to keep the F401 and F411 kind of similar if possible.

First things first, pulled the latest (3cc72f8c5), did a build, flash, and it works! Thank you!

Details below...

I know that! The important bit is the other line in builld_linker

Ah, OK, just wasn't sure you missed something. I'm not that deep into Espruino's internals.

But that's on by default for RELEASE=1 already??

Looks like for nRF and ESP make yes, but not for STM boards. After pull, with the latest arm gcc toolchain it's a bit over 370k just like you:

~/Espruino$ source scripts/provision.sh NUCLEOF411RE
Provision BOARDNAME = NUCLEOF411RE
Provision FAMILY = STM32F4
===== ARM
installing gcc-arm-embedded to Espruino/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin
Folder found
~/Espruino$ make clean && BOARD=NUCLEOF411RE RELEASE=1 make

...

bash scripts/check_size.sh bin/espruino_2v22.24_nucleof411re.bin
GENDIR not set, assuming 'gen'
PASS - size of 376968 is under 393216 bytes

 ...
 and
 ...
bash scripts/check_size.sh bin/espruino_2v22.24_nucleof401re.bin
GENDIR not set, assuming 'gen'
PASS - size of 376936 is under 393216 bytes

But changing to 'optimizeflags' : '-Os'

bash scripts/check_size.sh bin/espruino_2v22.24_nucleof411re.bin
GENDIR not set, assuming 'gen'
PASS - size of 202624 is under 393216 bytes

bash scripts/check_size.sh bin/espruino_2v22.24_nucleof401re.bin
GENDIR not set, assuming 'gen'
PASS - size of 202640 is under 393216 bytes

I know you're fine on the F411, but the F401 would fail. Even now it's:

The Nucleo F401 is fine - just checked the Nucleo's datasheet - it has an F401RE with the same half meg of flash as the Nucleo F411RE or the Espruino Wifi. "Only" the Espruino Pico has less flash. If the latest datasheet is correct. But I thought the same too :)

Changing 'optimizeflags' : '-O3', for the Wifi, fails that build too:

/home/akos/Espruino/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: bin/espruino_2v22.24_wifi.elf section `.text' will not fit in region `FLASH'
/home/akos/Espruino/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 99136 bytes
collect2: error: ld returned 1 exit status
make: *** [make/targets/ARM.make:3: bin/espruino_2v22.24_wifi.elf] Error 1

How are you sending the file? It worked fine for my using st-util (STLink) which uses the binary.

This was my mistake, just drag & dropped binary to the Nucleo's mass storage device. Did work before, but doesn't like the new start address. The fantastic STM32CubeProgrammer does work.

Ok, great! Sorry, my mistake - I'd forgotten there was an optimizeflags in the python file to override the defaults. I just put -Os in, and re-added NET/took off the PACKED_SYMPTR/etc

The binary offset of 0x08000000 is a bit of a pain. Being able to drag the firmware on is pretty useful though - so I've hopefully re-added it properly with a bit of explanation in there now

Just checked, it works!
Thank you!