I've built three QDX units so far and they all work fine, but now I've hit a snag on #4.

Rev 3a PCB, I removed the short at the very beginning of the build.
Built for 9 Volts.

• Power-on with a 7.5 Volt current-limited bench power supply and it comes up in firmware update mode.
• Copy 1_08.QDX to the drive.
• Unmount, power-off.
• Power-on with a 7.5 Volt current-limited bench power supply and it draws about 170 ma, fast-flash LED, then steady-on.
• USB enumerates, then after a few seconds, it gets an error and disconnects.
• Does it with several PCs, using a hub and not using a hub.

We decide to do a firmware downgrade.

• Power-on/fast-flash/power-off.
• Power-on and I don't remember the flash-pattern, but a USB media device enumerates on Linux
• I copy 1_07.QDX to the drive.
• I remove 1_08.QDX from the drive.
• Power-off.

Now when I power-on, it only draws 90 ma and there are NO LEDs lit and no USB activity.

Is it possible to brick a QDX?

Anyone have a recovery procedure?
I've got several STM32 Discovery boards with the built-on debugger if that helps.

On 07/06/2023 19:44, NoobBoy wrote:

* I copy 1_07.QDX to the drive.
* I remove 1_08.QDX from the drive.
* Power-off.
Now when I power-on, it only draws 90 ma and there are NO LEDs lit and no USB activity.
Is it possible to brick a QDX?

Do you mean you deleted what you thought was 1_08 from the QMX?
If so then maybe you actually deleted 1_07.

Try again without the delete.

73 Alan G54ZFQ

It was running 1_08 and we wanted to downgrade to 1_07 to see if that worked better so I copied 1_07 to the device and deleted 1_08.

The problem is now it does not enumerate on the USB and the LED does not light at all.

When you copy to the device you don't need to delete the previous one because it's done automatically, so you may have deleted the one you just copied, or corrupted the drive. However, it sounds like you have another issue if the USB isn't recognized and there's no light. That sounds a lot like a power issue. Trace the voltages from the power plug and after the regulator to see if you have juice and at the right voltages.
--
73, Dan - W2DLC

VCC is 5.0 and VDD is 3.3 Volts.
The processor is getting a 25 MHz 3.3 Volt (about) SYSCLK on pin #5.

I appreciate all the help folks.

The question is:

• The unit booted and I got blinking LED.
• I booted into DFU mode and wrote one file and deleted one file.
• I power-cycled and now I get no LEDs.

That seems like I somehow garfed-up the DFU bootloader, but I thought that was the whole point of a DFU bootloader that you couldn't brick the thing with a firmware update.

Replying to myself so people can see the exact sequence of events that left me (possibly) bricked:

QDX REV3a board with the short-circuit removed.
This is the third one I've built and the others work perfectly.

Here's what I did:

• Power-on unit, it comes up in DFU mode from the factory.
• Copy 1_08 to the flash drive and power cycle.
• Unit boots up in 1_08 and then disconnects from the USB after about 15 seconds.
• Try power-on several times, different PCs, USB hub and not with the same symptoms.
• Maybe using an older set of firmware will help, so boot in DFU mode (power-on, power-off, power-on) and copy 1_07 to the flash drive.
• I figure that if the device sees both 1_07 and 1_08 that it will ignore the 1_07 firmware in favor of the 1_08 firmware, so I delete the 1_08 file.
• Power-cycle and now nothing. No LEDs light.

Is there a way to recover this unit using the factory debug header?
I have an STM32F303 development board with the snap-off-style ST-LINK/V2-1 debugger with an SWD connector.

开云体育

Doesn’t it reboot as soon as you load the new firmware in? ?I thought the QDX did…

On 08/06/2023 18:44, NoobBoy wrote:

VCC is 5.0 and VDD is 3.3 Volts.
The processor is getting a 25 MHz 3.3 Volt (about) SYSCLK on pin #5.

That looks as if the processor is working. I think the manual says the processor turns on the 5 volts.
Does the QDM show as audio and COM port in Device Manager?
I think you said Linux so the equivalent.
Can you open the terminal?

73 Alan G4ZFQ

The QDX does not attempt to perform USB enumeration on either Linux or Windows-10.

On 08/06/2023 20:07, NoobBoy wrote:

The QDX does not attempt to perform USB enumeration

Sorry, getting confused, on the QDX the voltages are independent of the processor.
Looks like Hans needs to comment.

You must cycle the QDX power to get USB enumeration when using a Windows system. Just plugging in the USB cable will not work if the QDX already has power.

Steve N9SZ

Good point, I was just looking at the LEDs to see if the thing was working.

So this morning, I plugged in the USB using a VERY short cable into a Linux machine where I can watch the USB enumeration.

• Power-on
• No LED activity
• No USB activity

So I? successfully made a brick out of a QDX.

That really shouldn't be possible with DFU, so I read about how DFU works, and unfortunately due to the design of the system, I can't forse the processor to boot into DFU mode by jumpering pins.

Reading a LOT here, I saw that someone had a system with a bad EEPROM which was causing the thing not to boot, or not to run or something, so out of desperation, I shorted the EEPROM SDA line to ground and applied power.

• LEDs blink like it's in DFU mode
• USB enumeration completes
• I see a mass storage device
• The mass-storage device has 1_08 on it and the EEPROM file
• I delete 1_08
• I copy 1_09
• And I wait.....
• Reflash completes, thing boots, enumerates and I can connect through the virtual com port.

So, I don't know what happened to corrupt the EEPROM, or why the thing doesn't boot with a bad EEPROM (both are bad design in my 30-year experience as a firmware developer.)

Now I can give the thing to the person who bought it and be done with this thing.

I managed to brick my QDX today by interrupting the 12V power supply more than once, I think during boot up. It appears to be a design flaw that corrupts the firmware file.

I was able to restore it by using NoobBoy's procedure of shorting the SDA line (pin5) of the EEPROM to ground and connecting by battery while maintaining the ground. It instantly came up in firmware update blinking LED mode and I was able to use USB to paste an uncorrupted version of the firmware into the EEPROM folder. I disconnected power, and it started normally. I should note that the corrupted firmware file name was 1_10, not 1_10.QDX when I first looked. This may have been the actual corruption for all I know!

This is why I love forums like this!

Hi Nooboy, after reflash complete, do you need to disconnect the EEPROM?SDA line from the ground? Or do you need to replace the EEPROM chip? thanks.

I also save my brick, happy! Thanks Nooboy and Brian.
I connect SDA to GND, power on, seeing the LED flashing, then disconnect SDA from GND.?
After reflash firmware, my brick come back to QDX. ^O^?

Once in firmware update mode just copy the new firmware file onto the "drive". It does not matter if the version of the new file is older or newer than what is there, it will replace it. DO NOT DELETE ANY "FILES" FROM THE DRIVE. That's what probably caused the issue.