jason Posted August 12, 2022 Report Posted August 12, 2022 @GregO @Dave Starkey I've updated our firmware to be the same as the public black magic probe firmware, cherry picked rtt support as well, and released binaries: https://github.com/flirc/blackmagic/releases/tag/v1.8.4 Quote
geosmall Posted January 21, 2023 Report Posted January 21, 2023 (edited) firmware.zipHi Jason, Jeff Probe is an awesome community add and I appreciate all your work on this. I'm in the process of upgrading firmware on my Jeff Probe and have everything working right now on Win 10 with help from Zadig to assign WinUSB driver to the devices. Using dfu-util.exe -l to list devices it can see the DFU firmware upgrade interface just fine: Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2021 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/ Found Runtime: [1d50:6018] ver=0100, devnum=14, cfg=1, intf=4, path="1-2", alt=0, name="Black Magic Firmware Upgrade (SAMD)", serial="0B35C557" Per the post above I have downloaded firmware.zip (attached) from Stable Release v1.8.4 at Release Stable Release v1.8.4 · flirc/blackmagic (github.com). The zip has 4 folders (below), each of which contains several .bin, .elf and .hex files. It is not clear to me which I should load and why. This leads me to two specific clarifying questions I was hoping you could answer: 1.) Could you kindly summarize the reason for the multiple folders and which folder firmware should be used under which circumstance? For an example, I plan to use RTT but it is not clear if I should use blackmagic_fw, blackmagic_fw_no_serial_rtt, or blackmagic_fw_rtt? 01/21/2023 07:31 AM <DIR> blackmagic_fw 01/21/2023 07:31 AM <DIR> blackmagic_fw_no_serial 01/21/2023 07:31 AM <DIR> blackmagic_fw_no_serial_rtt 01/21/2023 07:31 AM <DIR> blackmagic_fw_rtt 2.) As for which .bin file to use, contents (typical) from blackmagic_fw_rtt folder are below. From the file sizes I'm guessing blackmagic_dfu.bin/.elf is the bootloader only, blackmagic_dfu_full.bin is the combined app and bootloader, and blackmagic.bin is the binary app I should use to load with dfu-util.exe? But I'm only guessing here. 01/21/2023 07:31 AM 117,900 blackmagic.bin 01/21/2023 07:31 AM 192,010 blackmagic.elf 01/21/2023 07:31 AM 8,256 blackmagic_dfu.bin 01/21/2023 07:31 AM 72,886 blackmagic_dfu.elf 01/21/2023 07:31 AM 23,267 blackmagic_dfu.hex 01/21/2023 07:31 AM 126,156 blackmagic_full.bin Thanks again! George Edited January 21, 2023 by geosmall Quote
jason Posted January 21, 2023 Report Posted January 21, 2023 The black magic probe enumerates with two Serial Ports on your computer. One is for the GDB Interface you attach too, the other is the serial port for the device. You can use the second USART port for whatever you want, I usually put a shell interface or a printf on that second interface. There are dedicated serial lines on the bottom of the BMP for that second usart port. But on my device, you can reconfigure the unused JTAG when using 2 wire serial for those serial ports. The benefit being that you can use one cable for JTAG and Serial to the target. Now RTT is something different. I might get this wrong, but from my light understanding, you get two USART ports on your PC. One for JTAG, another you attach for serial again. But there are no serial pins that connect to the target. This is a virtual device where you can communicate to the target over the same 2 wire serial debug interface, but also need to support this in the target. The normal firmware uses the serial number for the device. So on a mac, we end up with /dev/cu.usbmodemJEFF19502 The problem with this is that on a mac, I personally like to have a .gdb file that does that auto connects: target extended-remote /dev/cu.usbmodemJEFF1 monitor swdp_scan attach 1 mon convert_tdio disable Unfortunately we can't have a file like this if you have more than one probe, because the name changes. So in order to avoid this, the custom serial number just uses JEFF0 and JEFF1 all the time for every device. So If I'm on my office setup or home setup, it all stays the same. This isn't so much a problem on windows and linux. In linux you can make a udev rule to create an alias. Hope that helps. Sorry, I need to spend more documenting. I'm running on thin fumes. Quote
geosmall Posted January 21, 2023 Report Posted January 21, 2023 Umm, thanks Jason. Sorry to hear, best of luck with the fumes. The above is interesting, but did not address the two questions I had above. I'll just give the blackmagic.bin file a shot out of blackmagic_fw folder and cross my fingers. I'll report back after I get a chance to test a bit. Best, George Quote
jason Posted January 21, 2023 Report Posted January 21, 2023 .bin is the regular file that has a random serial no_serial.bin is the one that has no serial number rtt is the one that acts different based on my explanation use the blackmagic_fw.bin one. Quote
geosmall Posted January 21, 2023 Report Posted January 21, 2023 Ah, got it, thanks so much Jason. Quote
geosmall Posted January 21, 2023 Report Posted January 21, 2023 (edited) Plugging in while holding down the boot button boots up a DFU device at [1d50:6017]. This step likely confuses many folks that you need to boot into DFU update mode at [1d50:6017]. dfu-util -l gives: Found DFU: [1d50:6017] ver=0200, devnum=17, cfg=1, intf=0, path="1-2", alt=0, name="@Internal Flash /0x00000000/1*008Ka,15*008Kg", serial="DEMO" Then on to programming blackmagic.bin from blackmagic_fw folder. Used command line dfu-util.exe --device ,1d50:6017 -s 0x00002000:leave -D blackmagic.bin, which gives: Warning: Invalid DFU suffix signature A valid DFU suffix will be required in a future dfu-util release Opening DFU capable USB device... Device ID 1d50:6017 Device DFU version 011a 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 4096 DfuSe interface name: "Internal Flash " Downloading element to address = 0x00002000, size = 114528 Erase [=========================] 100% 114528 bytes Erase done. Download [=========================] 100% 114528 bytes Download done. File downloaded successfully Submitting leave request... Transitioning to dfuMANIFEST state Looking good so far, so I'll try testing and report back. George Edited January 21, 2023 by geosmall 1 Quote
beattie Posted March 2, 2023 Report Posted March 2, 2023 A while ago I built and flashed some firmware for my Jeff probe and my Jeff probe became unusable for its intended purpose. I have periodicaly cloned the github repo and tried to build the FW with no success, then I noticed that the repo had been synced up with the upstream repo so I thought I'd be able to build ... but no luck as far as I can tell libopencm3 has changed so that the flirc repo does not build. So I was going to ask that binaries be made available but wonder of wonders I stumbled across the post that pointed me right at my very heart's desire and my Jeff probe is back to performing its intended purpose. The vendor support for this device has been phenomenal. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.