54 replies to this topic

[Wdh]

Hi all- I did not get the email. I updated my mount a few weeks ago- the HC reports that the MC version is 7.18.5028. Is the version in this thread a later version? I am generally reluctant to update unless there is an issue. 

 

Bill

[Mike Mc]

Hi all- I did not get the email. I updated my mount a few weeks ago- the HC reports that the MC version is 7.18.5028. Is the version in this thread a later version? I am generally reluctant to update unless there is an issue. 

 

Bill

Hey Bill,

 

I just updated mine using the link Celestron provided at the top of the Drivers and Software page in the Support section of their website.It installed version 7.18.5028 on mine as well.

 

I think you're up to date.

[JethroXP]

I updated mine following the directions Celestron Posted.  Normally I'd prefer to do it wired, over USB, but I followed the instructions and did it over WiFi and it worked fine.  Now just need clear skies to see if I notice any difference.  I'm hoping the mentioned "significantly improved tracking" is noticeable.

Edited by JethroXP, 03 April 2025 - 07:12 PM.

[Wdh]

Hey Bill,

 

I just updated mine using the link Celestron provided at the top of the Drivers and Software page in the Support section of their website.It installed version 7.18.5028 on mine as well.

 

I think you're up to date.

Thanks Mike! 

[mlord]

No problem if one prefers to do it "wired" through a hand-controller.  Just slower.  WiFi is much quicker, and safe so long as the mount has firmware newer than about 2018 or so, when they fixed WiFi to work correctly during updates.

[TentacleJoe]

If you’re on a newer Mac (non intel) and are having problems running CFM, make sure to use the package from this link and not the button link from the firmware page.

https://software.cel...Evolution/cfm3/

[Ice Cube]

If you’re on a newer Mac (non intel) and are having problems running CFM, make sure to use the package from this link and not the button link from the firmware page.

https://software.cel...Evolution/cfm3/

was able to successfully update my 3rd generation evolution with cfm3, 

but my 2nd generation evolution is kicking back a device memory corruption error for the MC.

 

both over the WIFI.

 

will scrounge up the cables tomorrow from the storage units and try the direct wired connection for the update.

[JethroXP]

was able to successfully update my 3rd generation evolution with cfm3, 

but my 2nd generation evolution is kicking back a device memory corruption error for the MC.

 

both over the WIFI.

 

will scrounge up the cables tomorrow from the storage units and try the direct wired connection for the update.

How do you know which generation of Evolution Mount you have?

[mlord]

He's probably referring to the WiFi generation: SkyQLink-xx vs Celestron-xxx.

Anyone with the former should be using a cable for the update, as it's old enough to likely still have older firmware with a WiFi bug that makes firmware updates very risky over WiFi.

[Ice Cube]

He's probably referring to the WiFi generation: SkyQLink-xx vs Celestron-xxx.

Anyone with the former should be using a cable for the update, as it's old enough to likely still have older firmware with a WiFi bug that makes firmware updates very risky over WiFi.

mine 2nd gen has been updated for firmware a couple of years ago.

it's wifi is of the form celestron-FF instead of celestron-FFF

 

oh dear!  plugged in the serial cable and the nexstar+ HC and getting

an error 17!

[mlord]

oh dear!  plugged in the serial cable and the nexstar+ HC and getting an error 17!

That is a risk when an update is aborted -- best bet for others when that happens, is DO NOT power off the mount.  Instead, just reattempt the update then and there.

 

Once the mount is powered off in a failed state, the bootloader in the mount firmware is unlikely to work again.

 

So.. I hope you do somehow manage to recover from that.  I also have an older (Rev.F) Evolution mainboard here that I corrupted with an aborted firmware update.  At some point I will wire it up to a chip programmer and see if I can reflash the bootloader to it.  This should be possible -- there's a "JTAG-ish" set of pads for this purpose. 

 

Cheers
 

[mlord]

I also have an older (Rev.F) Evolution mainboard here that I corrupted with an aborted firmware update.  At some point I will wire it up to a chip programmer and see if I can reflash the bootloader to it.  This should be possible -- there's a "JTAG-ish" set of pads for this purpose.

I think I may finally have a go at this, perhaps next week -- gotta order some probe connectors for it first.  If all goes well, I can probably then help anyone else with a bad-flash on the Evolution mount.  And likely also for StarSense hand-controllers, which use a similar processor.

[mlord]

Probe and connectors ordered, should be here early this coming week.  Gotta verify the wiring of the 10-pin JTAG pads on the Evo mainboard, and then hook it up and figure out the associated JTAG software for flashing.

[mlord]

Gotta verify the wiring of the 10-pin JTAG pads on the Evo mainboard

I have now verified that the 10-pin JTAG pad of the Evo mainboard is indeed laid out exactly as required by 10-pin ARM JTAG probes, so that part looks encouraging.  It even has a 10K pull-up on TMS.

 

[mlord]

FedEx International Priority:  For when it Absolutely, Positively, has to get there.. in a week or two.

 

Still waiting for the JTAG stuff, though it might arrive today, or later this week, or..

 

EDIT:  Actually, after sitting for three days in Memphis, it has finally crossed over into my local area, so it probably will arrive here today.  Then we'll see about reviving a mal-flashed Evolution main board!

Edited by mlord, 09 April 2025 - 10:00 AM.

[mlord]

.. we'll see about reviving a mal-flashed Evolution main board!

And how did that board get into such a messed-up state?

 

Well.. I was testing running CFM through the HBG3 to update firmware, and discovered (the hard way) that it doesn't work for that!  So I then added code to the HBG3 to try and detect CFM, and to switch the HBG3 "off" if it notices someone attempting to use it with CFM. About 99% foolproof, but don't rely on that: for now, never use CFM with an HBG3 connected!

 

Thankfully, this was one of the spare "dead" boards I had acquired years back and subsequently repaired.  I have another of those which I then just grabbed and have been using ever since, for testing the HBG3 and other devices here.

 

But I would like to have it working again.  This JTAG stuff should result in that happening.  And then I can safely resume efforts to make the HBG3 compatible with CFM. It slightly annoys me that this is the only area, in which the HBG3 is not at least "as good as" a Celestron WiFi adapter.  Gotta fix it! 

 

Cheers
 

Edited by mlord, 09 April 2025 - 10:27 AM.

[Ice Cube]

And how did that board get into such a messed-up state?

 

never use CFM with an HBG3 connected!

 

 

that's really good to know!  my HBG3 was attached when i got the device memory corruption/firmware update failure

[mlord]

There's been a note about CFM/HBG3 on the HBG3 web site for years now, but I did just check and it's not longer as prominent as it ought to be.  I'll fix that momentarily!

 

The tricky bit about CFM is that it isn't just one protocol.. CFM tries and uses about a half-dozen different messaging protocols while updating firmware -- accumulated cruft from two decades of CFM and firmware..

[mlord]

The FedEx guy finally arrived today, six days after the "overnight shipment" was sent.  He looked at the parcel before handing it over, and said.. "Wow, this must have gotten lost somewhere!".  Too true.

 

The main two items were these:  The JTAG probe itself, and a 20-to-10-pin adapter for use with it:

 

 

I had also ordered a few 5x2 pin headers, in 1.27mm (1/20") spacing, as needed for the 10-pin JTAG connection on the Evolution's PCB.  Cleaned the empty pads, and soldered one on:

 

 

Then plugged everything together, including a USB-C connection to my (Linux) computer, and was ready to go.  Except the Evo PCB was not responding normally, until I cut "R2" on the 20-pin adapter board, thereby disconnecting the NMI (PTA4) signal.  This apparently is not unusual, and is noted in the documentation for the 20-to-10-pin adapter.

 

 

The software of choice for this is "OpenOCD", which can run on Linux as well as other platforms.  Dumping the flash memory from a "good" PCB was easy enough.  The troubles began when I then switched to the "bad" PCB to write that file back.

 

The first step of the write procedure did an "erase", after which the board stopped talking to the JTAG stuff.  There were helpful messages though, suggesting "do this" and "do that", which I did try in various sequences and combinations.  Then, suddenly, things were happy again, and OpenOCD wrote the dumped image back to the "bad" board.

 

The board now boots up and runs again, with the latest firmware (courtesy of the unit I dumped it from).  But there is a subtle hardware issue with it somewhere, which probably has nothing to do with the re-flashing, but.. I need to poke around some more with a fresher mind to determine what's going on.

 

The Nexstar+ and StarSense hand-controllers appear to work fine with it, although I didn't do exhaustive testing.  But CFM running through the Nexstar+ doesn't "see" the mount.  CFM running through the StarSense HC did see it, but failed on upload to the Evo with "corrupted memory" errors.  So I had to reflash it again with the JTAG adapter.  This time I wrote down the command sequence for the erase-write stuff, and hopefully it will be repeatable next time.

 

But.. two out of three HBG3 adapters are unable to communicate with that PCB, unless I also touch the grounded shell of a USB-C cable to them, at which point they work perfectly until that GND connection is removed again.  The third HBG3 works.  It's probably due to the same issue that causes CFM not to work via the hand-controllers.

 

This suggests maybe excessive noise on the +5V signal lines on the AUX bus, interfering with communications, so a hardware issue rather than anything to do with the firmware.  I'll dig into that again perhaps tomorrow.

 

Cheers

Edited by mlord, 11 April 2025 - 07:53 AM.

[rrpallechio]

Then plugged everything together, including a USB-C connection to my (Linux) computer, and was ready to go.  Except the Evo PCB was not responding normally, until I cut "R2" on the 20-pin adapter board, thereby disconnecting the NMI signal.  This apparently is not unusual.

 

I want to grow up to be you

[mlord]

While I contemplate hooking a scope up to this PCB, there happens to be yet another Evo mainboard in the parts collection here.  This one has been used in the past as a "donor" board, taking parts from it, to help revive other Evo mainboards.  Including the main processor chip at one point.

 

When I ordered the JTAG probe stuff from Digikey, I also got them to include a new, un-flashed processor chip as well -- since they had them in stock, and the JTAG can be used to flash them.  So I've also now ordered replacement capacitors and more L293DD chips from AliExpress, with the hope of repopulating the donor board again to the point where I can try and revive it.

 

The symptoms it originally had were "no LEDs" when powered.   But I now know a few possible causes for that:  It could have been due to corrupted flash memory in the processor chip, except that same processor got re-used and is working fine on another Evo mainboard.  So, not that.

 

But there is a teensy little 3.3V regulator that powers the processor chip, separate from the much larger 3-pin tab regulator nearby, which I now think must be mainly for the WiFi module.  That teensy 3.3V regulator takes 12V input, and has to lose 8.7V of that as heat.. not a great design, and there's a chance of it dying at some point.  Perhaps that's what is wrong with the donor board?  We'll see, some day.

 

Speaking of that WiFi module.. there is a "T25" chip (74HCT2G125) associated with it, which suggests it is simply the regular Celestron WiFi dongle circuit, copied onto the Evolution mainboard, complete with 5V AUX bus interface.  So I'm expecting to find that it really is just wired straight to the AUX bus on the Evo mainboard, rather than having its own special control interface.  I hope to check this theory with an ohm-meter later today.

 

That bit about the WiFi helps in diagnosing the AUX bus issue I'm working on this Evo.  When connecting over WiFi, CFM can find and connect to the WiFi module, but not the rest of the Evo.  Very curious that, and explained nicely by the WiFi using the exact same AUX bus wiring as the other AUX ports of the Evo.  So that's where my scope needs to have a good look at things.

 

Which reminds me.. I really should be using the AUX Bus Scanner (python project) rather than CFM for these tests..

Edited by mlord, 11 April 2025 - 10:02 AM.

[mlord]

Speaking of that WiFi module.. there is a "T25" chip (74HCT2G125) associated with it, which suggests it is simply the regular Celestron WiFi dongle circuit, copied onto the Evolution mainboard, complete with 5V AUX bus interface.  So I'm expecting to find that it really is just wired straight to the AUX bus on the Evo mainboard, rather than having its own special control interface.  I hope to check this theory with an ohm-meter later today.

Without having spent too much time on that, it does appear that signals from that 74HCT2G125 are wired to the regular AUX connectors of the Evo mainboard.  I didn't do a super detailed examination, but it does appear that's how the internal WiFi is actually hooked up -- just wired into the AUX bus without an actual RJ12 plug/jack.

 

There are three extra wires from WiFi that go to the main Evo processor, presumably (aka. "guessing" here) for detecting WiFi mode and connections status, for the purpose of the processor then driving the LEDs appropriately.

Edited by mlord, 11 April 2025 - 02:36 PM.

[mlord]

.. two out of three HBG3 adapters are unable to communicate with that PCB, unless I also touch the grounded shell of a USB-C cable to them, at which point they work perfectly until that GND connection is removed again.

I tackled this today, armed with an Ohm-meter and the spare "donor" PCB.  What I did, was measure resistance from each of the AUX bus pins, to the large tab on the 5V regulator of the Evo PCB, comparing with the donor PCB.  The Rx/Tx pins (these are always hardwired together), were measuring low resistance to +5V, around 20K-ohms, when it should have been in the 80-100K range.

 

 

So then I started removing chips from the AUX interface circuitry, one at a time, looking for improvement in the readings.  The culprit turned out to be U13, which I have yet to exactly identify from the on-chip markings (CT2 43Z).  The most likely match is a variant of the SN74LVC2T45 logic level translator: https://www.digikey....2T45DCTR/639457  The "CT2" marking matches exactly, as does the "Z".  The "43" is likely a date of manufacture code, as in 2014, 3rd month, or something.

 

I swapped it for the same U13 chip from the donor PCB, and.. THREE BLUE BLINKS from the HBG3.  Plus, the Evo WiFi interface also now works fine.  CFM also now finds the mount, and correctly says the firmware is already up-to-date.

 

So, problem solved, and it had nothing to do with the JTAG re-flashing.  This gives confidence going forward for subsequent use of this PCB in working on HBG3 compatibility with CFM, as well as just giving me an extra spare working Evolution mainboard for contingency!

 

Happy.

Edited by mlord, 13 April 2025 - 11:46 AM.

[mlord]

.. my 2nd generation evolution is kicking back a device memory corruption error for the MC.

If that PCB is still not responding, you could send it to me here, and I'll reflash it with the JTAG rig, and send it back again.  You pay shipping both ways, and for any parts required (eg. JTAG header, possibly/unlikely a new CPU chip).
 

[Ice Cube]

If that PCB is still not responding, you could send it to me here, and I'll reflash it with the JTAG rig, and send it back again.  You pay shipping both ways, and for any parts required (eg. JTAG header, possibly/unlikely a new CPU chip).
 

terrific!  

 

i'll contact you via DM for shipping info...

i'm planning on using this guide to extract the boards vs sending the whole mount.

 

https://nexstarsite....lutionMount.pdf