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

[malc-c]

Archie,

When I loaded the HEX code the programmer fuses are set by the config bits in the code when the code is loaded into the application. I'm wondering if, for example that these bits needed to be changed, and as a result the code as programmed has not programmed correctly.  Now this may be down to me messing with bootloaders the other day, but I just erased and blanked the PIC, loaded the code which set the fuses shown in the attached image, but then errored with 53 errors and 4 IDs...  Clicking the CODE button shows the HEX as per attached image....  Originally the chip I programmed and mounted on the PCB programmed without issue.... but it's raised an element of doubt as to the the replacement PIC being incorrectly programmed causing it not to run....(for arguments sake say the oscillator setting should be HS_PPL and it gets set to HS)

[Astro-Geek]

No need for apologies Malcolm  (ever 🙂)

Yes, that's why Skywatcher's choice of sockets on this mount was so risky.  (that's my excuse anyway !)

The Synscan hand controller plugs into an EQ5 mount via an RJ45  socket, so the EQmod adapter has an RJ45 plug.

On the synscan goto Dobs, the cable that links the Alt motor board to the Az motor board is the RJ45  at both ends, and the synscan hand controller plugs instead into the RJ12  on the Alt motor cover, right next to the RJ45 socket. 😬

So if you're not concentrating (like I wasn't), it's quite easy to plug the EQMod RJ45 plug into the RJ45 socket on the Dob, and boom.......  resulting in a repair that will cost around £200, and a 4 month wait.

It would have been much safer to have a completely different type of socket linking the two motor boards.

Edited May 25, 2020 by Astro-Geek

[malc-c]

I think I've found the possible error.... I don't think the PIC has been programmed with the right code.  

I'll drop the OP a PM...

[malc-c]

Archie,  I could really do with some help here.

I have installed python, and executing the scripts in that zip file launched a CMD like box asking for the path to the BIN file, which was copied and pasted against the prompt.  I hit return and pointed it to the folder where to put the HEX file and hit enter.  Some text was displayed and then the box was closed.  On checking the path for the HEX file, the folder was empty.  I had to resort to recording the screen in order to see what the messages were...

I've tried locating the output folder directly on the C drive and it still have the same error...

Any ideas

 

 

Placing the BIN file in the PUBLIC folder (where everyone has permissions) and then opening the script in the Python IDE and running it from there also results in the same error, so I don't think its a windows user permission issue

Even running the IDE as Administrator has the same issue

 

Edited May 25, 2020 by malc-c

[ozarchie]

Hi Malcolm, I will have a look when I get home.

In the meantime, do you keep any notes on the circuit, especially connectors? I have started roughing out a circuit diagram based on the EQ6.

What would help are photos of both sides of the AZ board. 

Cheers Archie 

[Astro-Geek]

2 hours ago, ozarchie said:

Hi Malcolm, I will have a look when I get home.

In the meantime, do you keep any notes on the circuit, especially connectors? I have started roughing out a circuit diagram based on the EQ6.

What would help are photos of both sides of the AZ board. 

Cheers Archie 

Leave that with me Archie,  (something I can manage at last.. 🙂)

I'll take some high res photos of both sides of both boards and post them on here, (they'll be big !)

 

[Astro-Geek]

Ok, here's the bigger photos of both sides of both boards.

I had to take them at an angle to avoid the reflection from the ringflash.

They're both almost identical, apart from the obvious missing RJ12 and power socket from the AZ "slave" board.

As malcolm suspected, there's one or two small components near the PIC that maybe telling it whether it's the AZ or the Alt.

Thanks Archie.... 

[malc-c]

And along the same theme here one with the pic removed as a few tracks and vias are under the device

[malc-c]

OK, just to rule out an issue with my PicFlash programmer I installed my PICKit2.

With the PIC in the breadboard and the PicKit2 programmer attached I loaded up the code from the post on page 3 and received a warning that the code is too large for the device... but when instructed to program the chip it reported a successful programing.  But verification failed.  I get the same results with the sample EQ6 file contained in the zip file.

If the device is read after a "successful" program the program memory is just 0000 in each location

Any ideas Archie ?

Edited May 26, 2020 by malc-c

[ozarchie]

Yes, that does look odd. I am just resurrecting my PICKIT2 with an 886 in it. I will get back to you.

I am using the same version of Python as you have, but am not seeing that problem.

1. Windows search > cmd<enter>
2. C:\users\Name\>cd \users\public<enter>
3. C:\Users\Public>py -V<enter>
4. Python3.8.3
5. py bin2hex.py -o v209.hex -b v209.bin

 

 

[Padraic M]

2 hours ago, Astro-Geek said:

Ok, here's the bigger photos of both sides of both boards.

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.

[malc-c]

33 minutes ago, ozarchie said:

Yes, that does look odd. I am just resurrecting my PICKIT2 with an 886 in it. I will get back to you.

I am using the same version of Python as you have, but am not seeing that problem.

1. Windows search > cmd<enter>
2. C:\users\Name\>cd \users\public<enter>
3. C:\Users\Public>py -V<enter>
4. Python3.8.3
5. py bin2hex.py -o v209.hex -b v209.bin

 

 

 

I followed your instructions, running from the command prompt.  However rather than getting the "Done!" message I was prompted to enter the paths for the source and destination again, which resulted in the same permission error.  Only this time it did produce a 1K hex file... full of 3FFF at each location.  I think it was this confusion that has resulted in me effectively programming a blank PIC in the first instance....

After a bit of faffing around I managed to get it to work.... using the py script from your zipfile.  This produced a 20k hex code with data (see attached).  However when this is loaded into my PicFlash programmer the programming fails with the same 53 program and 4 ID errors.  Loading the 20k hEX file into PicKit2 gives the same warning about the code being too large for the device - it also shows the code is protected (as it does in picflash).

[ozarchie]

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

[malc-c]

2 minutes 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 · 0 downloads

I'll give that a go.  In the PicFlash I originally tried changing the calibration and code / write protect to off and none - but hadn't edited the HEX file....  I also tried changing bit 6 in the PicKit2 settings to disable code protect of programming memory and that didn't work.... I'll give your suggestion a go and report back....

[ozarchie]

 

 

You will first get a screen like this:

 

But once you set the configuration bits, and export it (File>Export Hex), and reload it, you should get:

 

After that,  you should be able, to program,verify, read etc.

[ozarchie]

I think you need to copy bin2hex.py into your \user\public directory for the command line that you used.

[malc-c]

Archie, I still get errors when programming the PIC using the MC004ee.hex file (53 program errors - 0 ID).  I also notice that having removed all the config settings that the Oscillator settings changed as well.  Setting this back to HS made no difference - the code still failed to program.   However, when the same code was loaded into PicKit2, and whilst it too complained about having no config bits set... it did program, and verify and can be read back...... but with no config setting being programmed then is there a chance that the code won't function correctly as the wrong Osc settings have been set ?

[malc-c]

• saving the file and then
• using that HEX file to program the device

 

I missed that bit !

[ozarchie]

Are you saying that the ICSD is getting the 53 programming errors? I am not sure what that means. I have a PICKIT2 with a 28 pin demo board loaded with a 28 pin plastic 16F886 and it programs correctly. What device is reporting the programming errors? The PICKIT2?

Edited May 26, 2020 by ozarchie

[malc-c]

Yeahhhh.... success !!!!!!!!!!

Well as far as I can tell.... having exported the files as instructed and then loaded that back into both PICFLASH and PICKIT2 the code loads, verifies, and can be read back......  I did have to set the OSC to HS (the motor board has a 20mhz xtal on it) but now have two programed PICs 

Archie, thank you for teaching me these techniques... even at 58 I'm loving the learning curve

[malc-c]

3 minutes ago, ozarchie said:

Are you saying that the ICSD is getting the 53 programming errors? I am not sure what that means. I have a PICKIT2 with a28 pin demo board loaded with a 28 pin plastic 16F886 and it programs correctly.

Those errors are reported using the mikroelctronika PicFlash program.... I'm guessing that it was due to the code protection bits....

Anyway I now have been able to program the PICs without errors after following your instructions.  I missed the part about loading the converted hex code which had the config bits removed and then exporting it with the PIC selected to generate the config settings, and the re-importing it again....

[ozarchie]

OK, cool, Imight leave you to it. Good luck. Cheers, Archie

[malc-c]

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..... 

[Mick J]

Enjoyed following this Malc, Archie an Mr Geek, it ain't over until the circuit board sings, looking forward to that. Outstanding work all.

[malc-c]

Well this is interesting.....

With the PIC in the EasyPIC5 dev board programmed, I connected up a FTDI USB - 5v logic serial adaptor to the PIC serial port and loaded up the SW Firmware loader application

The result is quite pleasing