Gateware update not taking

[Bruce Walker]

I have two HL2s, one I operate remotely that was new from the production batch last summer. I have been trying to switch gateware to the 10rx stable/20210730_73p2/variants/hl2b5up_cicrx/hl2b5up_cicrx.rbf

Regardless of whether I use the hermeslite.py method or Quisk, it reports success in programming the gateware, but after waiting a while for reboot, it is still running the original factory 4rx firmware. I’ve also tried using the hermeslite.reboot() method, also without seeing the new firmware. I have used the same process to switch my home HL2 gateware back and forth without any issues.

Any suggestions short of power cycling, which I can’t do without traveling to the remote QTH? 

—bruce W1BW

[Steve Haynal]

Hi Bruce,

What gateware version is reported for the remote unit with update problems?

73,

Steve

kf7o

[Jean-Baptiste GALLAUZIAUX]

I'm using my HL2 with Quisk.

My question may look silly but I would like to know how I can read my gateware version for a HL2 delivered in September, 2021 from the last Makerfabs batch?

Is there a place to read the history of gateware and where to download an update? I guess it should be in the Github wiki?

73 - Pierre - FK8IH

[James Ahlstrom]

Quisk shows the "Code version" of the current gateware in the title bar.

Jim

N2ADR

[Bruce Walker]

On 1/16/22 23:43, Steve Haynal wrote:

> What gateware version is reported for the remote unit with update
> problems?

In [3]: hl.response()
Out[3]: Response(type=2, mac='00:1c:c0:a2:13:dd', gateware='73.2',
radio_id=6, use_eeprom_ip=False, use_eeprom_mac=False, favor_dhcp=False,
eeprom_ip='0:0:0:0', eeprom_mac='00:1c:c0:a2:00:00', receivers=4,
board_id=5, wideband_type=1, response_data=0, ext_cw_key=False,
ptt_resp=False, pa_exttr=False, pa_inttr=False, tx_on=False,
cw_on=False, adc_clip_cnt=3, temperature=16.616699218749996, fwd_pwr=1,
rev_pwr=1, bias=0.0, txfifo_recovery=True, txfifo_msbs=0,
rem=b'-\n\x00\x04\x83\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')

--bruce w1bw

[Bruce Walker]

Sorry, Jim. Quisk reports code version 73, ID 6

--bruce w1bw

[Jean-Baptiste GALLAUZIAUX]

Thanks Jim, I could read "Code version 73.2

73 - Pierre - FK8IH

[Steve Haynal]

Hi Bruce,

That gateware is new enough for remote upgrade.

The Intel/Altera IP used for this remote gateware update has a set of error flags. If any one of these error flags are set, it falls back to the factory image which is 4 receivers. For example suppose you somehow tried to program a corrupted gateware file which couldn't load, then the error flag for that would be set, Or perhaps there was a CRC error once when reading the new gateware. Currently these flags are not cleared until a full power cycle. So any error condition remains and forces the factory image until cold power cycle. I suspect this is what is happening in your case.

I should look at if there is a way to clear these flags for future gateware, but it is deep inside the Intel/Altera IP.

73,

Steve

kf7o

[Roger David Powers]

FWIW while testing hermeslite.py while updating the wiki, I definitely noticed the only reliable way to see the gateware change was to do a cold boot after the update i.e. take power away for a few seconds then wait for it to come back up.  I don't think that's an issue worth worrying about though.

Regards,

RDP

[Steve Haynal]

Hi RDP,

For me, the remote update is working and visible without cold reboot most of the time. That was the intent. In rare cases a fault flag might be set as discussed previously which does require a cold reboot. One such case is the very first gateware update. The HL2 arrives with only the factory image installed. It starts up, tries to load the user image, finds none, sets an error flag, and then boots the factory image. Since this error flag is set, it will not boot into the new image unless a cold reboot is done. But once a user image is written and th eunit rebooted, writing subsequent user images should not require cold reboot.

73,

Steve

kf7o

[Bruce Walker]

> On Jan 20, 2022, at 1:34 AM, Steve Haynal <softerh...@gmail.com> wrote:
>
> For me, the remote update is working and visible without cold reboot most of the time. That was the intent. In rare cases a fault flag might be set as discussed previously which does require a cold reboot. One such case is the very first gateware update. The HL2 arrives with only the factory image installed. It starts up, tries to load the user image, finds none, sets an error flag, and then boots the factory image. Since this error flag is set, it will not boot into the new image unless a cold reboot is done. But once a user image is written and th eunit rebooted, writing subsequent user images should not require cold reboot.

Aha! Mystery solved: I’ll bet that I had not tried to program new firmware on this unit before my remote attempt, since it was relatively new and I had been using it as a transceiver before attempting to repurpose it as a remote skimmer. I had used different firmware on my original unit, which is why the identical process worked just fine. Thanks for the explanation, Steve.

—bruce w1bw