Any ideas on repairing a (slightly!) blown motor board ?

[Astro-Geek]

2 hours ago, Padraic M said:

What I find very useful is to load both front and back images into Gimp (my tool of choice) or PS as separate layers. Mirror the bottom side horizontally, then using the Perspective tool, get both layers aligned perfectly. Then all you need to do is toggle the top layer visibility to see how top and bottom components, vias and holes line up. Makes analysis a lot easier.

Good idea Padraic.  I took advantage of photoshop myself with something similar when I  was making a note of the voltage readings around the board.  I put it in  a layer and then dimmed it down to 50%, so that when I printed it my handwritten figures would show up more clearly.

[Astro-Geek]

1 hour ago, malc-c said:

I just want to comment on this thread for anyone else following along....

This thread is NOT about trying to circumvent the copy protection in the Skywatcher Firmware.  I've posted all my trials and tribulations in trying to get a PIC reprogrammed so you can see just how complicated these things are, and the  effort we are putting into getting this board fixed.  The intent is to provide a documented thread for others to follow should they find themselves in a similar situation to the OP where their board has been fried and there is no clarity from the agent, UK distributor and even Synta themselves as to compatibility between new and old boards, or if a replacement for the original boards are available.  This leaves the OP with the choice of a £200 bill for replacing the existing boards, one of which is perfectly serviceable, or giving up on the goto function, which was the main reason the scope was bought for.  The last option is to try and repair the faulty board... which without the help of synta or the UK distributor means we have to resort to reverse engineering.....

My thanks to Archie for his assistance in resolving the PIC code issue.... now to get the board back from the OP and reprogram it for him..... 

 

...Seconded  (by me, the OP 🤓)

Excuse me if I'm repeating myself here, this is now quite a long thread and my memory is not as good as it used to be.....

As Malcolm has said, if the remedy was just a case of ordering the single small PCB that is faulty, then I would have done that 3 months ago. 

I did buy  one in fact, from a European Skywatcher main importer, but unfortunately the box contained a part that was completely different to that which it pertained to contain, so it was returned, (and promptly and apologetically refunded, no problem there.)

All of the Telescope mail order companies and main agents that I have contacted have faced two major difficulties, this unprecedented world-wide Covid situation, plus the fact that the Skywatcher Goto Dob range has recently been significantly modified since mine was produced.  This has resulted in much uncertaintity in which replacment parts are compatible with each other, and therefore how many parts I would need to buy, even though my problem is caused by just one small PCB.

...enter Malcolm and Archie...  expending much time and effort on my behalf on a completely non-commercial basis, (he hasn't even let me pay for the return postage or the blank PIC chip yet).  🍺🍺

 

 

[malc-c]

3 hours ago, ozarchie said:

Hi Malcolm, I am not really a PIC expert but the issue appears to be the configuration words. As you can see on your pictures, code protect is turned on (by the contents of the .mcf file and hence the contents of the .hex file). This means that once you program it, you can't read it back, so verification fails. Reading it back shows all zeroes.

You can prove this to yourself by

• deleting the second last line in the hex file (the config bits)  (:20400000FFFFFFFFFFFFFFFFFFFFFFFFFFFFA22FFF3DFFFFFFFFFFFFFFFFFFFFFFFFFFFFAF),
• saving the file and then
• using that HEX file to program the device
• both errors will disappear. (I have attched the edited file for you).

If you load the modified HEX file, set your configs, you can then export the hex file which will then contain the program and your configs. All should the work.

 

 

MC004ee.hex 17.78 kB · 1 download

Archie,

Can you advise how best to do this (a link to the editor you used if possibly)

[ozarchie]

https://notepad-plus-plus.org/downloads/v7.8.6/

with Hex editor plugin:

https://superuser.com/questions/1324217/how-do-i-install-the-notepad-hex-editor-plugin

 

[ozarchie]

Well done Malcolm. That smells like success to me!

I am attaching the Skywatcher low-level protocol document (from Skywatcher, not me). Here you will find the motor control commands used by Skywatcher to talk to the motor control boards. It all happens at 9600 baud. Ane example command ":e1: gets the firmware revision from an EQ6. It MAY work on these boards?

To answer one of your previous questions about how ALT is distinguished from AZ -

From the enlarged photos: If you look near pin4 of the PIC, there is a trace going to R4, which is populated as 0R0 on the ALT and not present on the AZ. My guess is that selects the board operation.

Regarding the TxRx lines, note from the Skywatcher document:

1. UART: 9600bps, 1 start bit, 1 stop bit, no parity check.
2. Signal level: 5V or 3.3V.
3. On most of the EQ mount, the TX and RX lines are separated. The motor controller will send its response immediately after it received and process the command.
4. On most the Alt/Az mount, TX and RX lines are connected together, and there is another line(Drop) to indicate that the TX/RX bus is busy. The Drop line is controlled by the master only, which means the master device should pull the Drop line to low level when it starts to send a command and keep pulling it low until it receives the full response from the motor controller, or, a time-out occurs. The motor controller will send its response immediately after it received and process the command, thus the master device should release the TX/RX bus as soon as possible after the last bit of the command is shift out of the hardware register.
5. The motor controller pull its TX line to high level with a 5.1K to 10K resistor, other than that, it does not strongly pull the TX line to high level and other devices can pull the TX line to low level without problem.

EQMOD talks to the motor controller using separated Tx and Rx lines, so if you get this to work, you can indeed connect a correctly wired EQMOD cable directly to the motor control boards. You would then need to configure EQMOD for the reported 'steps' and you would have an EQMOD telescope. Not sure about its use for astrophotography though .. you would really need to change it to a GEM

Cheers, Archie 

skywatcher_motor_controller_command_set.pdf

[ozarchie]

I have started a documentation schematic:

https://easyeda.com/join?type=project&key=bd5cc1cca39ab3ae2d634da8b17612be

Anyone should be able to edit it, a bit like github for schematics.

[malc-c]

Morning Archie,

Thanks for the info, and for creating the online schematic... I'll take a look

[ozarchie]

Sorry All. I had forgotten to share the project. You should be able to access it  now, rather than cloning it.

https://easyeda.com/jmarchbold/mc004v1

 

[malc-c]

Archie,

Whilst I'm waiting for the board to arrive from Astrogeek (RM not doing such a stirling job this time round...  ) I thought I would try and produce an unprotected HEX file for my HEQ5 just in case I should ever need it, and whilst this thread is still fresh in my mind.

I downloaded the firmware from SW website, which was already an uncompressed MCF file.  Ran the PY script to produce a HEX file (HEQ5.HEX) - I then opened that file in the HEX editor and deleted the first line that has 020000040000FA and saved it as a new file (HEQ5config deleted.HEX).  This was then opened in PicFlash, and for some reason it still showed as being code protected.  Changes to the code protection settings were made and then saved as a new file (HEQ5config reset.HEX).  This file was then loaded back into PicFlash and all the config bits and code protect were correct ( copy protection bits were clear and HS oscillator correct for HS) but when I try and burn the PIC it fails with 41 program errors...  If I then load that same code into PicKit2, it programs and verifies without issue....  I can then take the programmed PIC that was programmed using the PicKit2 and place it in the EasyPic 5 dev board, read the PIC back just fine and even verify the code using the PicFlash application...

However every attempt to read the firmware level on the pic from Skywatchers firmware loader application fails so I have no real way of knowing if its running or not ( I do wish SW would add a LED to their boards that would flash so you know if the device has a heartbeat and is running - testing would be a lot easier)

HEQ5config deleted.hex HEQ5config reset.HEX HEQ5.hex

[ozarchie]

Could you send me a screen capture if the error screen? The other think to check is the CRC. Maybe it needs be programmed as well. I think (but am not really sure) that it is held in the EEPROM, so maybe a dump of the EEPROM area? I think the real test is probably whether the motor control board responds to the commands detailed in the document. 

Cheers, Archie

[ozarchie]

Hi Malcolm,

• I have managed to program a 886 PIC with the MC004 code.
• It does respond to Skywatcher firmware uploader, but also fails to upload code.
• However, it does respond to serial terminal commands, such as those used on the EQ6 - see attached image.

 

So I am stuck. I don't really know how to help now.

[ozarchie]

I have looked at your HEX files, but am not sure what you deleted.

If I compare HEQ5.hex with HEQ5config deleted.hex, it appears that the first line was deleted. This is the 'line length' line in Intel HEX format.

At the end of the HEQ5.hex file, there are three lines of interest.

• The last line :00000001FF is the 'end marker' for the file.
• The second last line :2043E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA000FF003A, I am not sure.

1. :20 is the start token (20h is the length)
2. 43e0 is the offset word address
3. the next 16 words are data
4. The last word is the checksum of the record (003a)

• The third last line :20 4000 007F 007F 007F 007F 00FF FFFF FFFF FFA2 2F00 05FF FFFF FFFF FFFF FFFF FFFF FFFF FFE2, are the configuration words.

1. :20 is the start token (20h is the length)
2. 4000 is the offset word address, 
3. I think that, in the data,  CONFIG1 is word eight (0000-(0007), and CONFIG2 (0008) is the ninth word.
4. finally checksum (FFE2)

I have edited your HEQ5.hex file as HEQ5a config deleted.hex and get C1E5 as the checksum.

I do not know what the config bits should be, so I will leave that up to you.

Cheers

Archie

HEQ5a-config deleted.hex

Edited May 28, 2020 by ozarchie

[ozarchie]

Hi All,

According to a capture of the "Update" command, the reason it is failing is that it cannot find mcu2. So I think it should work when  both motors are there.

Cheers, Archie

 

[malc-c]

6 hours ago, ozarchie said:

Hi All,

According to a capture of the "Update" command, the reason it is failing is that it cannot find mcu2. So I think it should work when  both motors are there.

• I have managed to program a 886 PIC with the MC004 code.
• It does respond to Skywatcher firmware uploader, but also fails to upload code.
• However, it does respond to serial terminal commands, such as those used on the EQ6 - see attached image.

Cheers, Archie

 

Morning Archie,

I was thinking the same, the updater is looking for two micros, but only one was responding.

Thanks for checking the HEQ5 hex code and the detailed explanation.  I'm sure in the previous post it said delete the first line, which matches the example in that post.

Can you upload your working MC0004 code.  Whilst my efforts seemed to work, I would much rather use one that is proven to communicate and respond to the correct commands

Also, what are your thoughts on using the ICSP header... would there be any risk to the other chips when MCLR /VPP is taken to 12v ?

Malcolm

[ozarchie]

Hi Malcolm,

Yes, it got a bit hectic there for a while, so not surprising that a few things were buried.

I think the pinout on the ICD2 is numbered wrong, and has an ususual connection.

Pin6 of the connector is connected to MCLR\ - usually Pin1 of ICSD. Similarly, Pin2 of the connector is CLK- usually Pin5 of ICSD.

And there is a strange resistor between MCLR\ and Vdd - R20.

I would use your  FTDI USB - 5v logic serial adaptor  to serial update the device using the firmware update program from SW, rather than try to figure out the ICD2 connector.

Cheers

Archie

 

 

[ozarchie]

MC004d.hex

[malc-c]

Well the good news is that the PIC was programmed on board using the ICSO header...... I used a DVM on continuity to trace out the pin connections, and yes you are right it's all reversed, pin 1 (indicated by the square pad) is not MCLR - Pin 6 is.  Working back from the pad nearest the PIC (pad 6) we have, MCLR, Vdd, Vss, Data, Clk  Using the PicKit2 it found the chip, and programmed my version of the code.  I'm in the process of rigging up a connection to the PICs serial port to test.  Fingers crossed it will see the chip and respond to the firmware updater and those commands....  

 

[malc-c]

Thanks for the HEX file - if my code doesn't work I'll use the proven one... at least now I know I can program the chip in circuit without issue if I have to re-program it's no big deal  

[ozarchie]

BTW, I tested the theory about R4 setting the board type. If you ground pin5 on the PIC, it does change the board response from Alt to Az (after cycling the power).

I saw the circuit that you posted regarding the Rx, Tx lines. If that is the case, then "Tx" is/was connected from the RJ45/7 to Pin6(RA4) on the PIC, rather than Pin17 (Tx). Pin6 is also connected to R1, whick I think is a pullup resistor to Vcc. The EQMOD cable probably has Pin7, 8 shorted in the cable, which is why the onboard12V was shorted to the "Tx" pin. You could possibly check that R1 is still Ok and still connected to Vcc.

It also means that the motor control software commands won't work from a terminal program as the Rx data line is multiplexed with the Tx data line i.e. it is half-duplex. In my case, I have them connected separately, the same as your FTDI/USB convertor. But, you could run the Tx line from Pin17 (using a jumper wire from the top of D3) to the Tx input on your FTDI/USB converter. That should work.

Anyway, good luck. I will check later on progress.

Cheers, Archie

[malc-c]

Archie, thanks for the input and for working out how the boards are addressed.

I'm not having much luck here.  Having uploaded my copy of the HEX file to the PIC via ICSP (read back and verified by PICKit2) I hooked up two test wires form pins 5 and 7 of the 8 way socket on the board (as this would be the serial connection between both boards).  No matter what port settings or which way round I had the wires I couldn't retrieve the firmware version via the PC application using the FTDI board.  (this may be due to the reasons you describe above).  I can confirm the FTDI is working as linking the tx/rx together results in an echo back when an ascii character is sent.   But as this gave me an element of doubt in my version of the code (given how easily I screwed up the deletion of the wrong line), I connected the PicKit2 back up to the ICSP port, loaded up your version D of the MC code as you have confirmed the code responds to instructions and the PC firmware updater application.  The programming of the PIC was confirmed by reading the verified code back into the pickit2 application after relaunch, and then exporting it as a file and then opening that file in an editor and sure enough the code looked the same.  So now I'm confident the PIC is programmed with a working version of code.  I'm just struggling in finding a way to test it, which given your explanation above may prove difficult.

I'll retrace the serial connections now I have the board in front of me, but something is causing the DVM to give strange readings, so I'm guessing that the lines are tied together through resistors, caps or inductors somewhere along the lines rather than straight out from the PIC to the connector pins.  

I looked at R1, and on board it measures around 6.6K ohms. My battery in the DVM is running low, so I'll remeasure again once I've changed the battery, but its not open, so hasn't blown.

[malc-c]

I'm beginning to realise why I moved over to Arduino and away from pics....

For the life of me I can't replicate my success of getting the PC application to talk to the PIC and retrieve the firmware version.  Even when programming a DIP chip on the EasyPic5 board.  I've tried three different USB boards, one that definitely  used 5v TTL serial, and still nothing.  I've downloaded the same terminal application as shown above and don't get anything back when sending the same command instructions.   The pic gets programmed via the PicFlash application, so its not a power issue... so I'm sorta scuppered on how to test this further....  Getting back to the MC004 board, I'm 100% confident the PIC is programmed with Archies proven HEX code.  I've taken some large scale images to help anyone trace out the board, but obviously some via's and tracks will be under components.

If I can get this comms issue sorted I'll do some checking, but for now I've come to a grinding halt  

[malc-c]

Well I seem to have resolved the issue with the FTDI boards.... one of the four breakout boards has a prolific chipset... windows complained about its driver, the driver installed, but still wouldn't work.  After that ALL USB to serial boards stopped working, couldn't even get an echo back by connecting RX and TX pins together.... Having just uninstalled the driver my FTDI board now works

I've parcelled up the motor controller board and will be posting it tomorrow... hopefully this time, with a 100% working code programmed into the PIC we should get a result..... unless the board has some other failed discrete parts that we simply can't find by testing in situ.

[malc-c]

You know, electronics can be a baffling hobby.  As mentioned above, I followed Archies advice and extracted a version of the motor board firmware that when programmed to a DIP version of the 16F886 responded with the firmware vision when interrogated by the PC application.  I burnt the same code to an SOIC version of the same PIC and labelled it, ready for use on the board when it arrived.  In the meantime Archie provided a proven copy of the firmware that responded to control codes, so I opted to use that.

I then could not for the life of me reproduce the success I had a few days earlier and get any PIC with any version of the code to communicate through the USB Serial boards.  I even soldered the SOIC chip that was programmed with the same code as the DIP chip that did respond to the PC application directly to the PC used to program it.  I added a 20mhz crystal, 2x 22pf caps and a few wires and hooked up the 5v power.  Again, when connected via the USB serial board the PC software reported it couldn't connect to the motor control board.  I squirted Archies code to the PIC and had the same issue......   Each time I've tried reversing the two wires to the TX/RX pins on the USB serial board, and tried all baud rates  in case this was the issue....

In order to see if there was an issue with the USB board I connected it to an Arduino and uploaded  a simple bit of code that sent back the word "hi" each time any character is sent to it.  Opening up a serial monitor connected to the correct port and sending A, or B resulted in "hi" pinged back.... so that works, but for the life of me have no idea why I couldn't get a response back from the PIC when connected.... I installed an old version of MPLAB IDE so I could confirm the configuration bits in Archies code, thinking that maybe the oscillator setting somehow gets changed, as the board has a 20mhz crystal, HS is normally set... and sure enough Archies code when read in to the IDE with the option to use the code settings has HS set... but still no joy.... 

Now it could be that the PIC is simply not running.... and as Skywatcher don't include a flashing LED on the board to confirm the PIC has a heartbeat, and there are no regular timing buses used (such as I2C) using a logic analyzer won't show a thing.  Most pins are kept low, and without being able to send an instruction to the PIC can't test the pins that enable and output to the motor driver chips.  So lets pray that the PIC is more happy connecting to the handset when AstroGeek receives the board back.  Failing that all I could ask is for Archie to accept the challenge and take a look at the board..... but that may have a few logistical issues as I don't think he's in the UK.

Or AstroGeek could look at the option of getting an original AZ board and make the modifications to convert it to an ALT board.... both of which would be a lot cheaper and quicker than the full replacement to the newer "upgrade".  But hopefully we'll see a post on Monday with a video of AstroGeek dancing around his Dob as it rotates the OTA about its ALT axis   

[malc-c]

On 27/05/2020 at 13:50, ozarchie said:

Sorry All. I had forgotten to share the project. You should be able to access it  now, rather than cloning it.

https://easyeda.com/jmarchbold/mc004v1

 

Archie, have you taken this down?   I get a 404 error even after logging in 

[malc-c]

Well, I received a PM this afternoon.... AstroGeek had received the board and this time it worked.  He can now move the mount in both AZ and ALT axis.  However there are some quirky things happening that his testing has thrown up, and are beyond my understanding of how these boards and handsets function, so I'll let him list his findings later.  By the sounds of it though, the mount tracks which is a result.....