I've done very little SMT (basically I did the button and knob light mod) and was wondering whether you use solder paste in jobs like this or is that only when you're soldering straight onto the board.

You must have smaller probes. That was one of the first things we tried, but we can't quite get into the pins on the inside row.

And we use very fine gauge rosin solder, although there is more than one way to skin a cat. Paste could work as well.

Stu

Solder paste doesn't work very well in this situation as it is very hard to get the amount right. It also tends to get behind the pins whereupon it doesn't heat very well and wont wick easily. I practiced various techniques on an old SIMM card, and just couldn't get the paste to work well.

The approach that works best (for me anyway) is to use the iron to 'paint' the connection. The blob of solder on the end of a 1/16" tip is enough to solder several pins. Start by fluxing all the pins, position the new chip and tack two opposing corners. Verify the alignment, add more flux, and then drag the blob slowly along the line of pins, allowing a couple of seconds per connection. When each pin heats up it will wick solder off of the iron and into the connection whereapon it heats the other pin and results in a good solder joint.

    ||  ||  ||  ||  ||

         (OOO)

        [TTTTT]     Drag slowly --->

        [TTTTT]

 

The keys to this technique are flux and patience. If you don't allow a enough time per pin then the solder won't wick properly and you'll end up dragging a bridge of solder across _all_ the pins. If you don't have enough flux then you will also bridge adjoining connections. With a hundred connections to make it is likely that one or more bridges will be made anyway ('cos we're not pro's). Clean all solder off of the iron, add flux to the bridged pins and reheat. Often this is enough to wick out the bridge - the solder wicks back onto the iron. In stubborn cases where this doesn't work, fine desoldering braid will wick it out (with flux, obviously). When this happens you'll need to repaint the connection and also a couple each side of it as the braid isn't fine enough to only hit one connection.

This technique is used by many professionals to mount fine SMT chips to boards - they paint the pads and rely on the wicking action to draw solder under the pin. In this way they avoid physical contact with pins that are easy to bend. Allegedly they use the biggest tip size that they can get into the board as it holds the most solder.

I managed to stack 4 chips on my SIMM using this method. I haven't tested each and every connection, but they looked good.

DISCLAIMER - This post is purely informational in nature. I do not accept any responsibility for any actions taken based upon this post,

You must have smaller probes.

Hmm. Both of my 2 sets are the same size, One set is BK Precision, and the other Extech, I don't think that they're especially small - kinda standard.

If you're having problems with the probe touching other pins then heatshrink can help to insulate most of the probe. Orient the board so that you're looking face on at the pins and bring the probes in from each side - this way you're running the bottom probe through the gap and not across it.

Check pins 48 & 49. If I'm understanding Mark's debug output correctly then these two pins are floating/shorted high. Note that pin 50 is Vss.

One thing I've noticed is that part of the boot log reports as above with the same error we've been getting, while another part of the boot log says:

"Memory: 31240k/32M available (980k code, 20k reserved, 524k data, 4k init)"

So which part is to be believed?

Stu

Not sure...Mark will have to chime in. One thing that I can tell you is that the kernel appears to try to test for beyond 32MB, and that you will get "c2000000 wrote ffffffff, read 00000000" as it tries to test the first location beyond 32MB.

Both parts are to be believed.

If you see (as posted) 32MB being reported by the kernel, then the memory has passed Hijack's DRAM test and is now being used!

So look very closely at the Hijack "Checking for extra DRAM" messages.. probably failed on c2000000 rather than c1000000, right? Hijack has detection support for up to 64MB of DRAM now, though I think there was something somewhere I needed to fix for it all to work properly.. forgotten now..

Cheers

64MB?!?!? Hm!!! That sounds rather interesting! Has anyone done it yet? I still have a bunch of chips left... Very tempting...

I have a feeling Paul would be the first to go for the 1gb ram upgrade if someone managed to work out how to do it :-)

Just think of the caching I could do!

It has been said that it would be do-able though very difficult.
IIRC, it wouldn't work for another reason : with four chips stacked onto one, the stack would become too high. Well, high enough to get in the way of the drive bay anyway.

Actually we're still getting "Checking for extra DRAM at c1000000: wrote 00000000, read c0000000 " or sometimes "Checking for extra DRAM at c1000000: wrote 00000000, read c0" at the beginning of the boot log and further down it reports 32 MB, hence the confusion.

Stu

Make sure you are using Hijack v391 for this. What you say it's doing should not be possible with Hijack v391.

-ml

They've arrived, funny, they look a lot smaller in real life than on the pictures in the forum.

It's funny that. I noticed the same thing. As have the people I've asked to solder the things :-(

Heh - I'm going to wait till the early adopters have ironed out the bugs, then I'll need to have a brave day when the kids are out to try it. I'll probably go the whole hog and actually buy a small soldering iron too which I maybe should have used for the button light hack.

Right then, I've sorted out access to the SMT stuff at work for this afternoon. Wish me luck....

BTW: Who's currently doing repairs to damaged empegs? Just covering all eventualities.

EDIT: Just realised I'm now officially a veteran, next stop Pooh-Bah!!!

Aw yeah. Worked first time...

Checking for extra DRAM:

c1000000: passed.

c1100000: passed.

c1200000: passed.

c1300000: passed.

c1400000: passed.

c1500000: passed.

c1600000: passed.

c1700000: passed.

c1800000: passed.

c1900000: passed.

c1a00000: passed.

c1b00000: passed.

c1c00000: passed.

c1d00000: passed.

c1e00000: passed.

c1f00000: passed.

c2000000: wrote ffffffff, read 00000000



empeg:/empeg/bin# cat /proc/meminfo

        total:    used:    free:  shared: buffers:  cached:

Mem:  31920128 15552512 16367616  1306624  8257536  4747264

Swap:        0        0        0

MemTotal:     31172 kB

MemFree:      15984 kB

MemShared:     1276 kB

Buffers:       8064 kB

Cached:        4636 kB

SwapTotal:        0 kB

SwapFree:         0 kB

Thanks Paul, Mark, Hugo, Stu and everyone else who took the punt.

Nice work!!!

If you see any performance changes (improvements), please
post them! Let us know what we can look forward to. I know
Mark has already started to do so, but it is nice to see what
others find as well. Thanks!

Okay then, well I'm getting there. I'm currently stuck at:

Checking for extra DRAM:

c1000000: wrote ffffffff, read fbffffff

So nearly there.

Pin 43, I think. Can't remember which chip.

It's Hijack 3.90. Does that make a difference?

We get this from the web-based memory report:

total: used: free: shared: buffers: cached:
Mem: 31928320 31211520 716800 1568768 8466432 10616832
Swap: 0 0 0
MemTotal: 31180 kB
MemFree: 700 kB
MemShared: 1532 kB
Buffers: 8268 kB
Cached: 10368 kB
SwapTotal: 0 kB
SwapFree: 0 kB

Stu

It's Hijack 3.90. Does that make a difference?

It looks like Mark rewrote the memory management code in v391. It's not clear why, but I'd suggest upgrading anyway. It's entirely possible that there was a bug in v390 that you are seeing.

Pin 43, I think. Can't remember which chip.

Bingo!

Checking for extra DRAM:

c1000000: passed.

c1100000: passed.

c1200000: passed.

c1300000: passed.

c1400000: passed.

c1500000: passed.

c1600000: passed.

c1700000: passed.

c1800000: passed.

c1900000: passed.

c1a00000: passed.

c1b00000: passed.

c1c00000: passed.

c1d00000: passed.

c1e00000: passed.

c1f00000: passed.

c2000000: wrote ffffffff, read 00000000

.....

Memory: 31240k/32M available (980k code, 20k reserved, 524k data, 4k init)

Oooh! Lovely....

empeg:/empeg/bin# cat /proc/meminfo

        total:    used:    free:  shared: buffers:  cached:

Mem:  31920128 10387456 21532672  1335296  3674112  4747264

Swap:        0        0        0

MemTotal:     31172 kB

MemFree:      21028 kB

MemShared:     1304 kB

Buffers:       3588 kB

Cached:        4636 kB

SwapTotal:        0 kB

SwapFree:         0 kB

Congrats! Which method did you use in the end?

"I want my...
I want my...
I want my memory..."

(sorry Dire Straits fans...)

Congrats! Which method did you use in the end?

A bit of yours and a bit of something else.

I managed to get the afternoon in our test room on Friday. So I started by straightening the pins and making sure they sat nicely on the existing pair of chips. Once I was happy a dab of Pritt-Stick held them in place. To do the actual soldering I used what the guys at work affectionatley call the Nanoprobe, which looked like a minature temp-controlled Weller iron to me. The tip is smallest I've seen. I then did the soldering under their microscope setup which was quite cool.

Under the scope I applied a small amount solder to the tip of the iron (which actually looked like half a tonne under magnification) and then press it against the pin until the solder flowed off the tip and onto the leg of the chip. I repeated this process until I'd done all the legs on the first chip. After feeling quite pleased with myself I then went and tried your method. This worked well too. In the end there was just that one dodgy leg on the first chip. A quick press of the iron onto the leg must've resweated it.

The most difficult bit was making a satisfactory connection to RAS line on the StrongARM.

Here it is:

Upgraded to Hijack 3.91 we get:

Checking for extra DRAM at c1000000: wrote 000 .....
Memory: 15016k/16M available (980k code, 20k reserved, 364k data, 4k init).....
Memory: 31240k/32M available (980k code, 20k reserved, 524k data, 4k init).....

The web utility gives:
total: used: free: shared: buffers: cached:
Mem: 31928320 29294592 2633728 1703936 8466432 9687040
Swap: 0 0 0
MemTotal: 31180 kB
MemFree: 2572 kB
MemShared: 1664 kB
Buffers: 8268 kB
Cached: 9460 kB
SwapTotal: 0 kB
SwapFree: 0 kB

It is only showing around 2 MB free. Where did all of the rest go if it's got 32 total as reported?

What gives? Why do we get all of these different values reported?

Stu