Ubertooth One not booting into DFU mode and not showing any packets during capture

[btle0812]

Recently an Ubertooth One board has been purchased. Its firmware version appeared to be not the latest, but 2018-12-R1. When trying to flash the latest firmware version 2020-12-R1 with ubertooth-dfu, the application was unable to find Ubertooth because the board reboots still in regular mode (USB ID 1d50:6002) instead of DFU mode (USB ID 1d50:6003).

An attempt of rebooting into DFU mode with ubertooth-util -f gives the same result, the board reboots in regular mode. Even shorting pins 1 and 3 on the Expand connector before plugging in USB doesn't make the device to go to DFU mode.

Steps to reproduce

1. Run ubertooth-dfu -d ubertooth-one-firmware-bin/bluetooth_rxtx.dfu or ubertooth-util -f.

Expected behaviour

Ubertooth One board reboots in DFU mode and is recognized as 1d50:6003 USB device. Then the firmware can be flashed.

Actual behaviour

Ubertooth One board reboots in regular mode, it is not detected by ubertooth-dfu, thus firmware can't be flashed.

Version information

Ubuntu 20.04

Ubertooth tools and libbtbb version (ubertooth-rx -V):
Tried two versions.
libubertooth 1.1 (2018-12-R1), libbtbb 1.0 (2018-06-R1)
libubertooth 1.1 (2020-12-R1), libbtbb 1.0 (2018-06-R1)

Ubertooth firmware version (ubertooth-util -v):
2018-12-R1 (API:1.06)

Moreover, the board is not receiving any packets with ubertooth-rx and ubertooth-btle -n. We could assume that this specific board is faulty, but later more devices were obtained from other sellers and all of them are demonstrating identical behavior! I realize that these boards are made by unknown manufacturers now and may differ from the original model (note "SMA-CONN" label near the antenna connector in place of "rxxx-px" label of the original boards).

Maybe I'm missing some important step in the firmware flashing or the initial preparation of the Ubertooth board? The previous similar board from several years ago is flashable and has been working correctly for a long time.

[CursedOddity]

I have the exact same issue.

Tried shorting pins 1-3 to manually force DFU mode as directed. tried with usb boot and my pi5 as i was told issue arise with VMs and usb for ubertooth. still nothing.

Im wondering maybe you bought your ubertooth from the same place as me and they are just defective.

My ubertooth is the exact same one as yours.

trying to use ubertooth-specan tells me I have to upgrade firmware. The device never boots into dfu mode using pentoo or kali installed. (Not vm)

Others have shown that when in dfu mode a lsusb will show id of 6003 and have note that it’s in dfu mode.

I shorted out pin 1-3 as shown on the docs to force dfu and nothing changed. I just returned mine to the Chinese seller and have given up on the ubertooth. I decided to buy the USRP B210. While it won’t be able work with Bluetooth hopping at least I’ll be able to mess around with something that actually works

[btle0812]

More devices have been obtained from multiple sellers, they can be divided into 3 categories.

1. With "SMA-CONN" label. Is recognized by Ubertooth software, but does not switch to DFU mode with any of the methods and is not receiving any packets.
2. Without label. Not recognized as an USB device at all, not booting in DFU mode with pins 1 and 3 shorted.
3. With "$Rev$" label. Came with the latest 2020-12-R1 firmware and is working!

[ukoda]

I have one the "SMA-CONN" with label from Banggood, https://www.banggood.com/Ubertooth-One-Bluetooth-Protocol-Analyzer-for-Bluetooth-Sniffer-Experimentation-Build-in-LPC175x-ARM-Cortex-M3-Controller-RP-SMA-Connector-Premium-PCB-2_4-GHz-Transmit-Receive-p-2026714.html, which has the same problem. It reports Firmware version: 2018-12-R1 (API:1.06) but will not go into DFU mode to upgrade to API:1.07.

[btle0812]

The working device with "$Rev$" was obtained from this seller. https://www.aliexpress.com/item/3256806895521791.html

[ukoda]

With the "SMA-CONN" version is it likely this a software only issue with maybe the LPC175X not having been programmed with the correct/full firmware or some flash access registers set wrong? I have not worked with the LPC175X processors recently, I have mainly worked with STM32 processors.

Given it has a 6 pin ISP header would it be possible to flash new firmware though that connector and hopefully resolve the DFU issue at the same time? If I get a bit of free time I may read up on this, unless someone has quick answers.

[ukoda]

There is disagreement between the KiCAD schematic in this repo at https://github.com/greatscottgadgets/ubertooth/tree/master/hardware/ubertooth-one and the documentation at https://ubertooth.readthedocs.io/en/latest/firmware.html around the 6 pin header. Looking at the actual board I suspect repo schematic is either wrong or very badly out of date. I think the readthedocs pages is more trustworthy.

Specifically only pin 1, ground matches, all others are different. On the schematic pin 3 is not connected but on the physical board there is clearly a track, hence believing the readthedocs version of that connector. I can provide a PDF of the schematic if needed but I am reluctant to attach it here. If it was to be pick up as being correct and referenced then it could add to any future confusion.

[ukoda]

Ok from the processor data sheet it does indeed look like you can flash the processor to stop future updates. If the factory wanted to protect 'their' IP they could do this. I have done development and manufacture in China and it is common for factories to lock down processors by default. It is entirely possible the person on the assembly line flashing the processors is not aware that this is open source software and protected the chip like every product he was asked to flash before.

This is currently all speculation. The relevant part of the datasheet reads:

8.30.3 Code security (Code Read Protection - CRP)
This feature of the LPC1759/58/56/54/52/51 allows user to enable different levels of
security in the system so that access to the on-chip flash and use of the JTAG and ISP
can be restricted. When needed, CRP is invoked by programming a specific pattern into a
dedicated flash location. IAP commands are not affected by the CRP.

There are three levels of the Code Read Protection.

CRP1 disables access to chip via the JTAG and allows partial flash update (excluding
flash sector 0) using a limited set of the ISP commands. This mode is useful when CRP is
required and flash field updates are needed but all sectors can not be erased.

CRP2 disables access to chip via the JTAG and only allows full flash erase and update
using a reduced set of the ISP commands.

Running an application with level CRP3 selected fully disables any access to chip via the
JTAG pins and the ISP. This mode effectively disables ISP override using P2[10] pin, too.

[ukoda]

Ok I have resolved the disagreement between the KiCAD schematic in this repo and readthedocs and both are correct. This the schematic if you want to save time opening KiCAD and updating.

ubertooth-one_sch.pdf

The readthedocs suggestion of shorting pins 1 and 3 of J4 will not invoke the LPC1754 ROM bootloader, it must be using a boot loader in the existing firmware.

The ISP connector I was looking for is not actually a connector, which is why I was confused. It is a series of rectangular pads on the rear side of the PCB only, near the JTAG connector. Pin 1 is towards the SMA end of the board. If you short pins 1 and 2 then reset by briefly shorting pins 1 and 6 you should get access to a serial port ISP command interface with comms on pins 4 and 5. The protocol looks easy to work with in Python so I'm assuming there is plenty of software to do the out there, haven't looked yet. The data sheets suggest this works in all cases, except if CRP3 is active.

The easy option is to solder to these pads and try it. However as I have failure case open with Banggood I no want to solder to the board in case I have to return it. I was going to make a pogo pin adaptor for it instead but note the pin pitch is unusual making that a bit more complicated.

[ukoda]

Good news, using a probe jig and a USB to serial adaptor I was able to access the bootloader ROM and flash new code so mine is now running API 1.07. I have not tried to put it into DFU mode as it now has the code I need. The page https://ubertooth.readthedocs.io/en/latest/programming.html has more detail about this process. So, for mine at least, the CRP is not active, making it recoverable.

[ukoda]

Just close out things from my experience here is the response I got from Banggood that appears to backup up what I found:

Please check the solution below, if there is no other question, you can close this ticket. DFU requires a bootloader to boot, but the general factory production is to directly flash the application firmware, which is to improve production efficiency, not to protect the firmware IP from being copied. The "SAM-COMN" you mentioned is only a difference in silk screen printing, and the circuit design part is exactly the same, so the module itself has no hardware problems, the difference lies in the firmware.
Solution:
1: Use the microcontroller serial port communication to flash the bootloader, and you can use the DFU function.
2 Use J-Flash software to directly download the 2020 firmware through the programmer. If you can't download the bootloader, you can also use the downloader through J-Flash to directly download the 2020 program. http://myosuploads3.banggood.com/products/20250123/20250123001609bootloader.rar

So in short for the factory to do the job properly would have required an extra step, costing production time. So to save money they simply programmed the application code directly into the device. Annoying but recoverable.

[zatarra]

@ukoda can you share the pinout of the serial port? I can't find it anywhere and the PCB doesn't have labels.

[ukoda]

@zatarra Attached is a picture of the rear of the board where I have marked up the connector where I was using a pin jig. I used the SMA as ground since my probes are wider then the pin spacing so it was getting crowed in that area. If you are not worried about returning the device then soldering to the PCB will probably be easier. I powered the board via the USB connector.

[zatarra]

Thanks for the details @ukoda

I'm not sure what the ISP pin is, but I assumed it would be VCC. Maybe I'm wrong? This is how I connected ubertooth to the FTDI module:

In any case I was able to flash the firmware and it seems to work (ubertooth-util -x trigger the xmas lights and I can retrieve the firmware version) until I reset ubertooth. Then it stops working:

Once I reset it:

If I try to flash the bootloader first I can't get DFU to work:

If I try to verify data it fails:

Any idea what might be wrong?

[ukoda]

@zatarra One thing that did catch me out is you can program the app firmware and it appears to work until reset. What I had to do was program the bootloader first, using that serial interface, then use the DFU tool via USB to get the app in.

If you are working from the the github.com:greatscottgadgets/ubertooth.git repo the boot loader is in a firmware/bootloader directory. After doing a make I flashed it by shorting pins 1 and 2 to force the ISP ROM, then shorting 1 and 6 to reset it, and then using lpc21isp bootloader.hex SerialDevice 230400 4000. After that I removed the short between pins 1 and 2 and power cycled it.

I was then able to use DFU mode to program it via USB. For that I went to the firmware/bluetooth_rxtx directory, used make then flashed using ubertooth-dfu -d bluetooth_rxtx.dfu -r.

[zatarra]

Again, thanks for the details @ukoda . I was able to flash the bootloader and then use DFU to flash the firmware. It is still not working correctly as I get lots of libUSB Error: Operation timed out: (-7) when trying to use its features, but at least it is now able to boot correctly and I can use DFU. I'm using OSX but tomorrow I'll try to use ubertooth with a raspberry pi.

[ukoda]

@zatarra Based on the DFU process working over USB I would say it is likely that the Ubertooth is now correctly working and it is the PC end that needs looked at. Trying an RPi next is good idea.

[zatarra]

Hello @ukoda, so I tried a raspberry pi and I got the exact same results. Any command that uses the radios simply hangs. At this point, I'm not sure if the chips are faulty or if I'm not programming it correctly. The bootloader seems fine otherwise I wouldn't be able to boot. However, flashing the DFU via firmware throws another error. Although it seems to be working and I can query the board for info, any commands that require the use of the radio will make the board hang. In the screenshot below, once I issue the ubertooth-utils -t and start the TX test, all of the subsequent commands fail with timeouts. If I power cycle the board, it starts responding again.

I'm running out of ideas. Are there any debug modes that could help understand what is going on?

[ukoda]

@zatarra While unlikely it may be worth trying those tests as root. I built most of the libraries and tools from the repos, github.com:greatscottgadgets/libbtbb.git and github.com:greatscottgadgets/ubertooth.git.

I am a newbie to the Ubertooth, I brought it to help with design verification for a Bluetooth product I am developing and I'm still waiting for working hardware for that. So as a result after testing that Ubertooth worked using the ubertooth-specan-ui program I put the hardware aside until have working product to use it with.

At this point I would say you have resolved your problem related to this issue and your current problem may have been addresses in another issue. If not you may need to create a new issue to see if someone with a deeper knowledge can help you.