Problem with D.Out Circuit

[Jidis]

Hi again,

I know this is asking for a big fat "I told you so", but I'll throw it in here anyway-

I just built a compact board that I want to use to work on some MB64 apps. Everything but the Core and the LCD are on one big, double-sided, crowded board. The D.In (165) chain is 3 chips long with the last output pulled high. The D.Out (595) is 4 chips with the last hanging open. The A.In is only one 4051. They've all got the necessary resistors and the supply and ground pins for each IC have been checked.

Now the weird stuff. I threw all the lines on a single 5x2 pin header. It's got ground, 5v, sclk, rclk, a line to the 595's, a line from the 165's, a line from the 4051, plus the 3 mux lines. The shift register clock/latch lines are jumped in parallel from chip to chip (595's and 165's). They all check as solid connections, all linked back to the main header. The IC to IC connections for each chain have also been double checked. Now the dumb part. No sockets. Everything went directly to the board, but was heated as briefly as possible with a low watt iron (23w maybe).

Problem-

Looks like the last two 595's are not cooperating. I figured to be safe and check a chain at a time, so I went for the LED's, and only used a five pin cable from my core (at J8) which covers the D.Out data pin, the clock lines, and Gnd/5v. The other chips are onboard and powered up, with the unconnected 165's still riding the clock/select chain with the 595's, but I don't have them, or the 4051 sending anything back right now. For right now, I'm using a button board with it's own 165's, that I already know works.

When I power up the core, I get the first four LED's of the 3rd shift reg. on solid (p.7,6,5,4), as well as the fourth light on the last register (p4). They stay on, and the other eleven outputs for those chips don't work. The first two register's lights all look OK.

I know swapping the last two IC's is the obvious solution, but needless to say, it's a bit harder to do in real life. If TK, or anyone who knows enough about the serial chain or those IC's, can think of anything that may cause that type of behavior, it would be a big help. I think I'll lay off it a day or two to get my nerves back.

The individual out pins to the anodes have all been checked, and the cathodes all hit the resistors to ground (470ohms in my case). I don't see any obvious shorts on some quick checks (definitely not shorts to 5v or Gnd), but I guess there's a possibility. I also guess the 3rd shift could be f**king up the 4th one, so I'll pull that first if I have to. I don't know if there would be any downside to having three stray 165's on the clock and power lines if they weren't connected to the core. I also don't know how easy it is to cook a shift register by soldering directly to it (well, maybe I do now).

                                        Thanks for reading all this crap if you did!

George

PS- I know I probably should have stuck the core circuit on there too and soldered the 18f directly to the board as well, but I wouldn't want to do anything "stupid".;D     

[TK.]

Hi George,

how many shift registers are enabled by the application? The number is normaly set with MIOS_SRIO_NumberSet

It's save to set it to 16 (max value)

Best Regards, Thorsten.

[Jidis]

Thanks Thorsten!

I grabbed a folder with the MB64 source & hex in it when I dumped the app into the PIC. I'm not sure how many SR's I had it set for, but I checked it with my first 32 LED board (also has it's own 595's), and all 32 LED's worked with that app. Both boards have the same number of D.Out registers and the same 1-4 IC chain, so the app should be OK.

Does the additional unused (165/4051) chip thing sound like it could affect the select lines? Or, could there be any affect from the route that the selects take from chip to chip? It's all parallel and they are all getting the two signals from the core, but there are different lengths involved.

One final look at it last night, and it looks like I can yank the data line to the last two IC's and rewire it to a breadboard circuit with a new 595 to make sure that there is a good signal coming off pin nine of the 2nd chip. Most of the chip to chip lines are jumpers rather than traces. Of course that will temporarily make for even more unused chips on the power and clock lines, but the max will only be 8 or 9 altogether with the 165's.

-George  ???

[TK.]

Does the additional unused (165/4051) chip thing sound like it could affect the select lines? Or, could there be any affect from the route that the selects take from chip to chip? It's all parallel and they are all getting the two signals from the core, but there are different lengths involved.

I'm not a layout expert, maybe bypass caps at the power rails help? ;-)

Best Regards, Thorsten.

[Jidis]

Thorsten,

After lots of unnecessary desoldering and breadboarding, I got this worked out last night, but it was 5am and I was too tired to post. :-\

The 595's turned out to be healthy and happy, and I didn't have to remove any. I ended up finding a solder short between the datalink from IC 2 to 3, which was touching one of the output pins to an LED. I've also got several "ground pours", which are on isolated islands, and I found one that had NO jumper taking it to the rest of the plane. Then of course it also had the resistors for about 5 of the LED's linked to it, so they were all hanging open with no return path.

                                                                                                                                                                                              :-[

The board is cool looking, but it's a mess "route-wise". It's arranged for a 40x2 to sit right in line with 4 vertical sets of knobs, lights and buttons, so I should get to play with some MB64 screen layout tweaks that somebody else might find useful. My board is double-sided, but I was too lazy to rearrange my traces to get everything routed, so I just attached holes and jumped them on the bottom. It also had a bunch of traces right on the edges, which didn't transfer well, so they had to be jumped too.

After I got the lights going, I went ahead and connected the D.In circuit. All the buttons work, but it's got some really nasty jitter on them (I do have all the input pin and data links pulled high with the 10k's). Looks like I'll be dealing with some of the same messy board crap on that one, so it may be a few days before I can play with my new toy.

                                                                                                                                                                                              :'(

                                                         Thanks again for the help!

George

[Jidis]

All the buttons work, but it's got some really nasty jitter on them (I do have all the input pin and data links pulled high with the 10k's).

-------oops!  Actually, they're not all pulled up! :-X

Found a bunch of switches with no resistors and solved my jitter problem.

TK or anyone else- Is there a "usual" cause of one or more LED outputs that reverts to high, or that flicks on periodically when there is circuit activity elsewhere?

I've got one on this, but I've seen it on a few other occasions.

                                                                                           -Thanks!

[TK.]

TK or anyone else- Is there a "usual" cause of one or more LED outputs that reverts to high, or that flicks on periodically when there is circuit activity elsewhere?

they only flicker if the LEDs are multiplexed, and interrupts are disabled for a short time (e.g. during a Flash or EEPROM write), or if the RCLK line is not connected properly

So: normaly they should not flicker

Best Regards, Thorsten.

[Jidis]

Yeah, this is actually worse than flicker. I've got one that pretty much stays on.

I'll double check the clocks. There could be noise or a short on the actual LED line too. It's a standard 595 D.Out setup. It's funny, I knocked out all the pain in the a** layout and construction stuff on this board really quick and it all worked, but then I proceeded to make every simple careless mistake I could find on the small stuff. ;D

-Thanks as Always!

George

---News---> Could be an app thing. ??? I just dumped the D.Out buttons test app and got no LED mess, plus the light wasn't coming on until after the MB64 app init. I'll check the files to make sure I don't have something set to toggle an LED, etc. I thought it was a fresh MB64 hex file.

[TK.]

If this happens with the MB64 application, it must be a hardware issue

Best Regards, Thorsten.