Make program-dfu error

Troubleshooting and Support
1

Hi there, Ive started goofing with just the seed on its own and have successfully programed the blink through arduino and the drum example program through the web programmer.

I tried making a change in the kick drums wave to be a square wave instead of triangle:

osc.SetWaveform(Oscillator::WAVE_SQUARE); //was _TRI

I made the change in notepad++ and saved it. Through the cmd line I performed a “make clean all” and attempted a “make program-dfu” while in bootload mode and after following Zadig driver upgrade. I receive the following error from the make program-dfu command

Make DFU Error
Make DFU Error741×704 34.7 KB

Any suggestion would be much appreciated :slight_smile: :thinking:

2

This is related to a recent change in the dfu-util utility. This should already be fixed.

Lines 289-290 of DaisyExamples/libdaisy/core/Makefile should read (specifically check for the comma at the end):

program-dfu:
	dfu-util -a 0 -s $(FLASH_ADDRESS):leave -D $(BUILD_DIR)/$(TARGET_BIN) -d ,0483:df11

In your screenshot it appears this comma is missing, which leads me to think your libdaisy is slightly out of date.

You can fix this by running the following from DaisyExamples/

git pull --recurse-submodules

If the problem persists or you have an error running the above you can run the following from inside of libdaisy to make sure it is up to date:

git checkout master
git pull origin master

Hope that helps!

3

Those instructions were great, I had to run the following first.

git checkout master
git pull origin master

I’m not sure but the git pull --recurse-submodules wouldn’t run until I deleted the drum.cpp file. I’m thinking because I had made changes to it. There was an error saying something like commit or discard my changes. I simply deleted the file and it seemed to run after that.

One thing very odd though since the

git pull --recurse-submodules

The drum.bin file is missing :thinking: Is that from something on my end or just a coincidence ?

I tried and was successful with

make program-dfu

on another example and it loaded just fine to the daisy seed.

2 Likes
4

Fantastic!! Glad you got it working.

I suspect that the changes were the reason for the failure of the git pull --recurse-submodles.

Git would have seen the changes to the drum.cpp file and made sure that it didn’t accidentally overwrite those (in case they were important). It’ll tell you what files are causing issues and you can just delete or rename which ever ones it mentions, and then it should work.

None of the individual .bin files are tracked on git (only the ones in the dist/ folder). So not sure why the one you had disappeared unless you ran make clean, or manually deleted the build folder.

1 Like
5

Actually I did run make clean all at one point earlier in the troubleshooting. Im quite green with this and didn’t realize this would remove the bin files. How can I go about rebuilding them

6

I’m getting this error too. Host is Windows 11 Git Bash, repository cloned today with submodules:

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 element to address = 0x08000000, size = 44648
Erase           [=========================] 100%        44648 bytes
Erase    done.
Download        [=========================] 100%        44648 bytes
Download done.
File downloaded successfully
Error during download get_status
make: *** [../../libDaisy/core/Makefile:289: program-dfu] Error 74
The terminal process "C:\Program Files\Git\bin\bash.exe '--login', '-c', 'make clean; make; make program-dfu'" terminated with exit code: 2.

The Makefile looks OK:

``
284 #######################################
285 # dfu-util
286 #######################################
287
288 program-dfu:
289 dfu-util -a 0 -s $(FLASH_ADDRESS):leave -D $(BUILD_DIR)/$(TARGET_BIN) -d ,0483:df11
290
291 program-app:
292 dfu-util -a 0 -s $(QSPI_ADDRESS):leave -D $(BUILD_DIR)/$(TARGET_BIN) -d ,0483:df11
293
294 program-boot:
295 dfu-util -a 0 -s $(FLASH_ADDRESS):leave -D $(BOOT_BIN) -d ,0483:df11
296


Note: the uploaded application does work, despite the error message.
7

That error is totally normal. A successful run will always end with that error and a working program.

Definitely confusing, but expected behavior for the time being!

1 Like
8

Thanks!! Yeah, It’s confusing. I’ll probably stick with the Arduino IDE because I have a Teensy-based device too and having two different IDEs is also an extra cognitive load.

9

This took me quite a bit of head scratching and searching TBH… but in other forums I found an explanation:

from m_mgowan on the particle_iot forums

After download is complete, the DFU spec prescribes that the device enters a state known as manifestation, where the host gives the device time to apply the download. During this time, dfu-util continually requests the status of the device while it reports that it is manifesting.

In our case, manifestation isn’t required, and the code simply sets the device status to manifestation complete and resets the device. The abrupt reset caused dfu-util to lose the USB connection and report a failure when trying to retrieve the device status.

The main fix is to delay the reset so that the USB response has time to be sent. A secondary fix is to report the state as Download_Idle so that dfu-util doesn’t print

Is the possible to tweak to add this delay and suppress the error - might be better for that first time user experience!

Steve

10

This seems like a reasonable explanation, thank you!
I just started and was also confused by this error.
I’d like to second the motion to try and fix it, in the meantime at least include it in the troubleshooting wiki and the getting started page so as to save newbies from worrying about it!

11

just update everything, still getting the error
confusing indeed

especially since I cannot find a way to rebuild the libdaisy library

12

I just realized that there’s no mention of the “Error 74” in the documents. We’ll need to update that. Thanks for bringing this up, Phil.

1 Like