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.

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

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.

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

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

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

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

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

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

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

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

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

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

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 ?

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

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

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 ?

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

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

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

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)

I was under the impression it was vice-versa. - so that would mean the EQDIR cable was connected to the socket where the link cable would go.... hence how 12v was placed on the TX line, and how the AZ board was not connected at the time. My apologies

OK, to the best of my abilities using the images provided (including one I took with the PIC removed which helped a lot) this is what I came up with for the serial connections. I may have missed a connection, it was difficult working from the images having to remember the flip them when tracing, so I'm not 100% this is accurate - I'm sure I must have missed a link somewhere I'm sure AstroGeek can have better luck confirming this as he has the board in front of him. The links Lx are shown as looped wires Pins 6 and 8 of the handset may not be linked - hard to tell, but three may be some webbing around pin 6 to the same copper fill as pin 8 ?

Archie, programming the PIC using the EasyPic5 board took a couple of seconds to program and verify