Bootloader_v6 doesn't work on restart

Software Development
1

** EDIT: SEE UPDATE BELOW**

Hi folks,

I’m attempting to use the new (unreleased) daisy bootloader_v6 to install a program to SRAM on my Patch by following this guide. The program loads and runs, but does not work once I unplug seed from my computer and reboot it.

I’ve done the following steps:

Setup:

  1. Checkout the “bootloader_v6” branch in libDaisy, and the latest master branch in DaisySP. Copy those folders into my project root directory (clone of daisy-projects).
  2. Run rebuild_all.sh from the root directory to build libDaisy and DaisySP.
  3. hold the boot button on seed, press the reset button, release boot to put Daisy in DFU mode
  4. Go to project directory. make program-boot to install the bootloader
  5. Add APP_TYPE = BOOT_SRAM to my project makefile

Installing the binary

  1. Build the program: make clean; make
  2. Plug a USB from my computer into seed’s USB port. This will power seed on.
  3. Press seed’s boot button immediately to extend the bootloader “grace period”. It will confirm by blinking the LED rapidly.
  4. Write the program to seed: make program-dfu. Program appears to write successfully. Output shows that program resides in SRAM:
Memory region         Used Size  Region Size  %age Used
           FLASH:          0 GB       128 KB      0.00%
         DTCMRAM:       16356 B       128 KB     12.48%
            SRAM:      131020 B       480 KB     26.66%
      RAM_D2_DMA:       16968 B        32 KB     51.78%
          RAM_D2:          0 GB       256 KB      0.00%
          RAM_D3:          0 GB        64 KB      0.00%
     BACKUP_SRAM:          12 B         4 KB      0.29%
         ITCMRAM:          0 GB        64 KB      0.00%
           SDRAM:      645716 B        64 MB      0.96%
       QSPIFLASH:          92 B      7936 KB      0.00%
arm-none-eabi-objcopy -O ihex build/Musubi.elf build/Musubi.hex
arm-none-eabi-objcopy -O binary -S build/Musubi.elf build/Musubi.bin
dfu-util -a 0 -s 0x90040000:leave -D build/Musubi.bin -d ,0483:df11
dfu-util 0.10

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2020 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Flash "
Downloading element to address = 0x90040000, size = 131020
Erase           [=========================] 100%       131020 bytes
Erase    done.
Download        [=========================] 100%       131020 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state

Observed behavior: The program runs as expected. However, once I disconnect the USB and reboot patch, the OLED screen is blank. The LED on seed repeatedly blinks in cycles of 2-3 slow blinks followed by 8-10 fast ones (the documentation says it would blink “SOS” if there were an error).

Any idea what the issue might be? It’s strange to me because the program successfully boots and runs immediately after it’s installed, but after I remove the USB connection and reboot, bootloader seems to not boot the program.

Thanks!

2

Update: I did some additional testing and it looks like it’s an issue with my program in particular (note that my program does work correctly when the binary is in the regular 128kb FLASH memory). I was able to get patch/Sequencer to build, run, and boot correctly by using the same steps above.

I’m wondering if there might be a conflict with the SRAM or QSPI space that my program uses and the space that the bootloader uses. For reference, my program contains the following:

static ReverbSc DSY_SDRAM_BSS  reverbScMaster;

void saveSettingsToQSPI(){
    size_t size = sizeof(settings_qspi);
    size_t address = (size_t)settings_qspi;
    patch->seed.qspi.Erase(address, address + size);
    patch->seed.qspi.Write(address, size, (uint8_t*)settings_ram);
}

void loadQSPISettingsToRAM(){
    memcpy(settings_ram, settings_qspi, sizeof(settings_ram));
}

Is it possible that I need to use a custom linker script to resolve these conflicts? Or maybe there’s some other sort of issue? I would appreciate any info on this, or how I could get the right debug output to diagnose the error.

1 Like
3

Hi @Evan, thanks for sharing.

I haven’t tried the bootloader yet, but was wondering if there is a way to upload using the ST-LINK programmer instead of DFU.

4

I’m curious as well, anyone know?

5

Solved my original issue; I’ll post the fix here for posterity. Turns out that the QSPI address space used by daisy bootloader conflicted with the QSPI space used by my program. I fixed it by changing the address space that my program uses:

// Note that Daisy can only erease data in blocks of 4kb, 32kb or 64kb;
// Arbitrarily chose to move  the address 10*64kb up.
const uint32_t BASE_QSPI_ADDR_SETTINGS = 0x90640000;
int16_t DSY_QSPI_BSS settings_qspi[SETTINGS_BUFF_SIZE];
int16_t settings_ram[SETTINGS_BUFF_SIZE];

// Copy the values in settings_ram (volatile) to settings_qspi (non-volatile)
void saveSettingsToQSPI(){
    size_t size = sizeof(settings_qspi);
    patch->seed.qspi.Erase(BASE_QSPI_ADDR_SETTINGS, BASE_QSPI_ADDR_SETTINGS + size);
    patch->seed.qspi.Write(BASE_QSPI_ADDR_SETTINGS, size, (uint8_t*)settings_ram);
}

void loadQSPISettingsToRAM(){
    memcpy(settings_ram, reinterpret_cast<void*>(BASE_QSPI_ADDR_SETTINGS), sizeof(settings_ram));
}
2 Likes