Out of FLASH memory!

Software Development
1

My daisy run out of flash to store my code!
compilation error :
./usr/lib/gcc/arm-none-eabi/9.2.1/…/…/…/arm-none-eabi/bin/ld: region `FLASH’ overflowed by 812 bytes

I’m wondering if I can use QSPIFLASH to store few functions (specially the one that don’t need to be fast)?

I’m used to speed optimisation, but not to space optimisation. Does anyone have any tips?

2

Yes! libDaisy has grown quite a bit, and with a lot of peripherals in use (USB, SD card, etc.) the memory can disappear pretty quickly.

We are very nearly ready to release our custom bootloader that will allow storing programs on the external flash chip with the following configurations:

  • Execution from AXI SRAM - allowing for binaries up to 512kB with no compromise in code performance. Only difference is that there is less on-board SRAM available within the program, but the 64MB external memory is still fully accessible).
  • Execution directly from external QSPI flash allowing for even larger programs if necessary. We are still tuning this for performance, but there is some performance loss compared to running on the internal memories right now.

The Bootloader can be programmed:

  • via DFU similar to how it is currently done over USB
  • by loading a .bin file onto an SDCard connected to the Daisy board
  • by loading a .bin file onto a USB drive connected to the Daisy’s external USB pins

We may add additional programming methods (including MIDI sysex, and qspk audio) in later versions.

Somewhat separate from the bootloader project we have recently started looking into having specific functions, be located in QSPI and executed either from the QSPI directly, or the ITCMRAM within the Daisy. This will likely see more action once the bootloader is released.

3 Likes
3

thanks for the good news!

1 Like
4

How is this bootloader project coming along? I was unable to find anything else about it with a search.

5

Hi @Evan,

We’ve got a little guide set up that goes over working with the bootloader.

You can build applications for it by adding the APP_TYPE=BOOT_SRAM (or BOOT_QSPI) flag to your Makefile.

The most recent version of the bootloader can be installed via the “Advanced” tab on the web programmer, or via make program-boot on the command line.

:slight_smile:

2 Likes
6

Sorry for necro-ing this thread, but I’m trying to use the bootloader via APP_TYPE=BOOT_SRAM, but it’s throwing an error when I try programming my daisy_sm. The link to the guide above doesn’t work. Where can I find this information?

7

And sorry for replying to my own reply.

https://github.com/electro-smith/libDaisy/blob/master/doc/md/_a7_Getting-Started-Daisy-Bootloader.md

8

Looking around for bootloader - SRAM threads I didn’t find an answer to my question so instead of creating a new topic, just adding it here as it is related to the original topic.

When having the bootloader programmed in flash and using it to load a program compiled with the APP_TYPE=BOOT_SRAM I wasn’t expecting the SRAM loaded program to be persistent on power cycling the DaisySeed.

My understanding is that the bootloader once programmed is persistent in the on board flash until it is replaced with some different code. The bootloader then either loads from bin file on some storage (USB, SD, QSPI flash) or from a host that can program the SRAM (volatile). As it is loading my program after a power cycle I would like to understand why the SRAM is not completely cleared and where my program is stored?

9

My understanding is that the following lines in libDaisy/core/Makefile puts the code in QSPIFLASH to be copied into SRAM at startup:

QSPI_ADDRESS ?= 0x90040000
…
ifeq ($(APP_TYPE), BOOT_SRAM)

LDSCRIPT ?= $(SYSTEM_FILES_DIR)/STM32H750IB_sram.lds
USBPID = $(DAISY_PID)
FLASH_ADDRESS ?= $(QSPI_ADDRESS)
C_DEFS += -DBOOT_APP
…
program-dfu:
dfu-util -a 0 -s $(FLASH_ADDRESS):leave -D $(BUILD_DIR)/$(TARGET_BIN) -d ,0483:$(USBPID)

1 Like