RFM12Pi with RFM69Pi Firmware = Help!

Firstly, I’m an absolute beginner when it comes to this stuff so bear with me.

So I have been running the original OEMGateway SD card on my Emonhub since 2014 and decided that I’d update to the latest version of EmonCMS to start logging locally using the latest SDcard image. In the process of getting everything set up and in my eagerness to get my old Emonhub updated to the latest firmware versions, I used the Update Emonhub function in EmonCMS and managed to upload the RFM69Pi firmware into my RFM12Pi. As a result the RFM12Pi is no longer functioning and the activity LED is always on.

I have tried following the RFM12Pi V2 wiki guide to upload the RFM12_Demo_atmega328 firmware however after I run $ avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:RF12_Demo_atmega328.cpp.hex (also tried baud rate at 9600) nothing happens and the function just appears to hang indefinitely and returns no further information or errors.

Have I completely bricked my RFM12Pi? Any help with this would be very much appreciated!


Further to the above, if I try to communicate with the RFM12Pi using

sudo service emonhub stop
minicom -D /dev/ttyAMA0 -b9600

I get no feedback or errors at all when pressing v. I have tried using both 9600 and 38400 as the baud rate with no success. The below is as far as I get

Welcome to minicom 2.7

Compiled on Jan 12 2014, 05:42:53.
Port /dev/ttyAMA0, 05:26:33

Press CTRL-A Z for help on special keys

Hi Steve

You are not the first and unlikely to be the last user to do that. it is IMO a mistake that is far too easy to make and the consequence is a huge headache at best.

Take a look at the "Unable to see emonTx inputs " thread for more info on this.

Basically the wiki is a bit out of date and the RFM2Pi repo has been moved around, plus there is a glitch in the emonSD that prevents the rfm2pi repo from being updated on the SD when the update routine runs. The actual firmware you need to install hasn’t been changed in a while but the location has, so we/you can either just download the correct firmware and try to install it “manually” or fix the repo on the SD so it updates and the firmware’s correct location is then known for the command line to work, I would probably go with the latter.

However based on the findings towards the end of the linked discussion, there is also a possible issue with running the avrdude command, I only mention this in case it doesn’t work when tried, IMO if you managed to install the wrong firmware it should be just as possible to install the correct one, It could also have been a bad connection so please ensure the RFM2Pi is seated correctly and try not to remove and refit it too often.

Changing the baud and/or using the “v” command will not work when the wrong firmware is installed as the initial setup will not complete the “wrong RFM module” will not initialize and the firmware will stall before reaching the point of listening to the serial port.

Firstly SSH in and try this one command

sudo avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400

This will try and communicate with the RFM2Pi without uploading anything, just to check we have good comm lines.

If that was successful,
(here’s an example output from a emonpi so the details will differ but essentially the same, ignore the “strace” errors, that’s normal)

[email protected](ro):~$ avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200
avrdude-original: Using autoreset DTR on GPIO Pin 7

avrdude-original: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude-original: Device signature = 0x1e950f

avrdude-original: safemode: Fuses OK (E:00, H:00, L:00)
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe

avrdude-original done.  Thank you.

strace: |autoreset: Broken pipe

you can try a firmware update with the following, it will (hopefully) fix and update the firmware repo then stop emonhub and upload the firmware, then restart emonhub.

sudo chown pi:pi -R RFM2Pi
cd RFM2Pi
git pull
cd firmware/old/RF12_Demo_atmega328
sudo service emonhub stop
sudo avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:RF12_Demo_atmega328.cpp.hex
sudo service emonhub start  

At this point you can check the LED on the rfm2pi, hopefully it will be giving an occasional flash, you can check data is passing through emonhub (if you have set the com_baud = 9600 in emonhub.conf) with

tail -f /var/log/emonhub/emonhub.log

if there is data flowing you should see some inputs in emoncms update, if not, try stopping emonhub and testing with minicom again.

1 Like

Hi Paul,

I really appreciate your assistance with this issue and am happy to say that I’ve been able to get the correct firmware back into the RFM12Pi, however it wasn’t without issue.

Firstly, as you suggested, I tried

sudo avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400

And got zero response with the pi just hanging as it had done previously. After reading the thread you posted above, you mentioned starting with a fresh SD card image which made sense to me as I had changed quite a few things following the RFM12Pi wiki page, plus a few other things while I was clutching at straws.

I reflashed with the Nov16 image (did not perform any updates) and removed the RFM12Pi and re-seated it. I then tried the above command again and this time with success! Unfortunately I can’t say which issue got me up and running again, the fresh image or the RFM12Pi connection, however I’m thinking it may have been the connection due to the next issue.

The next issue was that the firmware reflash failed a number of times at the middle to late stage where it was reading what I assume to be the firmware that had just been written. The fix? To hold firm pressure on the RFM12Pi above the connection block while I ran the flash again.

I am now getting my inputs into EmonCMS after changing the board rate to 9600 in the emonhub config file, however I think I am probably going to end up with gaps in my data due to the intermittent poor connection and no doubt it will get worse over time, so I have ordered a RFM69Pi to replace the RFM12Pi.

Again thanks for your time to respond to my issue and in helping me get up and running again.


Suggest that you may have a faulty connector - and likely to also get problems transferring packets of data over that as well.