Being a staunch advocate of VB6 (the cool version of Visual Basic, that - still - works on all versions of Windows, not that crappy bloatware .NET version) it didn't take long to knock up a simple test interface for our atmega128 chip.
The idea is that the chip monitors a number of pins and, when the state of any pin changes, the pin and direction (on/off) is reported back to the host over serial. It's a pretty simple concept - but one that's kept us occupied for a few hours this evening.
So when a pin goes low (we're using the internal pull-ups on the input pins to avoid having them floating around) we send a serial message, decoding the pin that triggered the message into an index number. When a pin goes high, the same message is sent, this time with the leading bit set to one, to indicate that the pin has toggled.
Our VB app simply ticks a tick box each time a particular index is received.
On box for "on" and one box for "off".
In each square, once both "on" and "off" messages have been received, the square turns green. After initial testing, we had this:
All of the boxes, bar the top four had successfully received an "on" and an "off" message. Of the red boxes remaining, none had received either an or or off message. It looked very much like the change of pin state wasn't being registered.
The first thing, of course, is to test continuity on all the soldering joints. Surface mount soldering the atmega128 chips isn't exactly difficult, but it's possible that one or more pins haven't actually joined properly to the pads they're sat on.
The test rig looks a bit shonky, but the wires have been rammed home firmly and there's no way they're coming out! So maybe it's the soldering on the other side?
Ok, the soldering isn't the prettiest, but it's functional - all the pins on the microcontroller have continuity to the connectors around the edges of the board (all except pin 38 which etched badly and came away, but we're not using that pin in our code).
The problem doesn't seem to be the hardware, so it must be the code.
After spending a good couple of hours re-writing the code - to effectively do the same job, but using a slightly different method - the problem remained. After tracing back the non-responsive pins to our PCB, and in turn tracing those back to the atmega128 pinout, it turns out that it's half of PORTF that's not responding.
A quick Google for "atmega128 portf problem" and one of the top answers was this page: http://www.avrfreaks.net/forum/problem-portf-and-portg-atmega128
"And of course if you try and use portf 4-7 you need to turn off the JTAG fuse."
That looks like it!
Caught out by another atmega128 gotcha.
Disabling the JTAG fuses and re-programming the chip, and the results are much more encouraging;
Our first full successful board test.
So far, we've been bridging the empty board contacts where the hall sensors will go (there's no point soldering 48 sot-23 sized hall sensors onto a board if it's badly designed and won't work from the outset!). After tonight's successful test, we'll be able to hook up the hall sensors and confirm the final board design, in order to get the gerbers posted off to a fabrication house for manufacture.
If anyone else has problems with PORTF on an atmega128 in future, check your JTAG fuses (and disable them if necessary!)
No comments:
Post a Comment