My Daisy Patch project is coming right along. However, in order to fit within the 128KB flash I have had to compile both my project and libDaisy at Os optimization level. I’m at the point where I am running out of processing headroom and I’d like to see how much I can gain by moving to O3.
It’s my understanding that I will need to use a bootloader to execute from SRAM. Is there an explanation or example of how to set this up for the Daisy Patch module? I’ve seen the example projects that enable the bootloader in the Makefile, but I’m not sure how one goes about getting their firmware onto the Daisy. A little tutorial would be excellent.
Adding APP_TYPE = BOOT_SRAM to my Makefile and rebuilding my project
Running make program-boot target to flash the bootloader
Running make program-dfu to copy my program to SRAM (and also QSPI flash)
All those steps complete successfully, but my application is never loaded. I get the 2.5 seconds of LED pulsing, and then nothing. I’ll try copying the BIN to the SD card.
No luck copying the BIN to the SD card. I’m not terribly surprised that it will take more than 10 minutes to get working, but I’m not quite sure what to try next.
One odd thing I noticed when building for SRAM is that it’s filling up the DTCMRAM, and not one of the larger RAMs like I was expecting.
Memory region Used Size Region Size %age Used
FLASH: 0 GB 128 KB 0.00%
DTCMRAM: 125508 B 128 KB 95.76%
SRAM: 122460 B 480 KB 24.91%
RAM_D2_DMA: 18464 B 32 KB 56.35%
RAM_D2: 0 GB 256 KB 0.00%
RAM_D3: 0 GB 64 KB 0.00%
ITCMRAM: 0 GB 64 KB 0.00%
SDRAM: 32 MB 64 MB 50.00%
QSPIFLASH: 0 GB 7936 KB 0.00%
This is what it looks like when I target the 128KB flash:
Memory region Used Size Region Size %age Used
FLASH: 122604 B 128 KB 93.54%
DTCMRAM: 0 GB 128 KB 0.00%
SRAM: 125508 B 512 KB 23.94%
RAM_D2: 18464 B 288 KB 6.26%
RAM_D3: 0 GB 64 KB 0.00%
ITCMRAM: 0 GB 64 KB 0.00%
SDRAM: 32 MB 64 MB 50.00%
QSPIFLASH: 0 GB 8 MB 0.00%
Is using up the DTCMRAM expected? Seems to defeat the point of using the bootloader if I am constrained to 128KB.
I just got to the “Custom linkers” section of the bootloader guide and it explains what’s happening to the DTCMRAM. Looks like I’m cutting it pretty close, assuming I can get the bootloader working at all.
I’ve done a bit of experimenting, and have found that the bootloader is working (at least partially) with the Daisy Patch. However, the display does not work when using the bootloader.
Since my application requires a bit of configuration after startup to make sound, it wasn’t obvious to me that my app was running. So I created a new Patch project using helper.py, and modified it to write a short string to the display.
When running without using the bootloader, the text appears on the display as you would expect, and inputs signals are passed through to the output.
When running via the bootloader, AudioCallback() is called and functions correctly, but the text does not appear on the display.
#include "daisy_patch.h"
#include "daisysp.h"
using namespace daisy;
using namespace daisysp;
DaisyPatch hw;
void AudioCallback(AudioHandle::InputBuffer in, AudioHandle::OutputBuffer out,
size_t size)
{
hw.seed.SetLed(true);
hw.ProcessAllControls();
for (size_t i = 0; i < size; i++)
{
out[0][i] = in[0][i];
out[1][i] = in[1][i];
out[2][i] = in[2][i];
out[3][i] = in[3][i];
}
hw.seed.SetLed(false);
}
int main(void)
{
hw.Init();
hw.display.WriteString("BOOTLOADER", Font_7x10, true);
hw.display.Update();
hw.SetAudioBlockSize(4);
hw.SetAudioSampleRate(SaiHandle::Config::SampleRate::SAI_48KHZ);
hw.StartAdc();
hw.StartAudio(AudioCallback);
while(1) {}
}
Hi @miminashi sorry you haven’t gotten a response, and thanks for writing up such a thorough report here, and on GitHub.
As far as I know, the bootloader should work with the Daisy Patch, but our team will look into it this week!
For the Nimbus (daisy field version) that uses the bootloader, we had to add a custom linker script. It might be worth giving that linker script a try on your Daisy Patch program, and seeing if it starts to work.
We’ll report back here, and on GitHub once we’ve done a bit of investigating ourselves
Thanks, Stephen. I believe I tried that linker script, as well as the SRAM and FLASH scripts from the libDaisy repo, and didn’t have any luck. I’ll try the Nimbus one again just to be sure.
Alright, we’ve confirmed there is an issue, and are working on a fix now.
The issue is that the pin used on the Daisy Patch OLED isn’t fully de-initialized after leaving the bootloader.
This results in the issues you’ve observed.
We should have an updated version of the bootloader that resolves this issue up soon!
I’ve copied this response to the github issue as well, and will respond in both places once the fix is published!
