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
Hi Daniel!
Are you referring to this page? I know there was one point when the link for that page was dead (or maybe certain link still is).
Yeah perfect. Thats the one. Thanks for the quick response. It’s weird. It must have been moved, the URL is almost the same as above (or another thread).
Thanks Takumi!
I found @shensley 's description above. Would this maybe be worth to add to the help?
I can’t find a ‘bootloader_v6’ branch. The closest I can dig out is ‘tct-plus-bootv6’. Is that it?
V6 is still incompatible with the Patch SM. I’m very sorry for the wait.
Just to confirm: tct-plus-bootv6 is the one to use?
Alright, sorry, I figured it out. Got confused with the info above and thought I’d need a separate branch.
I got it working and here are some findings on my Daisy Patch:
At first my OLED wasn’t working. After I removed anything fat/sd/usb_midi related it finally showed up. Haven’t done tests with bringing those back step by step.
If I try using boot_qspi by setting APP_TYPE = BOOT_QSPI in my make file I get this:
../DaisyExamples/libdaisy/core/Makefile:240: *** Unkown app type "BOOT_QSPI ". Stop.
dfu-util -a 0 -s 0x90040000:leave -D build/Midi.bin -d ,0483:df11
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 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/
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 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x90040000, size = 97516
Last page at 0x90057ceb is not writeable
make: *** [program-dfu] Error 74
One more question: Should the Daisy Seed work with an OLED screen using BOOT_SRAM if I wire it the same way the Daisy Patch is wired?
Any hints/thoughts on the above? Specifically the Last page at 0x90057ceb is not writeable? It would be really helpful to keep using DFU/USB upload for faster development.
@Takumi_Ogata @shensley maybe?
You should be able to. Are you running into an issue?
I had to pack up my OLED because of a move, so I can’t test right now (I should have access to it next week).
And for the second question, have you tried the QSPI example in DaisyExamples → seed?
The OLED on Seed question was more for future development.
I’ll try the QSPI example haven’t tried that. It’s also less important as my code now fully fits into the memory. Will check though.
My biggest issue is that the DFU/USB upload isn’t working and that I need to use the SD card for transfer right now.
Thanks for your help @Takumi_Ogata
Please feel free to start a new thread about the issue if you need to.
We would be happy to look at the code you got so far 