Recently I've been testing (with success) the new RFM69CW RF module, it's pin compatible and backwards compatible with RFM12B, JeeLabs JeeLib RF12 driver now supports the RFM69CW. It's been tested to work on emonTx V2, emonGLCD. RFM12Pi and emonPi.
RFM69CW on RFM12Pi
All was going well until I fitted an RFM69CW to a board with a blank ATmega328 (no bootloader), I went ahead to upload a bootlader via arduino (or avrdude) in the normal way and the ISP upload failed. So I investigated further...
It seems when the RFM69CW is fitted to reset line is only asserted low for half the time compared to when the RFM12B (or no RF module) is fitted. See scope trace below.
The red trace shows a healthy ISP reset when the RFM12B is fitted (90ms) and the blue trace shows the reset line when the RFM69CW is fitted (50ms).
So, the question is can avrdude be set to force reset for longer..? I'll investigate. Has anyone else noticed this problem? I've still not been able to post on the forum, do you need to do something with my account..
I'm using an an AVRISP MKII ISP programmer with the board powered by 3.3V and running the following AVRdude command which checked for the presence of a chip and reads it's device signature.
$ sudo avrdude -c avrispmkii -p m328p -P usb -v
Re: RFM69CW ISP Upload Problem - Reset timming
When you're using the ISP, I'm pretty sure it holds the target AVR's /RESET low for the entire transaction. That puts the AVR into a dumb SPI slave mode so that the ISP can act as a SPI master to program it. So it may be that the ISP is de-asserting /RESET because it's given up, i.e. the /RESET behaviour you're seeing may be another symptom, rather than the cause.
Do you have an external pull-up on the RFM69CW's /CS? I'm wondering if the module may think it's selected (because nobody is pulling /CS high) and so driving MISO which is interfering with ISP<->AVR transactions. Then when the ISP doesn't see the responses it expects from the AVR (because of that interference), it gives up and de-asserts /RESET.
You can't rely on AVR internal pull-ups for SPI /CSs if those SPI devices are going to be on the bus while you're trying to program the initial bootloader, because there's no code running on the AVR yet to enable those internal pull-ups.
Re: RFM69CW ISP Upload Problem - Reset timming
Yes! Your totally right, I was observing a result rather than the cause of the problem. Temporally puling up the RFM69CW SEL line (Dig10) with a 10K resistor solved the problem (update: 100K also works ok). Thanks for your help.
Looks like a hardware change might be needed (add pull-up resistor) in order to make the RFM69CW allow ISP upload onto a blank ATmega328.
Re: RFM69CW ISP Upload Problem - Reset timming
Glyn, I'm pleased to hear that the RFM69C now appears to be working correctly for you. My own experience was that, although I could get the revised code to run without locking up, no RF was happening.
Might it be possible to post some working code on the thread that I started about this, at http://openenergymonitor.org/emon/node/5162
An updated version of your simple RF checker sketches would be perfect :D