Jump to content
Flirc Forums

Bricked Jeff Probe


Angel

Recommended Posts

  • 5 months later...

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 by geosmall
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by geosmall
  • Like 1
Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...