Since I ran out of code space, I went for installing the bootloader and executing from sram. Things worked for a while but lately dfu-util fails to erase qspi flash when programming. An excerpt follows:
Device returned transfer size 4096
Warning: Overriding device-reported transfer size
DfuSe interface name: "Flash "
Downloading element to address = 0x90040000, size = 299848
Erase [ ] 0% 0 bytesdfu-util: Error during special command "ERASE_PAGE" get_status
Sometimes erasing works for a bit (say 20%) and then it breaks as above. The curious thing is that once in say 20 times, works. The even more curious thing is that the online daisy programmer manages to erase and program the same firmware with a success rate of 100%. The problem however with this approach is that I cannot run it as part of my build/program automation script.
I am really curious what the differences between dfu-util and the online programmer are. Do you guys have any alternative tool for dfu downloading? I am using dfu-util 0.11 on ubuntu 22.04.
I managed to make it work by patching dfu-util and increase the timeout used by dfu_get_status(). But it still shows a problem with the bootloader. What is the bootloader actually doing?
I just want to clarify the issue that youāre encountering.
The main problem was not being able to erase qspi flash 100% of the time, but now you are able to with the workaround of increasing the timeout used by dfu_get_status().
Could you tell me more detail about the problem with the Daisy bootloader that youāre still seeing? Thanks!
The problem with the bootloader that Iām still seeing is that while erasing, it fails to respond in a timely manner to get dfu status requests and since dfu-util has a hardcoded timeout of 5 seconds, it means others will run into this issue as well when executing from SRAM.
So, even though I patched dfu-util and got things working, the original problem with the bootloader remains.
P.S: why not make the bootloader sources open? Iām sure many would like to participate in improving or fixing bugs.
I think thereās a chance this may be a versioning issue. Are you able to try with dfu-util v0.9 or v0.10? The bootloader was developed specifically with v0.9. Since the bootloader erases in blocks of 4096 bytes, the process should not take more than a few hundred milliseconds at most (unless thereās something wrong with the QSPI chip), so itās not a fundamental limitation.
Hello Takumi. I get into very similar if not to the same problem. Somehow my daisy patch_sm become frozen after I tried to start it from the external power source. The sequence on re-start started to become unusual also: first delay for several seconds and then going into the dfu mode for several seconds and then freez. I was using a fresh Bootloader v.6 in SRAM, also storing some data in QSPI that should be loaded on start-up. Trying to re-upload my code showed this:
Erase 0% 0 bytesdfu-util: Error during special command āERASE_PAGEā get_status
To be honest I didnt find how to edit dfu-util, the method benishor described. I am using VS code. So my sequence, what I tried to do to fix:
uploaded blink example via st-link to the regular FLASH memory (to clear it from the bootloader)
re-uploded bootloader via usb sucessfully
tried then to upload my program. First time I get a sucess my code was running on the module. Then I again freez the module while starting it from the external eurorack power source. I repeat same sequence with re-uploading bootloader but now after that I ending up with same freez status as on beging: delay at start, then short dfu mode and freez. Reseting, re-uploading bootloader doesnāt help. I canāt even upload a code now. Please help.
That what I see now when trying to upload my code:
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading element to address = 0x90040000, size = 140956
dfu-util: Last page at 0x9006269b is not writeable
make: *** [program-dfu] Error 64
Hi, not sure if this is in time to help you, but I just ran into a very similar situation, with the several-second delay before starting either the Blink sample or the Daisy Bootloader.
And I got the exact same āError doing special commandā¦ā
I was apparently somehow able to get it working again by using the STLINK-V3MINI and using the STM32CubeProgrammer, doing a āchip eraseā (it didnāt seem to immediately fix it but then after I re-tried the whole booting to the ST bootloader, downloading the Daisy Bootloader cycle one last time, it started working again.
Annddā¦ It just randomly somehow got back to this ābadā state, Iām pretty sure it was running fine last night, then when I went to turn it on today, it was back to taking a few seconds before the āheartbeatā light would start, and wouldnāt properly start the app.
Iāve tried a few times with STM32CubeProgrammer but still havenāt got it working yet. Also very strange and disconcerting that it somehow apparently got into a bad state all by itself. I was doing some changes/testing with battery vs USB power, but hopefully that doesnāt cause this!
Update: as a random test, I tried repeatedly plugging and unplugging the USB cable (with stand-alone Seed board), and after about 20 times, it started acting normally again! Iāve tried a few hundred more plug/unplug cycles and itās still behaving. I canāt even think of any way this should be at all possible!
This sounds similar to an issue we are having in the field. Big release, and this is a MAJOR show stopper! It seems there is no āsafteyā in the bootloader. The bootloader should have a saftey built in, so if it does not 100% complete, on the next power up, it goes back to where is was before the bootload attempt. We were able to get it to consistently lock up at power up by cycling power on for 2 seconds, off for 2 seconds. One of our units locked up every few power cycles, and another never locked up. Itās a very random thing, and very frustrating for our customers. Hopefully my DSP engineer will chime in here with more detailsā¦
Lol, was just making an account to say the same. @TallMike I saw on another thread you were talking about the SCB_EnableDCache() call. Have you heard back from ST on the support thread? I sent an email to ES as well asking if theyāve seen similar issues.
Weāve seen the same deal happen where it starts slow, goes into the bootloader, and then the app code doesnāt properly start. Iām going to see if I can get one of the ones weāve got to reflash with bootloader v5 to see if there is a difference
I still havenāt heard anything useful back from ST, they are speculating about the decoupling capacitors, PLLās, dirt on the board, etc.
I think itās worth noting that it would happen with the āblinkā app as well, so itās not limited to the bootloader, though probably worth trying the V5 one in case it was doing something slightly differently. Iām super nervous about sending out our product with this being unresolved.
Also, side note about the bootloader, it does not seem to have much ābrickā protection if e.g you unplug or power off the board in the middle of an update, it doesnāt seem aware that it didnāt finish and seems to jump to the app regardless.
What is the problem description that ST is replying to and what was their actual response? Do you think this is an ST or an E-S problem or is that just unknown for now?
Here is a link to the ST Community forum discussion:
And hereās what I asked on the ST Support Case:
Weāve been using a Daisy Seed module based on the STM32H750IB (Daisy Seed ā Electrosmith), and have observed the following inexplicable seemingly impossible behavior:
During powerup, it can get into a semi-persistent state (it will keep doing it for 5-30 times in a row of power cycling) whereby the startup code (seemingly SCB_EnableDCache) takes several seconds to run. Then it will āswitch backā and run properly for hundreds of times.
, it doesnāt seem to be a per-power-up probabilistic situation. Rather, it is acting like it has 2 different āstatesā that it is somehow ārememberingā, across power cycles (as long as 12 hours or as short as 1 second). When itās in the āgoodā state, it will repeatedly (over 200 times in a row) start up properly. Then at some point (apparently during power-up), it will transition into the ābadā state, where some part of the startup code (apparently the SCB_EnableDCache fn, though if that is bypassed, then it instead seems to take a long time initializing the QSPI flash). It will then stay in the ābadā state for approximately 5 to 30 power cycles in a row (hence my thinking that unlikely to be an independent per-power-on situation).
Thereās been at least two other Daisy Seed users who have run into this. Electro-Smith has not been at all responsive about this.
And hereās their initial response:
Hello Michael,
Since we cannot see the underside of this development board our team suspects that the issue might be the decoupling and bypass capacitance is insufficient in total as well as in low values such that the result is not inductive at the CPU operating frequency. This could help explain the intermittent operation.
Just because it has happened in the past, make sure the board is very clean around the HSE circuit. Detritus has been known to affect the frequency of operation such that it is difficult for the PLL to lock upon startup. If that is the case, it would present as a quick to long time for the micro to get out of reset.
If you can connect to the bboard with the CubeProgrammer you may watch certain items go into lock like the clock tree. With that tool you may investigate the settings for the POR, PDR, PVD and BOR configurations. See if those make sense or if you need to change them for your application.
In terms of where the problem is, itās still a bit hard to say. Iām really hoping thereās some change/tweak in the startup code that can be made that will eliminate this issue. I still cannot image how this can be happening at all, though!
Itās exactly what you describe. We have had severl returned from the field that are just dead at powerup. The Power LED is lit, and the other dark. I believe we reprogrammed one and it fixed it, but it could be that we just didnāt power cycle it enough to knock it out of whatever state it was in. We can reliably duplicate it on SOME modules by powering up for 2 seconds, off for 1 second. I can get them to lock up every other powerup, but then the next cycle it powers up normally.
Are the ādeadā ones really fully dead, or if you wait ~3 seconds, does the bootloader āthrobā start up?
Also, if you hold the ābootmodeā button and then press/release the āresetā button, does it show up as an ST DFU-device on the USB devices list? (with a USB cable plugged into the on-board USB socket)
The ādeadā ones do launch the bootloader, it just then freezes while exiting the bootloader, and the app code never starts. They do show up as an ST DFU device when put into DFU mode and the flashing operation in DFU mode works correctly. If we load the blink example as you have, they flash successfully and the example runs correctly after the ~3-5 second wait time itās doing whatever it does.
Interestingā¦ Hereās a test you could try: see if the Daisy port of the Owlsy bootloader has the same problem or not!
I made a fork of it for Daisy testing:
And I can send you the .bin (it wonāt let me upload it here).
The test would be to see if it enumerates as a MIDI device right away or takes that same 3 seconds.