Hiya! Apologies for the delay in response.
We’ve got a PR up on libDaisy that adds a new version of the bootloader.
We’re still testing it a bit before we merge it, and make a new release, but it should resolve the post-bootloader GPIO issues that were causing your problems.
Building the app against this PR, and using the new bootloader (v6) can be done by:
- navigating to libDaisy, and checking out the
bootloader_v6 branch
- rebuilding libDaisy (
make clean && make)
- navigating back to your app, and rebuliding it.
- flash the new bootloader (either using
make program-boot, or using the Web Programmer with the new binary: libDaisycore/dsy_bootloader_v6.bin
- Uploading your app via the bootloader (using dfu, SD card, etc.) as usual.
We’ll continue doing some testing on our end, but then you should be good to go.
Also, fun-side-note: This version of the bootloader/libDaisy provides a way of jumping back to the daisy bootloader (and staying there without the timeout) from your application.
Hope it works, and let us know if you catch any other issues 
I’ve just tested APP_TYPE=BOOT_SRAM, and as far as I can tell everything is working as it should be – OLED, codec, SD card, the whole shootin’ match. Nice! I used the linker script from the Nimbus example for the Field since my project is a bit SRAM-hungry.
Hopefully I’ll have some time in the near future to add some features to my project to give the new bootloader more of a workout, but things are looking good for now.
Thanks!
1 Like
Oh excellent! Happy to hear you’re up and running!
The new bootloader seems to be working well for the most part. But I’m a bit confused about the startup behavior.
When I’m actively reflashing updates to my app, the bootloader will load the app automatically after the 3 second grace period. This is the behavior even after I have disconnected the USB and power cycled my rack. Each time I power cycle the module it takes 3 seconds before the app is loaded. But when I power on my rack the next day, it takes much longer for my app to be loaded – about a minute.
Is this expected?
@shensley, actually, the startup delay is 32 pulses of the LED. So, 32 seconds, I guess?
So this is definitely not expected.
I’ve used the v5 bootloader quite a lot, and never experienced it there. So I wonder if it’s new to the v6.
I don’t know how long between active-use, and when the long bootup time will start happening on your unit, but would you be able to try to recreate it with your setup and the v5 bootloader?
I don’t want you to have to waste a day waiting for it to misbehave, but it’d be helpful to narrow down whether it could be something funky with the new version, or possibly even a hardware defect on your Daisy.
Sure, it should be easy enough to test. I just flashed the v5 bootloader and the test app I used on the GitHub bug. I’ll power on the module in the morning and see if there is a startup delay.
The delay I’m seeing is very consistent, so that makes me think it’s probably not a hardware defect. But I guess we’ll see after we gather some more information.
The v5 bootloader shows the same behavior, with the same 32 second startup delay. The power-off interval to trigger the behavior is actually not very long, but it does vary a bit, from less than 30 seconds to a minute or two (it’s tedious to test). Perhaps an issue initializing some timer?
I think my issues are related to my custom linker script. It’s a slight modification of nimbus.lds from the Nimbus Field project. I think some memory sections are clobbering each other, but I’m not quite sure how to tell or how to correct it if that is the problem.
@shensley, have you tested that project with the v6 bootloader?
interesting, it being a consistent 32 second delay, and having it still function properly aside from that makes me feel like it’s not really a hardware issue.
So it being potentially linker based is a good thought.
I haven’t had a chance to test the nimbus with the v6 bootloader yet.
I plan on trying the v6 version with a few projects this week or next.
I don’t know how this would affect the v5 bootloader builds or not, but have you rebulit libDaisy on that v6 bootloader branch?
It’s possible some of the changes to initialization aren’t fully synced up with what the library expects now.
I’m somewhat less sure of it being a linker issue, because my simple repro app with the standard SRAM bootload linker script shows the same behavior.
I did rebuild libDaisy on the v6 branch. The v5 bootloader shows the same issue.
I’ll be curious to see how your project testing goes. I’ll keep poking at it, bit this is admittedly well outside of my wheelhouse.
My Patch-derived prototype module does not exhibit this weird delay behavior. It always starts right up after the 3 second delay. I would guess that there is some issue with the Seed installed in my Patch module, but I haven’t tested that theory. I’ll try swapping Seeds when I get the chance and see if the issue is with the Patch module or the Seed.
Hi Everybody,
I have a similar issue with a Patch SM prototype.
I made my own class where I use the SSD130x4WireSpi128x64Driver for the display and it works normally without the daisy bootloader.
Ive already tried the v6 bootloader without success. I noticed the dac loads correctly.
Could someone point me in the right direction?
Thank you.
Hey coutlasssupreme!
Would you be willing to share your custom class so that we can troubleshoot closer?
I think there could be an issue with the pins not being fully de-initialized after leaving the bootloader, which seems like the main trouble that started this thread.
Hi Takumi,
For sure,
Its the same as daisy_patch_sm.h and daisy_patch_sm.cpp but with the display code added:
// daisy_patch_sm.h added a variable
line 3//-------------------------->
#include "dev/oled_ssd130x.h"
line 252 //-------------------------->
OledDisplay<SSD130x4WireSpi128x64Driver> display;
// daisy_patch_sm.cpp added initialization
line 346 //------------------------------>
//SPI
OledDisplay<SSD130x4WireSpi128x64Driver>::Config display_config;
display_config.driver_config.transport_config.spi_config.periph =
SpiHandle::Config::Peripheral::SPI_2;
display_config.driver_config.transport_config.spi_config.pin_config.nss = D1;//cs//5
display_config.driver_config.transport_config.spi_config.pin_config.miso = Pin();//dc
display_config.driver_config.transport_config.spi_config.pin_config.mosi = D9;//sda //mosi//8
display_config.driver_config.transport_config.spi_config.pin_config.sclk = D10;//sck//6
display_config.driver_config.transport_config.pin_config.dc =A8; //dc //miso//A8
display_config.driver_config.transport_config.pin_config.reset =A9;//res//A9
display.Init(display_config);
The behavior is that if I dont use the daisy bootloader, everything works normally, but if I use bootloader 5, the display wont work. If I use bootloader 6, the display still doesnt work, but neither does the serial port.
I noticed the nimbus example for field does what I need: use the bootloader and the display at the same time, I also noticed its exactly the same display driver. I also tried using the linker file, but since Im not familiar with the process, I just copied it and included it in the make file. Could it be that im using a different set of pins for the display?
As a note, I need the bootloader so I can use SRAM as flash because my program is big.
Thank you for sharing!
I think this thread may provide more info for you about the display driver that we made: OledDisplay::Init with Daisy Submodule help
And yes, the pins connected to the OLED will be slightly different between Seed (what Patch and Field are powered by) and Patch SM.
I don’t know if this directly relates to your issue, but I have heard from another community member who used the bootloader + OLED + Patch SM before (thanks Danyl!) that display init in the bootloader may cause problem with OLED. SPI displays can be very particular about resets and inits. If you didn’t properly clear the screen sometimes, it could “stay stuck”. So that’s something to look out for in your code.
Hi Takumi, thank you for your response,
I can confirm bootloader 6 along with the field/nimbus linker script makes the display work on the Field, but not on the patch SM. Maybe because of this PR? Its a change that makes it possible to assign pins different from the default NSS MISO MOSI and SCLK pins because the default ones woulndt work on the Patch SM. Also another difference is that patch sm needs to use SPI2, which is also exposed in this new config.
Its stated in this post that some pins weren’t fully de-initialized after leaving the bootloader and bootloader 6 fixed that, could it be that once you specify new pins, which the patch sm needs, these are not taken care of? Or that using SPI2 also isnt handled?
These are the 2 ways of configuring the display and are the only difference between patch and patch sm in regards to the display.
//PATCH SM
OledDisplay<SSD130x4WireSpi128x64Driver>::Config display_config;
display_config.driver_config.transport_config.spi_config.periph =
SpiHandle::Config::Peripheral::SPI_2;
display_config.driver_config.transport_config.spi_config.pin_config.nss = D1;//cs//5
display_config.driver_config.transport_config.spi_config.pin_config.miso = Pin();//dc
display_config.driver_config.transport_config.spi_config.pin_config.mosi = D9;//sda //mosi//8
display_config.driver_config.transport_config.spi_config.pin_config.sclk = D10;//sck//6
display_config.driver_config.transport_config.pin_config.dc =A8; //dc //miso//A8
display_config.driver_config.transport_config.pin_config.reset =A9;//res//A9
display.Init(display_config);
//PATCH
OledDisplay<SSD130x4WireSpi128x64Driver>::Config display_config;
display_config.driver_config.transport_config.pin_config.dc = seed.GetPin(PIN_OLED_DC);
display_config.driver_config.transport_config.pin_config.reset = seed.GetPin(PIN_OLED_RESET);
display.Init(display_config);
Hi coutlasssupreme,
Thank you for the wait.
Version 6 of the bootloader indeed should have fixed any half-initialized pin issues. That’s why the Nimbus example is working on the Field.
However, v6 is not yet compatible with the Patch SM as of right now. We hope to update it soon so that you can get the OLED and the bootloader working with your Patch SM.
Hi Takumi,
I see the repo tags still show version 6, so it should still be incompatible with patch SM?
Can you guys point me to where the bootloader introduction page lives? Any link I found on the forum is dead. Would be great to have that in the regular help given that it has become quite necessary with the big libraries.
Thanks!
@shensley or @Takumi_Ogata