You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My Daisy Patch project is about to exceed the 128KB capacity of the internal flash memory, so I will need to use the bootloader to continue development. Unfortunately, Daisy Patch projects do not work correctly with the bootloader. At the very least, the display does not work at all. It's hard to say what else may or may not be working without doing further testing.
I added APP_TYPE=BOOT_QSPI to my project's Makefile. After flashing the bootloader using make program-boot and then uploading my app using make program-dfu, the Patch appeared to be unresponsive. But after doing a little serial debugging, it does appear as though my app is being loaded and is running more or less correctly, as far as I can tell. The encoder works, I'm able to read data from the SD card into SDRAM, etc. But the display does not work.
I also tried APP_TYPE=BOOT_SRAM, but the Patch is completely unresponsive. I imagine it might need a custom linker script, like the bootloader version of the Nimbus app for the Daisy Field.
I crated a new project using helper.py and added some display calls. When running from the internal flash, the program works as expected -- the text BOOTLOADER appears on the OLED, and signals are passed through from the inputs to the outputs.
But when I set APP_TYPE=BOOT_QSPIorAPP_TYPE=BOOT_SRAM, the audio callback seems to be working correctly, but the text does not appear on the OLED. So even in this very simple case, the Patch is only semi-functional.
Another observation: the external codec is also non-functional when using the bootloader. No audio is passed through channels 3 & 4. I suppose this suggests an issue initializing or communicating with peripherals external to the Seed board? Perhaps variables related to SPI communication are ending up in the wrong data sections?
I've been staring at the linker scripts and the .map files a bit, but I'm not really sure what I should be looking for.
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!
My Daisy Patch project is about to exceed the 128KB capacity of the internal flash memory, so I will need to use the bootloader to continue development. Unfortunately, Daisy Patch projects do not work correctly with the bootloader. At the very least, the display does not work at all. It's hard to say what else may or may not be working without doing further testing.
I added
APP_TYPE=BOOT_QSPI
to my project's Makefile. After flashing the bootloader usingmake program-boot
and then uploading my app usingmake program-dfu
, the Patch appeared to be unresponsive. But after doing a little serial debugging, it does appear as though my app is being loaded and is running more or less correctly, as far as I can tell. The encoder works, I'm able to read data from the SD card into SDRAM, etc. But the display does not work.I also tried
APP_TYPE=BOOT_SRAM
, but the Patch is completely unresponsive. I imagine it might need a custom linker script, like the bootloader version of the Nimbus app for the Daisy Field.I crated a new project using
helper.py
and added some display calls. When running from the internal flash, the program works as expected -- the textBOOTLOADER
appears on the OLED, and signals are passed through from the inputs to the outputs.But when I set
APP_TYPE=BOOT_QSPI
orAPP_TYPE=BOOT_SRAM
, the audio callback seems to be working correctly, but the text does not appear on the OLED. So even in this very simple case, the Patch is only semi-functional.The text was updated successfully, but these errors were encountered: