¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

QDX won't load firmware...?


 

I built a QDX Rev 3a (yes I cut the trace at C41) last week, for 9V supply operation, and tested it successfully over the weekend. I believe it came loaded with firmware 1.05, and that's what I ran it with over the weekend.

Yesterday I wanted to do some fine tuning, so I updated the firmware to 1.09, and then opened a serial connection (using Putty) to access the QDX's terminal mode applications. I did a bunch of its test sweeps, made some notes for what I wanted to take a closer look at later in the hardware. Then I shut down the radio.

Today, the QDX won't go into "normal" receive mode. It either wakes in bootloader mode with the slow flashing LED, or alternately it wakes with a steady LED but without ever doing the the 5 seconds of quick LED flashing. I cannot connect to it via Putty, and WSJT-X says it can't find it either for rig control.

Since the bootloader works, I have tried progressively (regressively?) rolling back the firmware, landing back at 1.05. I manually deleted the EEPROM file each time as well, in case something got corrupted. The results have been the same for each firmware version I have tried.

I powered it up with a bench supply at 9V, and see it's drawing 111 mA when in "steady LED" mode. I took it out of its enclosure, and nothing looks out of place (although I don't know all the test points to check with a meter, the few more obvious ones like the 5V supply regulator output seemed fine).

Any ideas for what to try next??


 

Hi Leigh,

I do not have much to suggest.? The simplest is not to delete the old firmware and let the QDX do the update as described in the operating manual.? It might be the EEPROM chip IC6.? There has been a couple of posts on that IC failure.

These are suggestions.? Others may have better ideas on how to proceed.
73
Evan
AC9TU


 

Thanks Evan. For the record, it was the EEPROM file, not the firmware file, that I was manually deleting.

I guess I could try attaching the QDX to a different computer to do the firmware changes (although, it did work the first time after I applied the 1.09 update). I have been applying the firmware updates using an Rpi running the standard?Raspberry Pi OS. I am mostly a Mac user, and from what I read updating firmware using a Mac isn't a straightforward drag-and-drop operation.

Other than that, is there a way to trigger the "Factory reset" just from hardware, like by shorting pins?


 

Hi all

FYI there is no such thing as deleting either an EEPROM or firmware file from a QDX, QLG2, U4B or a QMX. They aren't real USB flash drives. I wrote a very compact bootloader to take as little space as possible. They're a very limited simulation of a USB Flash drive having only enough functionality to be able to copy in and out EEPROM or Firmware files. Which is documented in the QDX operation manual. Only. Nothing else. You can't delete or add other types of files, or rename anything. Your computer might do some caching that makes you think it did other things like copy in other files but it isn't really and if you disconnect and reconnect or power down you'll see it didn't really.

73 Hans G0UPL


On Wed, Jul 12, 2023, 7:36 PM Leigh KG7WED <ham@...> wrote:
Thanks Evan. For the record, it was the EEPROM file, not the firmware file, that I was manually deleting.

I guess I could try attaching the QDX to a different computer to do the firmware changes (although, it did work the first time after I applied the 1.09 update). I have been applying the firmware updates using an Rpi running the standard?Raspberry Pi OS. I am mostly a Mac user, and from what I read updating firmware using a Mac isn't a straightforward drag-and-drop operation.

Other than that, is there a way to trigger the "Factory reset" just from hardware, like by shorting pins?


 

Hi Hans, thanks for the comments. So the EEPROM "file" is an abstraction of sorts, OK.

In the manual it says "EEPROM contents: the QDX configuration and log file (if enabled). Again, you can read the file from QDX or write a new one to QDX, simply by dragging files in your file manager application."

So what I was trying to do was to wipe the EEPROM contents, in case something in that configuration data had gotten corrupted, and was preventing the QDX from booting up properly. I tried this both by system drag-and-drop "trashing" and by `rm` on the command line.

If neither of those options actually work to actually clear/reset the EEPROM contents, could you please suggest another way I might do that? Or if clearing the EEPROM wouldn't actually help, what else might I try at this point?


 

There is a hardwire reset. Look at the last page of the assembly manual.?
--
73, Dan? NM3A


 

Hello Leigh

Deleting a file does nothing. You can copy the file in and out, as the manual suggests. If you copy in a new EEPROM, the contents of the file you copy in will rewrite (replace) the entire EEPROM with the new values in the file. As others have said, there's also the Factory Reset which?erases the EEPROM and writes it to default values.?

73 Hans G0UPL


 

On Wed, Jul 12, 2023 at 01:01 PM, Hans Summers wrote:
there's also the Factory Reset which?erases the EEPROM and writes it to default values
The only reference to a Factory Reset I have found is that it's one of the Terminal Applications available when connecting to the QDX with a serial connection. But since it won't boot I can't do that.


 

On Wed, Jul 12, 2023 at 12:23 PM, Daniel Walter wrote:
There is a hardwire reset. Look at the last page of the assembly manual.?
I looked but I'm not seeing that. A keyword search of the assembly manual for "reset" doesn't yield anything about a hardwire reset either.


 


--
Colin - K6JTH?


 

Colin,

That is for the QMX.? The message topic is for the QDX.? There is no hardware reset for the QDX other than through the terminal program.

73
Evan
AC9TU


 

Thank you for catching that.?
--
Colin - K6JTH?


 

On Wed, Jul 12, 2023 at 03:09 PM, Evan Hand wrote:
There is no hardware reset for the QDX other than through the terminal program.

Thanks for the clarification on that.

Also, for the record, there's no problem getting my QDX into bootloader mode, just by power cycling it.

I was asking if there was a way to do a hardware reset of the EEPROM, since I can't get to Terminal Mode. (I don't know that it's the problem, but it's possible a corrupted EEPROM is keeping the QDX from booting normally.)

Since, as Hans says, I cannot actually delete/trash/rm the EEPROM from the file system, is there instead a factory EEPROM file with all default values that I could download and copy onto the QDX?


 

I have tried loading the firmware file using macOS and Windows systems now, to the same result.

One bit of additional info: when I power cycle the QDX, and it's in non-bootloader mode, the front panel LED just lights up steady with no quick flashing as I've mentioned. However, now that I have it out of its enclosure, I can also see that the onboard LED (on the bottom of the circuit board) pulses 1 time on and off, when it first powers up in non-bootloader mode. I mention this in case it provides additional diagnostic information.


 

AFAIK Hans has never published what if any, status the onboard LED provides other than in the factory for testing.

I would replace the EEPROM chip (IC6 24C64SM) and see if that helps.? I believe that it is this chip from Mouser:


This needs to be verified, preferably by Hans.
73
Evan
AC9TU


 

On Thu, Jul 13, 2023 at 09:50 AM, Evan Hand wrote:
AFAIK Hans has never published what if any, status the onboard LED provides other than in the factory for testing.
Thank you, yeah I wasn't able to find any documentation of that either. Maybe Hans can shed some light on the issue.

I could try an EEPROM chip replacement, but reworking a surface mount chip isn't something I've done before.

Hans, would it be possible for you to post a zipped copy of the EEPROM file with the default configuration settings? That way I could try swapping out the EEPROM contents using the bootloader, since I cannot currently access the terminal mode utility to perform a Factory Reset.


 

Leigh,

Again, as far as I know, nothing in the EEPROM configuration file would impact the serial communication.

Investing in a hot air rework station would be a good idea if you see yourself building and repairing more kits.? Almost all of the new kits have SMD components now.? It is becoming as essential as a temperature-controlled fine-tip iron.? They are not that expensive on Amazon:


The one that I have is no longer available.

Just a suggestion.
73
Evan
AC9TU


 

On Thu, Jul 13, 2023 at 03:22 PM, Evan Hand wrote:
Again, as far as I know, nothing in the EEPROM configuration file would impact the serial communication.

Good point, I should clarify the serial communication issue in finer detail, because looking back at my first post, I see I glossed over some of that.

The serial port does appear when the QDX is plugged in, as `/dev/ttyACM0`. Putty seems to connect to it ok at first (it doesn't throw an error that the port doesn't exist). However, after that point, the Putty window is completely unresponsive, to either typing in CAT commands, or to pressing the enter key to switch to terminal applications mode. The Putty window remains completely blank.

Also as I've mentioned before, when in non-bootloader mode, there is no front panel LED "quick flashing (flickering) for first 5 seconds after power up". When the QDX was working last weekend, it did have this quick flashing, but it hasn't done that since I ran the test sweeps in terminal mode on Monday.

?


 

Low-melting solders like Chip-Quik can be helpful as well, with or without hot air.??
73, Don N2VGU


 

Well, I wish I could rename this topic title to "QDX non-functional" or something like that, since I'm now not convinced it's a firmware loading issue.

I searched the forum for EEPROM corrupted and followed up on some other threads. Through that I found posts about the IC7 and IC9 latch-up issue. I checked my board and yes indeed I was seeing the low (~0.9 VDC) voltages on pins 1 & 7 of the LM4562 opamps (instead of the ~2.5VDC levels that they should be). That, combined with the bad "image rejection" test results I had gotten last week when the terminal mode was still working, told me that my board was being affected by the latch-up issue.

So, I pulled C71-C74 off the board, and replaced them with jumpers.

Result: The latch-up stopped on?one of the opamps, but on the other, it is still happening.

In this thread, @KEN G4APB reported similar results, and narrowed down the fix to replacing a corrupted EEPROM file:
/g/QRPLabs/message/92676

So I have opened a support ticket to request a copy of the factory default EEPROM file, so I can replace it via the bootloader.

If anyone would care to post their working EEPROM file to the Files section, I would be happy to give that a try as well!