Jump to content

Narrowband

EQ6-R Firmware update failure


Recommended Posts

I have been looking at the firmware releases on the Sky Watcher website and liked the idea of updating my EQ6-R Pro to 3.23 which has some new features like satellite tracking. I was confident as I have done this with the same PC and cables before with my AZ-GTI and have no issues updating the Hand controller which never gets used anyway.

So I fired up the MC Firmware loader 1.78 and checked my controller version which was 3.7. So I browsed for the new firmware file and clicked Update. The update failed and it suggested to power cycle the mount and try again. Well now all I get is an error message saying "Can not connect to motor controller". I have tried everything and notice that the hand controller when connected now just states "CAUTION Both axis... No response!". So I suspect that my mount is now bricked as it will not allow me to upload any firmware new or old. Has anyone else had this and if so how did they fix it? I am presuming new motherboard 🙁

Link to comment
Share on other sites

The port comes up as COM5 and is at 115200 speed. I was communicating with the mount directly via the USB port and read that its firmware was 3.07. The issue is that the firmware upgrade failed but the software said that if I power cycle the mount I can retry. I did as it said and the serial port shows under device manager but the motor controller no longer communicate at all for the firmware loader 1.78, not even to the hand controller.  I tried via the hand controller but that has not worked and even though I would try flashing the hand controller with Synscan Relay 4.2 but that could not communicate with the MC board either. I have now put 4.39.21 onto the hand controller and left that. Thankfully I have a spare motherboard for the EQ6-R and have installed that and this has MC 3.09 installed and that is running fine, which means I am not missing out on the only clear night in a month. I now need to see if anyone else knows how I can get this broken board fixed.

Edited by Grant Fribbens
Link to comment
Share on other sites

I cannot see any damage to the board that I removed. I always use the same PSU and cables. I have to admit I did try the firmware update knowing that I had already got a spare motherboard but did not expect to have to use it! I would now like to get the one I have had to remove working again so that I have a backup just in case but am definitely not going to update the one that is currently working.

Link to comment
Share on other sites

From my limited experience repairing motor boards it is very rare to brick a mount simply by uploading a firmware file as the micro controllers have a boot loader in a dedicate part of memory that doesn't get over written when using the windows application.  Most of the boards I've repaired have been boards based around the older 16F886 PIC micro controllers, and have been damaged when the user incorrectly used the wrong type of serial to USB convertor or plugged the connection cable into the handset connector by mistake.  This shouldn't be the case with your mount as it uses a straight bog standard USB cable. 

The "No response both axis" message displayed in the handset is caused by the handset not receiving a reply to the command to enquire what motor board its connected to.  This could be due to any brake in the communications line, dirty connectors, damaged curly cable, blown convertor chip in the mount, etc etc.  The handset sends out "please identify yourself" command to the board and expects to get back "EQ6 R" in a timely response.  

Now if your motor board is based on 16F886's then it's repairable by reprogramming two new PICs with the mount firmware (needs converting first)  - Have a read of this lengthy post where we've documented the repair process.  However if your board is one of the newer (which I strongly suspect it is ) motor boards with an ARM processor then sadly that is beyond my level of expertise, and will need either a new board purchased form the UK importer (either directly or via the retailer the mount was purchased), or we need to locate someone with the tools and equipment and skills to reprogram and replace ARM cortex processors.

Link to comment
Share on other sites

18 minutes ago, Grant Fribbens said:

I cannot see any damage to the board that I removed. I always use the same PSU and cables. I have to admit I did try the firmware update knowing that I had already got a spare motherboard but did not expect to have to use it! I would now like to get the one I have had to remove working again so that I have a backup just in case but am definitely not going to update the one that is currently working.

Can you post up a picture of the faulty motor board

Link to comment
Share on other sites

Here is a picture of the board.

20220506_115218.thumb.jpg.a740c1fbf355eee72bd4b9a7138833d6.jpg

I purchased the EQ6-R in 2020 and it only stays out if it is not going to rain so has had plenty of tlc!! I play with STM32 chips all the time with other devices (Sonoff devices, TUYA Devices, 3d printers and Betaflight flight controllers on drones) that I have but I can only presume that the MC Firmware loader 1.78 may have caused the bootloader to fail. I think that this software requires a firmware version from the MC before it will upload the new firmware. If you know of a way that I can get the firmware onto the STM32 in another way then I am open to suggestions and am very handy with a soldering iron, but what I am hoping is that there is a way to get the MC into DFU mode and somehow getting the firmware back on it that way (maybe using SW2). SWD1 connections look interesting as well 😀.

It would seem the handset has this when you hold down the zero and 8 keys together at startup, so surely there must be a way to do this with the motor controller.

Thankfully I had a spare board so was out imaging last night with that as well as with the AZ-GTI.

20220506_072815.thumb.jpg.46da9a4d5afcf7ff6feb1e73b45ed3db.jpg

Edited by Grant Fribbens
Link to comment
Share on other sites

You're more experienced than I as I've never programmed an STM32 before.  I was looking on the board for a JTAG header which would save having to physically remove the chip, presuming that it is the chip that has been damaged. I have a feeling that the board still uses a USB/Serial chip to handle the coms between the hand controller and the processor.  It could be that chip (prolific chip) that has gone tits up and causing the error.  Looking at the sw website the firmware for your mount should be 

Firmware: Universal Stepper Motor Driver with Built-in USB port, Version 3.23 if I'm not mistaken, I presume that was the version you were trying to upload?  -

I would have thought that if  you had tried to upload the older firmware for the 16F886's found in mounts without USB ports  to a board with an ARM processor on it the windows loader would have reported a problem.  Either way, seeing that the software can no longer find the board, re-uploading the correct firmware isn't an option. 

My attention was drawn to that port to, assuming D is for data, and C for common - with G for ground and + for programming voltage ???  Is there anything on the underside of the board - maybe pads on the board rather than a header ?  If you can find the USB to Serial chip (presuming this isn't built into the ARM chip) then shorting the TXandRX pins and using a terminal program you should be able to confirm that the coms are working as it will echo back whatever you send via the com port.

If you do manage to find an ICSP pad or header and reprogram the chip with the firmware (which might need converting to HEX) then keep us posted.  It would be great to then merge this thread with the one I linked to for future reference 

Link to comment
Share on other sites

I think that there is some echo happening as when I tried Synscan Relay 4.2 into the hand controller and connected that every time that I tried the update button of the MC Firmware Loader 1.78 a value on the hand controller screen kept increasing. There was an R with and number and then a T with a number being displayed in the bottom part of the LCD screen. When connecting USB it is still appearing under the device manager under Windows as COM5 as a Prolific Serial device. Normally when I program STM32 I just use my own FTDI and let VS Code do the upload, this is especially the case when doing Arduino code. Sometimes you might have to pull pin 60 high which takes it into DFU mode. Might have to do some reverse engineering of the firmware loader to see what it is doing.

Link to comment
Share on other sites

My guess is that as the firmware is uploaded via a serial connection then a bootloader is used in both 16F886 and STM32 versions of the board.  Again, you are more experienced than I, but I always thought bootloaders were placed in restricted memory in the stack, so that the normal code doesn't overwrite it and thus brick the device??

It sounds like these new boards have the prolific 230X chipset to handle the TTL serial to USB coms... If the board has a 28pin 2303HX chip, pins 1 and 5 are the TTL RX/TX lines.  So if they were shorted then in theory sending any ASCII character via a terminal program it should echo back.  If it does then I would try removing the short and send :e1 to see if the Arm chip returns the firmware version... If it doesn't then that would suggest that the chip has a bricked firmware, or something else fried it.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.