Need a guide on bootloader to flash to SRAM

Troubleshooting and Support
1

So I read the description: With the latest version of libDaisy, you should be able to flash the bootloader using the program-boot rule within any project.

But this is rather vague. What do I have to do exactly?
Where do I get the bootloader?

Is there a step by step anywhere?

thanks :wink:

2

The bootloader is included in libDaisy. The Makefile will know which commands to execute with this build target.

After that you need to specify APP_TYPE = BOOT_SRAM so the correct linker is used for the program to be placed in the SRAM region.

You can read more information here: libDaisy/doc/md/_a7_Getting-Started-Daisy-Bootloader.md at master · electro-smith/libDaisy · GitHub

3

thanks! but…sorry, being a beginner, there must be a simple thing that I am missing:

How do I run make program-boot target to flash the bootloader

and make program-dfu

using ctrl + P / tasks.json does not provide that.

I tried the following:

  1. changed Makefile to Target = program-boot
  2. flashed the daisy
  3. changed Makefile to Target = main, APP TYPE = BOOT_SRAM
  4. ctrl+P : program_dfu
  5. now it tells me Last page at 0x9005fa4f is not writeable

Memory region Used Size Region Size %age Used
FLASH: 0 GB 128 KB 0.00%
DTCMRAM: 27068 B 128 KB 20.65%
SRAM: 129616 B 480 KB 26.37%

4

You will need to activate the bootloader when trying to flash the SRAM build:

  • click reset button
  • see fading LED
  • while still fading click boot button
  • LED stays fading
  • bootloader is now activated and waiting for your SRAM flash

If you do not see the fading onboard LED after resetting the device you can be sure you have not successfully flashed the bootloader.

5

when I change the Makefile to Target = program-boot, it still flashes my app and not the bootloader.

therefore, when I hit reset, it will just reset my app.

6

make program-boot is a command you’ll have to execute manually from a commandline.

7

thank you, that was the missing link!

1 Like
8

but wow, my code is really slow now.
I am running OPT = -Ofast already,

are there things that can be done to speed things up?

My project relies heavily on big audio buffers for granular synthesis and reverb, plus a massive modulation matrix…

9

Are you using BOOT_QSPI? Switching to BOOT_SRAM app type typically should result in negligible performance difference vs internal flash applications whereas BOOT_QSPI apps will run noticeably slower.

Are you doing any specific memory allocations? You mentioned “big buffers”, presumably these are in SDRAM? What do your access patterns look like, are you doing any secondary buffering?

10

Hi!

I am using Boot SRAM.

My audio buffers are stored in SDRAM.

After I switched from Flash to SRAM, the program ran significantly slower.

I now turned my effect from stereo to mono, this helps, event though its a bit sad.

I am running a stutter(1 read), grains(8 reads), distortion(atan, srate-reducer, bitcrusher, ringmodulator), filter, delay(1 read) and reverb(7 reads).

Additionally there is a mod matrix with 3 mod sources/destinations/amounts per effect, which receives 4 CVs, plus internal lfo, envelope follower and adsr.

I assume reading buffers takes more cpu than I expected, and maybe I am giving the seed a bit more than it can chew haha :wink:

Now in mono, problems with speed are overcome, but now it crashes when I want to save a preset. But that should be adressed in another thread I assume. I am quite at a loss here, the same system works in another project, but here I am using 2 dimensional arrays for the first time…