Jump to content

sgl_imaging_challenge_2021_annual.thumb.jpg.3fc34f695a81b16210333189a3162ac7.jpg

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


Recommended Posts

A lot of that detail is educated guesswork, and presumptions that other components haven't failed (I feel this is turning into a new Sherlock Holmes mystery - a lot of deducing !!)

I'm not an electronics expert, but also having a background as an IT technician tend to follow a logical path when problem solving, which more often than not works... but I'm not infallible :) 

  • Thanks 1
Link to post
Share on other sites
  • Replies 247
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Well I've just received a PM from the owner and he's a happy bunny... Yes it's four out of four guys Due to their personal commitments they haven't had the time to put the thing through its pace

Hello everyone, I am that happy owner  who sent this badly damaged MC-003 board to Malcolm and received it back in fully working condition   I wanted to make a video showing that everything is working

We'll it looks like we've scored another goal in extra time The first thing I did this morning was to re-flash the PICs with the same 209 hex file I originally used.  Now as the PICs were solder

Posted Images

Thanks again to everyone who replied with help on this, and especially Malcolm who persuaded me to try changing some of the ICs as well.

It hasn't actually solved it, but it has confirmed that the fault must be the main pre-programmed PIC chip, which is likely to have copy-protected parts to its firmware, so that's a show stopper.

Nothings been lost though, the ICs were only a pound or two, and I now understand the circuit much better and I am confident at replacing surface mount ICs now !

It's now just a question of waiting for replacement to become available through the importer, when China resumes supplies.

 

  • Like 1
Link to post
Share on other sites

Just to keep anyone else following this thread up to speed, I've been in daily communications via PMs as we try and resolve the issue.  Thinking it was the driver chip, I persuaded Astro-Geek to purchase a replacement and suggested an easy way to remove the old one and solder the replacement to the board.  Regretfully this had no effect, and the remaining two chips (a hex schmitt trigger and an OP-Amp ) were also replaced.  Sadly the fault remained, and tonight Astro-Geek confirmed that all the discrete components have been tested by comparing like for like with the known working board.  So this just leaves the PIC micro as the possible cause.  Now Synta will have copy protected the raw HEX code, but as the firmware can be uploaded via a PC application this suggests the PIC as a bootloader running.  The firmware that you can download from SW website is encapsulated in a wrapper so it's impossible to extract the raw HEX code and attempt a reprogramming.... The Copy protection also means that its not possible to read the code on the good board and then squirt it back to the faulty one.....

So that basically means we can't do much more and that a new board is required.  At least through deduction and Astro-Geeks willingness to attempt some resoldering (which by the image he sent me he did very well) we learnt a lot about these boards.

Its been fun, and it would have been nice if the efforts resulted in a fix in the same way I fixed my HEQ5 with just a couple of capacitors, we'll just have to chalk this one up as unsolvable  :(

I'm sure Astro-Geek will keep us posted  once OVL or other SW suppliers are able to source replacement boards from China

Edited by malc-c
  • Like 1
  • Thanks 1
Link to post
Share on other sites

If you could flash a known good board with the firmware then you could potentially sniff the traffic and extract the data used to program the PIC.  Had I ever done this however I would know that it's really a stupid amount of work, and you really, really have to want to get hold of the data.

James

Link to post
Share on other sites

I do have a com port sniffer... but don't have any hand controllers to do the pass through.  You can bet your bottom dollar that Synta probably use the PIC in the hand controller to remove the encapsulation when its set to PC Direct mode, so even if you used a sniffer between the PC and the hand controller it would all be garbage....

Link to post
Share on other sites
  • 3 weeks later...

Sorry for my late entry, but I saw your dilemna described on the EQMOD forum.

I had a similar issue with my EQ6 motor control board, shorted the 12V to the onboard PIC :(

Eventually, I replaced the PIC (a PIC16F886). I cannot completely read the part number from your photo but I think it is the same.

The PIC uses ICSP which is an in-chip serial programming algorithm. The connections work since you have already tried this with the 2.09 mcf firmware.

But I do not quite understand some of your statements. If the chip/MCB returned the version number (2.9.98 from memory), then both Tx and Rx are working (The PC had to ask the version, the MCB had to answer).

Are you sure that only the Alt board was connected, and that it wasn't the Az board responding?

If the Tx, Rx are working, then it is likely that the PIC may be sensing something about the motor/encoder inetrface. It must be the onboard interface, otherwise the motor/encoder would not work on the other controller.

The motor driver is a l293D which is a "dumb" dual switch for the motor. From your picture, only half of it is used.

The encoder sensing is done via the quad 324 comparator and, probably, part of the 74HC14 inverter.  Did you replace both of these chips?

From your photo, I can see a connection from the 8pin HC connector via L5 to pin 18 on the PIC (this is the PIC Rx line). This is the connection that is most likely damaged via 5V. Two pins up (pin20) is Vdd. If this is 3.3V, then it is even more likely that this is the problem, but I can only see one voltage reg on board and you have already measured it as 5V.

One below, Pin17 is Tx. Both Tx and Rx are joined to the six pin connector and that is working. 

So I would check the connections from the 8 pin connector to the PIC pins, 17, 18 and see what the voltages are there.

 

Replacing the PIC is not difficult. In my case, the process was reasonably straightforward.

  1. The MCF file for the EQ6 was just the binary image.
  2. Use bin2hex program to create the HEX file.
  3. Use an ICSP adapter to program the PIC. (Search DIY ICSP, or use a PICKIT4)
    1. The ICD2 connector, in conjunction with the 3x2 jumper block may let you do this on-board (you would have to buzz out the pin connections for me)
    2. Or, Program the chip externally using a 28pin surface mount adapter and a clamp to hold the PIC surface mount pins onto the PCB.
  4. Solder it onto the main board, after removing the old one.

Best of luck,

Cheers,

Archie

 

 

 

 

  • Like 1
Link to post
Share on other sites
9 hours ago, ozarchie said:

Sorry for my late entry, but I saw your dilemna described on the EQMOD forum.

I had a similar issue with my EQ6 motor control board, shorted the 12V to the onboard PIC :(

Eventually, I replaced the PIC (a PIC16F886). I cannot completely read the part number from your photo but I think it is the same.

The PIC uses ICSP which is an in-chip serial programming algorithm. The connections work since you have already tried this with the 2.09 mcf firmware.

But I do not quite understand some of your statements. If the chip/MCB returned the version number (2.9.98 from memory), then both Tx and Rx are working (The PC had to ask the version, the MCB had to answer).

Are you sure that only the Alt board was connected, and that it wasn't the Az board responding?

If the Tx, Rx are working, then it is likely that the PIC may be sensing something about the motor/encoder inetrface. It must be the onboard interface, otherwise the motor/encoder would not work on the other controller.

The motor driver is a l293D which is a "dumb" dual switch for the motor. From your picture, only half of it is used.

The encoder sensing is done via the quad 324 comparator and, probably, part of the 74HC14 inverter.  Did you replace both of these chips?

From your photo, I can see a connection from the 8pin HC connector via L5 to pin 18 on the PIC (this is the PIC Rx line). This is the connection that is most likely damaged via 5V. Two pins up (pin20) is Vdd. If this is 3.3V, then it is even more likely that this is the problem, but I can only see one voltage reg on board and you have already measured it as 5V.

One below, Pin17 is Tx. Both Tx and Rx are joined to the six pin connector and that is working. 

So I would check the connections from the 8 pin connector to the PIC pins, 17, 18 and see what the voltages are there.

 

Replacing the PIC is not difficult. In my case, the process was reasonably straightforward.

  1. The MCF file for the EQ6 was just the binary image.
  2. Use bin2hex program to create the HEX file.
  3. Use an ICSP adapter to program the PIC. (Search DIY ICSP, or use a PICKIT4)
    1. The ICD2 connector, in conjunction with the 3x2 jumper block may let you do this on-board (you would have to buzz out the pin connections for me)
    2. Or, Program the chip externally using a 28pin surface mount adapter and a clamp to hold the PIC surface mount pins onto the PCB.
  4. Solder it onto the main board, after removing the old one.

Best of luck,

Cheers,

Archie

 

 

 

 

Archie,

Thanks for the input.  I've been in conversation with Astro-Geek as I have the ability to program PICs, but had no way to srip the wrapper from the downloadable firmware file to leave just the HEX

I'll have a play and see if I can burn a chip and post it to him

Excellent post, thank you

Link to post
Share on other sites

Can you provide a link to the convertor tool you used.  The Bin2Hex convertor I just tried is command line, and whilst it produced an output it's not recognised by the PIC programmer.  If this is the same utility can you remember what options / switches you used in the command line to produce a viable HEX file

Link to post
Share on other sites

Hi Malcom,

From my failing memory:

1. Rename filename.mcf to filename.bin
2. bin2hex.py<cr> "filenmae.bin"<cr> "filename.HEX"<cr>
3. load filename .hex into PIC_IDE
4. Program using ICSP

I have included the working files I used in the resurrection.

I am trying to recreate the process now. But my Windows10 + Python64 is not co-operating.

Good luck,

Cheers

Archie

 

 

PICmcf.zip

Edited by ozarchie
Link to post
Share on other sites

Archie, that's the same convertor I've downloaded.  The only thing that I don't understand is line 2 using the py extension and I presume <cr> means hit enter ?

Link to post
Share on other sites

If I run the normal command line bin2hex file.bin  file.hex  the conversion happens, but when I try to load the HEX file into PicFlash (I use an EasyPIC development board for PICs) I get the error shown in the attached image

error.thumb.png.55b156067454084ff83b44d4f8394aea.png

Edited by malc-c
Link to post
Share on other sites

I think you need to use the python scripts - bin2hex.py or binb2hex16.py

These scripts manage the bin2hex.exe program. One outputs eight records per line and the other outputs 16.

It was a while ago!!

python bin2hex.py -b filename.bin -o filename.hex

 

 

Edited by ozarchie
Link to post
Share on other sites

You should get a text file that starts something like this:

:020000040000FA
:2000000010280034FFFFFFFFA000030883120313A1000A08A2000408A3008A110A1200293E
:20002000DD20031DFF2F98138316813099000430980003178901031383121816981740307F
:2000400084008C1E212818193128981831281A0880002E3C031935284F300402031D840ADE

EQ6MCF204.PNG

Link to post
Share on other sites

I tried that

C:\Users\Administrator\Desktop\Firmware>python bin2hex.py -b MC004.bin -o MC004.hex
'python' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\Administrator\Desktop\Firmware>

I have both .py files in the same folder as the firmware and bin2hex

Link to post
Share on other sites

Archie,

Can you download the firmware for the goto dob flexitube from SW, convert it to HEX and either upload or drop me a PM with it attached or a link to a file download (dropbox or similar)

Cheers

Link to post
Share on other sites

Archie,  whilst I can code in PicBasic, and understand Arduino.... I'm getting out of my depth here with Python scripting....  I have no idea on which of the two files to download nor what to do with them once downloaded....

Any chance you can supply the HEX file as requested ?

I just tried the python -- version command and it's not recognised, so guess I would need to install python ?

Edited by malc-c
Link to post
Share on other sites

LOL - cross posting :) 

Just installed python, but again it's going to be a learning curve.... thanks for the file - saved me a lot of hair pulling :)

Link to post
Share on other sites

That loads into the PicFlash - Just need to get the PIC and get hold of the board from the OP (or see if he's comfortable with replacing the PIC once programmed

Thanks mate for all your help....

Link to post
Share on other sites

Archie,

I have some 16F866's in my hobby box (DIL versions but would do for testing).  The converted code loads, but when I burn it to the PIC it fails with this message.  The programmer can identify the PIC, erase it / blank it etc but it just won't upload... any ideas ?

Scrub that.... not sure what i reset but itn uploaded without error that time !!

 

 

error2.png

Edited by malc-c
IGNORE ERROR
Link to post
Share on other sites

I've had it confirmed by Astro-geek...

Pic have been ordered, hopefully here tomorrow.  I have a PCB from an old project that I used an ICSP header to program a 28 pin PIC in the same package so should be a "simple" case of holding the chip to the pads and squirt the HEX (which now loades without issue to the DIP version of the 16F886) to the PIC....

At least if this fails we've tried everything we can... all magor chips will have been replaced, and the OP has checked voltages against the known working board... if this doesn't work then there is little else we could do other than remove and test every SMD left on the board......

Link to post
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.