Partially dead PIC in MB-6582?

MIDIbox SID
1

Hi, I’m hoping for a sanity check here.  I just finished testing my MB-6582 baseboard (using SmashTV’s kit) with the SID testtone app (bridging pins 8 and 27 on the SID sockets) and discovered that I get a 1Khz tone out of all SID sockets EXCEPT U1_SID1 (second from right).  Here’s how I tried to narrow it down to the CORE1 PIC:

  • LCD on CORE1 has normal messages (SID Testtone Generator) + I get the upload request for CORE1 on MIDI In monitor in MIOS studio when CORE1 is selected for output on J11 ==> CORE1 PIC is powered up and partially working

  • Verified output buffer circuit for non-working output by bridging pin 8 on a working SID socket to pin 27 of non-working SID socket ==> Worked, therefore the output buffer is OK

  • Tested continuity from pin 8 of non-working SID socket to pin 24 (fourth from bottom right) of CORE1 ==> Worked, so no problems between CORE and SID socket.

  • Swapped CORE1 and CORE2 PICs.  Audio output now fine from both SIDs on new CORE1.  Output from original CORE1 not working.  (I can’t remember if I tested both SID outputs on the original CORE1.) ==> CORE1 section of PCB is fine

  • Swapped PICs back.  Now neither SID output connected to CORE1 works.  All 6 other SID outputs work fine. ==> ???

  • Re-tested output buffers of first two SID sockets from other good SID sockets ==> Works, so output buffer circuits still OK

  • Tried bridging output pins (pins 24 and 27) on CORE1 PIC directly to output buffers on SID sockets (pin 27) ==> Failed, so apparently I’m getting no output on those PIC pins

I also tried re-uploading the testtone app (selecting CORE1 on J11) and I cannot re-upload the app (first block sent, no response from PIC).  I tried to re-upload the testtone app onto the other COREs and it fails to upload on them also, so this is not unique.  (IS THIS NORMAL BEHAVIOR?  I THOUGHT I COULD UPLOAD APPS AS MUCH AS I WANTED?)  Hmm, I should probably try removing CORE1 and re-trying the upload.  (NB: I uploaded the testtone app to each CORE in its own socket, so MIDI In/Out was working fine initially.)

So unless figuring out why I can’t re-upload the testtone app uncovers something, it seems my PIC output pins (27 and 27) are dead.  Am I missing something obvious here?  Any ideas before I order a new PIC?

TIA,

Chris

2

I’m by no means an expert, but do all of the PICs have the correct ID header?

3

To start with, stop calling it “CORE1 PIC”… refer to each PIC by the PIC ID that you (or SmashTV) burned into it, in this case they should be 00, 01, 02, 03, which get installed into Core 1, Core 2, Core 3, Core 4.

Try uploading testtone to each PIC in Core 1. Note J11 needs to be set to 1, and MIOS Studio upload dialog needs Device ID set to match PIC ID (0-3). Always remember, MIOS Studio directs the upload to the PIC, it doesn’t matter which Core it is in, only J11 needs to match the Core you are uploading to not the PIC

You need to fix the upload problem before moving on to the SID/SID module testing. Then, you can test each PIC in each Core to determine which is a “known good” PIC and which are “known good” SID modules. Try uploading something else (like the interconnection test) so you know the upload really worked.

If you fix your uploading problems, then start testing SID output sections again and report results, try to report what works like “testtone app in PIC 0 in Core 1, pin bridging both SID sockets, both audio sockets have tone” etc.

The key to good troubleshooting is only changing one thing at a time and noting the differences (what starts/stops working).

4

Thanks for the replies.

Yes, the PICs have IDs 00,01,02,03 per the label on them from SmashTV and I see the PIC ID output in the upload request in the MIDI In monitor so I think I’m good on that.

I’ll try uploading the interconnection test in CORE1 with each PIC (maybe during lunch if I have time) and go from there.

Thx!

C

5

Update: I re-tested some stuff as described below using Wilba’s nomenclature for PICs vs COREs (makes this much easier to describe, thx!).  Here’s where I am:

Uploaded SID interconnect app, one PIC at a time slotted into CORE 1:

PIC 0, CORE 1 - uploaded successfully

PIC 1, CORE 1 - uploaded successfully

PIC 2, CORE 1 - uploaded successfully

PIC 3, CORE 1 - uploaded successfully

So uploads are apparently OK on CORE 1.  I must have gotten mixed up w/ MIOS settings and J11 settings before my initial post.

Tested SID interconnect app:

PIC 3, CORE 4 - interconnect OK for both SID sockets except CS# on U2_SID4

PIC 3, CORE 1 - interconnect OK for both SID sockets except CS# on U2_SID1

PIC 2, CORE 1 - interconnect OK for both SID sockets except CS# on U2_SID1

PIC 0, CORE 1 - interconnect OK for both SID sockets except CS# on BOTH U1_SID1 and U2_SID1

PIC 0, CORE 4 - interconnect OK for both SID sockets except CS# on BOTH U1_SID4 and U2_SID4

So this implies that the interconnect test app does not test CS# on U2_SIDx.

It also implies that something is up with PIC 0.

Uploaded testtone app 4 times, all 4 PICs slotted at once, setting J11 to each core:

PIC 0, CORE 4 - uploaded successfully

PIC 1, CORE 3 - uploaded successfully

PIC 3, CORE 2 - uploaded successfully

PIC 2, CORE 1 - uploaded successfully

So this confirms uploads are working in all COREs.

Tested output by bridging SID socket pins:

PIC 0, CORE 4 - no output from either SID

PIC 1, CORE 3 - test tone from both SIDs

PIC 3, CORE 2 - test tone from both SIDs

PIC 2, CORE 1 - test tone from both SIDs

Bridged pin 27 of U1_SID4 to pin 8 of U1_SID3 - got test tone

Bridged pin 27 of U2_SID4 to pin 8 of U1_SID3 - got test tone

This confirms the output buffers are working for all COREs.

This confirms that pins 24 and 28 on PIC 0 are not outputting anything.

At this point, I think it’s time to order another PIC unless anyone has further ideas..?

On the positive news side, I pulled the 6581 out of my ancient and non-working C-128 and got the test tone out of it!  I’ll have to upload the SID app to determine if the entire chip is good I suppose, but at least I got to hear the chip do something..!  Glad I bothered to hold onto my broken C-128 for all these years!

Presumably I can move along without PIC0 until I can get a replacement. My front panel arrives Monday, so I can start on the control surface then. I also have the 6581 to play with while awaiting my 6582s, so that should keep me busy.

Thanks again for all the help!

C

6

OK that makes it easier for me to follow, thanks! :slight_smile:

I agree, it appears like PIC 0 is not behaving like the other PICs… you’ve proved it with the interconnection tests.

I wish everyone’s troubleshooting reports were like this, you’ve basically done every logical combination to identify what does and does not work and where the fault lies, and the fault definitely lies with PIC 0.

Perhaps if you dare, peel back the label on PIC 0 and PIC 1 and compare the ICs… in the highly unlikely event that SmashTV has sold you something that is not a PIC18F4685 :)  It is just too strange for a PIC to be working but have a problem with only a few output pins, unless perhaps those outputs were fried by high voltage or static electricity… very strange.

I think you could use the changeid application (carefully!) to change PIC 4 to have ID 0, then use this as your PIC 0 in Core 1 in the short term… for the control surface to work, you need a PIC with ID 0 in Core 1, and for master->slave comms you need a PIC 0 to be the “master”.

7

No, thank you for the help and the sanity check.  I know how irritating it can be to remotely debug stuff, so you must have quite a high level of patience with all the questions you get. :slight_smile:

I’ll check the label just in case, good idea.  SmashTV is uncannily thorough so it is unlikely that is the issue but anything is possible.  One of the two dead pins initially worked so I suspect it is somehow my fault.

I’ll try the change ID app, thanks for the suggestion.  I figured the master had to be PIC 0, but I’ve not picked through the docs that far yet.  I built a PIC burner a while back that will probably support the '4685 so in the worst case I can always fall back to that.

Beer will be on its way shortly…

Thx,

C

8

The only real danger with changeid is accidentally changing the bit that controls UART baud rate, i.e. between standard MIDI and MIDIbox-to-COM. If you only change it to 0x00, 0x01, 0x02, 0x03 then there’s nothing to worry about.

9

Just took a quick peek at the changeid readme on my lunch break.  TK conveniently supplied a ready-to-load .hex file for the change, woohoo!

10

I ran the changeid application and it worked great.  Of course I don’t have the control surface built yet so I can’t really do much w/ it.  I did use the MBSID editor and verified that all oscillators and the filter work on my pulled 6581, so that was great!

11

Just a quick followup to close out this thread.  I ordered a new PIC from SmashTV (got it last week but have not tried it yet).  However, SmashTV saw this thread and insisted on replacing the dead PIC at no cost and sent me a refund.  So I just wanted to let folks know that SmashTV really has gone the extra mile here which just further confirms my complete confidence in his products and services.

Now hopefully tonight I’ll have some time to check out the new PIC…

Thanks again Tim!

12

Just a quick followup to close out this thread.  I ordered a new PIC from SmashTV (got it last week but have not tried it yet).  However, SmashTV saw this thread and insisted on replacing the dead PIC at no cost and sent me a refund.  So I just wanted to let folks know that SmashTV really has gone the extra mile here which just further confirms my complete confidence in his products and services.

Now hopefully tonight I’ll have some time to check out the new PIC…

Thanks again Tim!

Hi, I’m having a similar problem with my pic’s apparently .Has replacing them solved your problem?

thanks!

Vlad

13

Just a quick followup to close out this thread.  I ordered a new PIC from SmashTV (got it last week but have not tried it yet).  However, SmashTV saw this thread and insisted on replacing the dead PIC at no cost and sent me a refund.  So I just wanted to let folks know that SmashTV really has gone the extra mile here which just further confirms my complete confidence in his products and services.

This isn’t “aimed” at fussylizard, just a general thought: The chance that you actually get a broken PIC from Smash is very very small. Typically you made a mistake somehwere. A lot of times builders blame the PIC when it turns out it’s something else - blaming the PIC seems popular. Smash is a really nice dude and does his very best to make sure you get good stuff, his packing is nuke-proof and his prices are as low as can be - please don’t abuse his niceness by “guessing” your PIC is wrong and “demanding” a refund/replacement before you’ve done some severe troubleshooting and KNOW it’s not something else or YOU that broke the PIC :slight_smile:

14

This isn’t “aimed” at fussylizard, just a general thought: The chance that you actually get a broken PIC from Smash is very very small. Typically you made a mistake somehwere. A lot of times builders blame the PIC when it turns out it’s something else - blaming the PIC seems popular. Smash is a really nice dude and does his very best to make sure you get good stuff, his packing is nuke-proof and his prices are as low as can be - please don’t abuse his niceness by “guessing” your PIC is wrong and “demanding” a refund/replacement before you’ve done some severe troubleshooting and KNOW it’s not something else or YOU that broke the PIC :slight_smile:

This is off topic.

I have been troubleshooting for ages and I’m almost sure that 3 of my PIC’s are damaged. If they are damaged than it’s more likely that they have been damaged by me (no guessing) and the last thing I would do is “demand” Tim to reimburse me for it. But I’m sure you’re not aiming at me anyway.

15

It wasn’t aimed at anyone in particular, that’s why it was prefaced with “…just a general thought”. :wink: