Archived Forum

Points to check:

1. You have the programmer the right way round on the FTDI header. GND is nearest the USB socket.
2. The 10 k connected to pin 1 of the processor (RESET) is not shorting to the ground plane.
3. You have 5 V on pin 3 of the FTDI when the programmer is connected.
4. Did you get the programmer from the shop? There are two sorts, I'm not sure of the difference, so can't help any more there.

Thanks for this

I did some resoldering and managed to get power via the FTDI. I successfully used the FTDI to upload a Sketch to the NanodeRF as well, so the FTDI must be working.

But the 'not in sync' error remains on the EmonTx:

1. You have the programmer the right way round on the FTDI header. GND is nearest the USB socket. - YES
2. The 10 k connected to pin 1 of the processor (RESET) is not shorting to the ground plane. - NO, READS 3.3v and 3.27V 
3. You have 5 V on pin 3 of the FTDI when the programmer is connected. - YES 5.17V
4. Did you get the programmer from the shop? There are two sorts, I'm not sure of the difference, so can't help any more there. - YES, from the shop

This isn't making sense at the moment. Obviously correct: Your programmer, drivers, USB lead, power supplies on your emonTx.

If you put the processor from the emonTx into the Nanode, can you program it there?

The Nanode processor looks soldered on. 

I'm ordering a Funduino where I can then hopefully swap out the processor and check if this one is working. 

I wonder whether the FTDI interface pins are long enough in my Emontx

I wonder whether the FTDI interface pins are long enough in my Emontx

If you can't feel the contact springs making, it's easily verified with a continuity test! Did you solder the header in the wrong way round (short side should go through the PCB).

If it does prove to be the processor, it might be that is is missing its bootloader. In that case, an email to the shop should solve the problem.

Thanks

Please advise what you mean by a continuity test? Short side of FTDI definitely goes through PCB, and the fact that power is registering means that at least the power pins are reaching. But some of the other pins are a couple of mm lower. How long do the pins need to be to make contact with the FTDI?

When you say drop an email to the shop on the processor regarding the bootloader. What does that mean in practice? Can I not install the bootloader using the Arduini IDE?

Can I not install the bootloader using the Arduini IDE?

You'll need an ISP and an ISP header on the device where you plan installing the bootloader (those empty 6 holes at the bottom of your CPU in your second photo).    You can also build an ISP out of an Arduino.

Thanks, I've got an Arduino on its way in the post.  

Do I need to get resistors as well?

I'm not sure what resistors you're referring to.  But you want to do something like this:

http://arduino.cc/en/Tutorial/ArduinoISP

I've not tried it myself.  I use an AVRISP MarkII, but it should be pretty straight forward.

[EDIT]

CAUTION: You need to be aware of the Vcc voltages.  If you're programming an 3.3V AVR in-situ, then you need to use a 3.3V ISP.  The AVRISP MarkII senses your target's Vcc via the 6-pin header and then uses the appropriate voltage.  The ISP built out of an Arduino probably doesn't / can't.  So you'll need to either move the AVR to a 5V environment before programming with that, or use a proper ISP.

Hi. I don't need to install the bootloader after all. The problem is not the chip:

I swapped the Atmel chip into an Arduino, and it works fine. I got the LED blink sketch working on it, and (after changing the LED pin number) I also got the chip blinking the LED in the EmonTX.

I then installed the EmonTX CT sketch via the Arduino and swapped the chip back into the EmonTX. It doesn't transmit anything to the NanodeRF. (both are set in the their Sketches to use 433hz to match their boards).

So clearly the chip works, the LED part of the EmonTX works, but the circuits that attach the RF module and FTDI have problems. Not sure how to test these.

NB. I resoldered so the FTDI pins on the EmonTX stick out all the same length out of the board.

Thanks to you all for you help - I realy appreciate this

Any advice on my next move?

You've certainly narrowed it down a lot then.  Robert's suggestion of a continuity test would be your best bet next.  And I see nobody answered your query about that.   With the power off on your EmonTX, your multimeter set to continuity-test mode,  and a copy of the schematic by your side, you want to buzz out the circuits that appear not to be  working.  So for example, confirm that each of the FTDI pins run all the way to where they're supposed to run.  I don't have the schematic handy, but presumably most of them end up at the AVR pins.

Now that you have an image that at least flashes the LED on the EmonTx, you should also be able to determine if your IDE is able to reset the AVR by observing the LED when you attempt do download a new image.  It's only by  yanking on /RESET (via RTS or DTR) that the IDE is then able to talk to the bootloader and send it a new system image.  If your blinking LED sketch remains undisturbed during a failed system image download, that would suggest that reset path is not working.  You might want to change it so that it's blinking the LED fairly rapidly, so you can notice any disturbances to the beat.  If the reset path is working, but the data path isn't, the bootloader will wait for about a second, see that it's not getting a new image and jump back to the current LED flashing image, so you're looking for a 1 second interruption to the LED flashing.

Oh dear!

The LED is not flashing this morning on the EmonTX. 

The chip however is still working fine as I have checked a number of times by swapping it into the Arduino

Checking voltage readings on the chip when in the EmonTX:

PIN 15 (for the LED pin) reads zero - but should be oscillating between high and low

PIN 1 (Reset) reads 2.89V

PIN 7 (VCC) reads 3.3V

PIN 20 (AVCC) reads 2.59V

PIN 26 (ADC3) reads 1.4V

PIN 24 (ADC1) reads 1.75V

PIN 9 and 10 (TOSC) read low V around 0.4-0.6V

PIN 6 (XCK) reads 3.95V

Does any of this make sense? In the Arduino PIN 15 as expected registers HIGH and LOW V as per sketch.

I also tried the continuity test on the reset path from the FTDI, and circuit is fine on both sides of capacitor C1, but could C1 be bust?

If the LED was flashing, and now it isn't, and you have touched nothing else, there has to be a bad joint or a component that is physically strained and/or damaged.

Pin 15 not switching means the sketch is not running, therefore either it's perpetually reset, the clock oscillator isn't running or, if you've moved away from the LED blink sketch and have a sketch that drives the RFM12B module, it's sticking while trying to initialise that. Pin 1 high rules out the perpetual reset.

Pin 20 not reading the same as Pin 7 is a worry - it's only a short track away so that needs checking. They read the same (to 2 decimal places - 3.27 V) on mine.

Are the USB connector pins soldered properly - it's hard to tell from the picture (but irrelevant if you're powering via the FTDI).
C5 also appears to not have enough solder on one leg.

Pins 24 & 26 should be 1.65 V - but that isn't this problem, those not being exactly mid-voltage between 0 V and Vcc will restrict the analogue input range, but not stop it working.

You won't read a sensible voltage on the oscillator pins (9 & 10) - mine read about the same as yours on a normal multimeter.

C1 only comes into play when programming - if the reset line is high, it's not going to stop the sketch from working. But if it is broken/lost capacitance, the processor won't program.

So sorry, but apart from the AVcc voltage, there's nothing abnormal there.

There appear to be some solder splashes. You could clean the board (solder side) by scrubbing the excess flux off with a hard brush (e.g. a discarded toothbrush) dipped in white spirit, afterwards wash the board in warm soapy water and allow to dry thoroughly (and by thoroughly I mean underneath all the components and inside the connectors, including beneath the RF module). Doing that might make it easier for you to see any soldering faults.

Thanks again Robert

I've cleaned the board as you suggested. Still waiting for it to dry completely, but from what I can see there aren't any solder short circuits. I had previously resoldered the FTDI pins and had already patched up C5.

There is some minor heat damage to the PCB around a couple of the FTDI pins now and also around between the aerial and adjacent pins of the RF module. Looking closely at these though I can't see any shorts or splatter. I'm thinking that I should probably remove the RF module completely once the board is dry. However I haven't used any sketches beyond the modified blink sketch for testing, so RF shouldn't have been engaged. 

I keep wondering whether the most suspicious component here is the Crystal or a capacitor. (But I note that C1 is not relevant if the sketch is already on the chip). Are there any other capacitors that I should worry about at this stage?

I'm wondering whether desoldering some components now would help to narrow down the problem. Which ones should come off first? Also, does the soldering of the DIL socket in my pic look dodgy?

At this stage, until you have proved a faulty component, I would suggest that desoldering anything should be kept as the means of last resort. I have to recommend that you do NOT try to remove the RFM12B. Unless you have access to the proper desoldering station, it's very likely that you will damage either the RF module or the PCB or both in the attempt. If you you are not driving the RF module, I think it can be discounted.

I didn't notice any other suspect soldering - I've seen a lot worse that has been OK, but it's much easier when you are looking at it for real than in a photo.

If you're still using the blink sketch, then provided all the soldering is good, I have to think it's got to be the crystal or the capacitors around it. I think it's possible to use an internal oscillator to drive the processor, but I'd need to look it up - unless of course someone else wants to chip in here?

I think you let it dry thoroughly, then check the AVcc voltage again. If that's still wrong, you need to find out why (with the processor out).

If you're still using the blink sketch, then provided all the soldering is good, I have to think it's got to be the crystal or the capacitors around it.

I'd concur with that.  If you give these AVRs a good Vcc and a good crystal, they can't help but run.

I think it's possible to use an internal oscillator to drive the processor, but I'd need to look it up - unless of course someone else wants to chip in here?

Yes, the CKSEL bits in the Fuse Low Byte lets you control the clock source,  and it also lets you control how big a swing you put into the crystal.  If you set it to Full Swing you can generally see it on a scope.   But you'll need an ISP to change those fuse bits, and if you do decide to go that way, recall my Vcc caution above.  Using the internal oscillator has it's own issues: you'd need to calibrate it if you want accurate timing (and you do want accurate timing to drive the UARTs at the correct baud rate).  So going that route might help narrow down the problem, but probably isn't where you want to end up.   And given it involves ISPs etc. it may be more trouble than it's worth.

then check the AVcc voltage again. If that's still wrong, you need to find out why (with the processor out).

Yes, that's very odd.  It would be interesting to see if AVCC is still low when the AVR is removed, i.e. is it the AVR that's dragging it low?  Is anything getting warm?

Thanks both

The board is dry and I've rechecked the voltages with the chip back in and the AVCC is still 2.something while the VCC is 3.2x. 

I also checked the the LED with the chip out, by shorting one of the 3.3V keyholes to the pin 15 on the DIL socket. LED lights up fine. 

I'll measure the Vs with the chip out and see what readings I get on the empty DIL socket:

(PIN numbers relate to Atmega328 mapping with PIN 1 = reset)

PINs 1-5 = 0V

PIN 6 = 5.14V

PIN 7 = 3.30V

PINs 8-14 = 0V

PINs 15 - 22 = 0V

PIN 23 = 1.34V (takes a few secs to settle)

PIN 24 = 1.35V

PIN 25 = 0

PIN 26 = 1.35V

PINs 27-28 = 0

So, I wonder why Pin 20 AVCC is reading 0V!!

So the schematic shows Pin 20 (AVCC) and Pin 7 (VCC) are connected, and should both read 3.3V.  It looks to me like your Pin20 is for some reason not connected.  With the power off you should be able to buzz out Pin7, Pin20 and VCC (picked up somewhere else on the board). They should all be connected.

Pin6 looks a bit high for a part that is being run 3.3V.  The schematic shows it runs via a 4.7K R to either VCC (3.3V) or PWR (5V) depending on the setting of SJ2.  It looks like there are a couple of jumpers that select VCC or PWR (SJ1 and SJ2).  I'll hand over to someone more familiar with the schematic than I am to explain what that's all about.

[EDIT]

I'm not sure why your Pin1 (/RESET) is 0V either.  That suggests something (presumably the FTDI programmer?) is holding the AVR in reset.   With the power off, you might want to check the path from Pin1 thru the 10K pull-up to Vcc also.

I'm almost starting to wonder if all your Vcc are actually at Vcc.

Pin 20 should definietly be the same voltage as p7 as they are connected by track under the AVR (see shop pic attached - the track just clips the bottom of the screenprinted "8")

Pin 6 does look high but is probably the result of 5v being picked up via the 4.7K res. There was an error on the first PCB's and a permanent short to 5v is present on the temp senser jumper pads, this was never changed as it panned out the temp sensor worked better at 5v even on a 3.3v based circuit.

Paul

Great work guys, and thanks for your help.

I resoldered some of the DIL pins (created a bit of a mess on PIN 20 which makes it now stick out above).

Now - my modified blink sketch is working, and the FTDI is working, and allowing me to upload sketch.

Next step now is to check if the RFM12b module is working. However, given the progress, I'm marking this thread as solved.

The RFM12b module is not working: the EmonTX Sketches don't work.

To test further, I set up a Sketch to initialise the module, as per the EmontTX transmit test example Sketch. I added in the lines required to blink the LED. If I comment out the rfm calls, then the blinks work.

I guess therefore that the RFM12b needs to be resoldered as well. Are there any voltages it should read that I should check for first? 

Your photo is not quite pin-sharp, but it looks as if the middle pad on the left-hand side of the RFM12B is a bit dodgy. I can't really tell for any of the others.

I did note that the module is twisted slightly, before you touch anything make certain that it is not skewed so far so as to make one of the pads touch the adjacent pad as well. Whatever you do, remember my warning above about unsoldering the module.

Robin Emley's technique for the RFM12B is to sit the module on a pad of double-sided tape to position it, then solder. (Obviously, that's too late for you.)

Okay. Had a go at resoldering the RFM12b. 

Terrible result  burned three slots - see the pic attached. 

To my total surprise, it works and the NanodeRF is receiving data from this EmonTx!

thanks again Robert, Paul and 'dBc'

Given the resoldering damage, I don't know if thus is going to work for long, and I still need to check the CT sensor inputs but very glad for now for the advice and persisting with this. 

In all honesty, I think you need some soldering practice before you next embark on something of this complexity and size, and I wonder whether the tools you are using are up to the job. The best advice I can give you is buy a mixed bag of cheap components and some stripboard, look at one of the many soldering guides and practice. Then when it comes to small stuff like the RFM12B and smaller still like the emonTx, get a big stand-mounted magnifier as well. You also need to make sure your soldering iron has the correct sized bit and is at the correct temperature. Generally, you'll do more damage if it is not hot enough (yes!) because you'll apply the heat for too long. You should be able to solder a single joint on stripboard in about 1 s. The usual reason tracks and pads lift is because the heat was on for too long.

In all honesty, I think you need some soldering practice before you next embark on something of this complexity and size

LOL. Yes, this was my first electronics soldering project. I also wanted to go lead free.

My next project will be to burn a few PCBs. ;)

You seem to have got away with it, but I'm afraid you came very close to making an expensive mistake. Get a handful of cheap components, some stripboard and practice, before you try your next plated-through double-sided PCB. Seriously.