Hi,
How do I find out what version of libdaisy and oopsy Im running (MacOS)?.
Thanks,
Ade
Hi Ade!
You could check using git
on your machine and compare some numbers but itâs not the most user-friendly task.
Honestly, probably the best thing to do is download the version you want from GitHub.
Thanks @Takumi_Ogata ,
What git commands (and directory locations) should I be using to get the version numbers?
I can find what branch I am using (main | dev | bootloader-additions ) but want to see the version number. Unfortunately I recently updated to the latest version and bootloader has now stopped working via Oopsy.
Does this mean that you updated libDaisy and then things stopped working?
If so, you can reinstall âbootloader-additionsâ version of Oopsy and it should come with the version of libDaisy thatâll work. Please make sure to backup your patches and such before you do this.
Let us know if that works
Thanks @Takumi_Ogata .
Correct, I updated and things stopped working.
I tried your suggestion. Git checkout bootloader-additions returned "your branch is up to date with âorigin/bootloader-additionsâ. I continued with the ./install.sh and find that the bootloader is still not working for me.
I noticed that the PR number on this was 81 and I think the one I was using was 72? (I cant be sure). How do I version back to test prior versions?
Note: I am wanting to use bootloader-additions and C++ inserts and am fault testing MidiOut on my Seed2-DFM. Im not getting any Midi Thru via Oopsy.
Oopsy Bpatcher reports as per usual but does not physically complete the flash and the LED on the Seed stays dark. Performing the same without bootloading loads the seed fine but I need the extra space as Im using reverbs.
oopsy-verbose: "oopsy generated code"
oopsy-verbose: "oopsy compiling..."
oopsy-verbose: compiling...
oopsy-verbose: "generated code"
oopsy-verbose: "oopsy created binary 110KB"
oopsy-verbose: "oopsy flashing..."
oopsy-verbose: flashing...
oopsy-verbose: "created binary 110KB"
oopsy-verbose: "stdout dfu-util -a 0 -s 0x90040000:leave -D build/SpringReverb_v21_STIO.bin -d ,0483:df11"
oopsy-verbose: "dfu-util 0.10"
oopsy-verbose:
oopsy-verbose: "Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc."
oopsy-verbose: "Copyright 2010-2020 Tormod Volden and Stefan Schmidt"
oopsy-verbose: "This program is Free Software and has ABSOLUTELY NO WARRANTY"
oopsy-verbose: "Please report bugs to http://sourceforge.net/p/dfu-util/tickets/"
oopsy-verbose:
oopsy-verbose: "Opening DFU capable USB device..."
oopsy-verbose: "ID 0483:df11"
oopsy-verbose: "Run-time device DFU version 011a"
oopsy-verbose: "Claiming USB DFU Interface..."
oopsy-verbose: "Setting Alternate Setting #0 ..."
oopsy-verbose: "Determining device status: state = dfuIDLE, status = 0"
oopsy-verbose: "dfuIDLE, continuing"
oopsy-verbose: "DFU mode device DFU version 011a"
oopsy-verbose: "Device returned transfer size 4096"
oopsy-verbose: "DfuSe interface name: "Flash ""
oopsy-verbose: "Downloading element to address = 0x90040000, size = 112060"
oopsy-verbose: "Erase [ ] 0% 0 bytesErase [ ] 0% 0 bytesErase [= ] 7% 8192 bytesErase [== ] 10% 12288 bytesErase [=== ] 14% 16384 bytesErase [==== ] 18% 20480 bytesErase [===== ] 21% 24576 bytesErase [====== ] 25% 28672 bytesErase [======= ] 29% 32768 bytesErase [======== ] 32% 36864 bytesErase [========= ] 36% 40960 bytesErase [========== ] 40% 45056 bytesErase [=========== ] 47% 53248 bytesErase [============ ] 51% 57344 bytesErase [============= ] 54% 61440 bytesErase [============== ] 58% 65536 bytesErase [=============== ] 62% 69632 bytesErase [================ ] 65% 73728 bytesErase [================= ] 69% 77824 bytesErase [================== ] 73% 81920 bytesErase [=================== ] 76% 86016 bytesErase [==================== ] 80% 90112 bytesErase [===================== ] 84% 94208 bytesErase [====================== ] 91% 102400 bytesErase [======================= ] 95% 106496 bytesErase [======================== ] 98% 110592 bytesErase [=========================] 100% 112060 bytes"
oopsy-verbose: "Erase done."
oopsy-verbose: "Download [ ] 0% 0 bytesDownload [= ] 7% 8192 bytesDownload [== ] 10% 12288 bytesDownload [=== ] 14% 16384 bytesDownload [==== ] 18% 20480 bytesDownload [===== ] 21% 24576 bytesDownload [====== ] 25% 28672 bytesDownload [======= ] 29% 32768 bytesDownload [======== ] 32% 36864 bytesDownload [========= ] 36% 40960 bytesDownload [========== ] 40% 45056 bytesDownload [=========== ] 47% 53248 bytesDownload [============ ] 51% 57344 bytesDownload [============= ] 54% 61440 bytesDownload [============== ] 58% 65536 bytesDownload [=============== ] 62% 69632 bytesDownload [================ ] 65% 73728 bytesDownload [================= ] 69% 77824 bytesDownload [================== ] 73% 81920 bytesDownload [=================== ] 76% 86016 bytesDownload [==================== ] 80% 90112 bytesDownload [===================== ] 84% 94208 bytesDownload [====================== ] 91% 102400 bytesDownload [======================= ] 95% 106496 bytesDownload [======================== ] 98% 110592 bytesDownload [=========================] 100% 112060 bytes"
oopsy-verbose: "Download done."
oopsy-verbose: "File downloaded successfully"
oopsy-verbose: "Transitioning to dfuMANIFEST state"
oopsy-verbose:
oopsy-verbose: "stderr dfu-util: Warning: Invalid DFU suffix signature"
oopsy-verbose: "dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!"
oopsy-verbose:
oopsy-verbose: "oopsy dfu error"
oopsy-verbose: "dfu-util: Warning: Invalid DFU suffix signature"
oopsy-verbose: "dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!"
oopsy-verbose:
oopsy-verbose: "dfu error"
Many thanks. Ade
Do you happen to know which version of the bootloader your using, or at least where youâve flashed it from?
The latest branch of Oopsy is actually on dev
, but it should be synchronized with the bootloader-additions
. Either way, probably best to checkout dev
and then git pull
to make doubly sure itâs up-to-date.
Under certain scenarios, the DFU process may fail to restart the seed. Have you tried simply resetting it after flashing?
thanks @Corvus_Prudens,
I dont know which version of Bootloader im using I figured it was updated when I recently pulled the latest update off githib (via terminal). I just did checkout Dev and git pull said it was up to date. Still the same issue with the patch not loading. (Confirming the json has app_type"Boot_Sram" included.)
âsomâ:âseedâ,
âapp_typeâ: âBOOT_SRAMâ,
Do I have to restart Max and replace the bpatcher or something like that?
Also confirming that I am enabling bootloader on the Seed2 via the Daisy Web Programmer.
Thanks.
Hi @Corvus_Prudens,
Also confirming that resetting the seed after flashing continues to show the leds as dark (not flashing). I tried with a 108kb file as well, that will happily flash in standard mode, and it also does not flash in bootloader mode. (leds remain dark).
Ade
Hi @Corvus_Prudens,
Are you able to check the current version of Bootloader works with Seed2DFM ?
Im still not having any luck.
Many thanks,
Ade
Sorry for the delay in my response!
Do you have a minimal reproduction for the patch and hardware configuration that you expect to work with the bootloader? If not, Iâll create a basic one to re-verify the base functionality. From what I can see of your setup, it should work.
However, it sounds like it may be an issue with some of the objects used. The default linker for the bootloader is a bit different from the one for internal flash, so there may be a bad interaction with one of the objects in the patch and where itâs getting placed in memory.
Thanks Gabriel,
Ill package up a patch tonight and sent it to you
Adrian
Hey Gabriel,
I started testing last night and your comment about the bootloader linker treating some objects differently helped me narrow down the issue to a codebox operation which in one case is dealing with delays in a reverb.
They are being defined as :
Delay predelayLR(12336), delay1(88320), delay2(101519), delay3(119001), delay4(141176);
and then being read as :
early1 = delay1.read(0);
early2 = delay1.read(0.207771 * sizeLP, interp="linear");
early3 = delay2.read(0.357573 * sizeLP, interp="linear");
and being written as:
delay1.write(fixdenorm(diffuse1));
delay2.write(fixdenorm(diffuse2));
delay3.write(fixdenorm(diffuse3));
delay4.write(fixdenorm(diffuse4));
Is there anything in the nomenclature that may cause a difference between the two modes in using delays within a codebox that could cause this issue?
Many thanks,
Adrian