Archived Forum

How did you upload the firmware? was it definitely successful?

Paul

I have tried uploading with both an AVR dragon and an Arduino as an ISP programmer. Both without errors. After upload of the firmware the LED turned on, so something changed.

I will try remove the RFM69PI from the pi and see if I can talk to it directly.

In the default sketch the LED is switched on as the first "setup()" command and turned off again after starting serial and configuring the rfm device. If the LED remains on the chances are the problem is rfm related, 3 possibilities spring to mind 1) Is "#define RF69_COMPAT" correctly set (1 for 69 or 0 for 12) ? 2) Is the rfm device connected correctly ie good connection and orientated correctly (xtal is opp sides on 12/69) or 3) have you powered up the 3.3v rfm with 5v during upload with ISP?

Be very careful when using ISP with the RFM2Pi boards, it is a 3.3v ONLY board.

If using the last 6 pins of the GPIO connector on the RFM69Pi to connect ISP the ISP MUST be 3.3v if the rfm69 (or 12) is already fitted because they are not 5v tolerant.

Paul

Thanks.

I've uploaded the hex file from here https://github.com/openenergymonitor/RFM2Pi/tree/master/firmware/RFM69CW_RF_Demo_ATmega328, so I guess its correct settings for the RF69??

I'm aware of the 3.3V and I'm sure it hasn't been exposed to 5V.

Its placed and looks like this: http://wiki.openenergymonitor.org/index.php?title=RFM69Pi_V3 but as I read there is no need for the Xtal as its using its internal resonator.

I was referring to the rfm xtal rather than the (unpopulated) avr xtal. The avr does use an internal resonator.

A recent glcd issue flagged up a ref in the build guide to orientate the rfm12 by its xtal location not being useful when using a rfm69 because the xtal is on the opp side. The rfm can only be attached 2 ways so it would be obvious if fitted wrong when comparing to image.

It must be getting stuck in these few lines, since it isn't a tiny those lines can be ignored

is your jeelib upto date ?

yes the radio is oriented correctly.

I'm uploading the hex files, so the library version should not matter.

I've tried uploading the blink.hex and that works.

Could it be that since i'm using a 868MHz radio it get stuck as the hex file is compiled for 433MHz?

I will work on being able to compile it locally.

Could it be that since i'm using a 868MHz radio it get stuck as the hex file is compiled for 433MHz?

I wouldn't of thought that would be an issue although I cannot be 100% sure.

Yes, you are right about the hex and jeelib

​If you were able to edit and compile on the Pi you could add a couple more led flashes to narrow the search too.

Do you have a screen and keyboard attached or can you use "remote desktop connection" to get to a gui desktop on the Pi? the avrdude-rpi in my repo is altered to allow use of the arduino ide. 

I thought of using a FTDI adaptor directly to the RFM69PI. I'll try that later today.

I've added some printout in the setup function

  displayVersion();
      Serial.println("start");
  if (rf12_configSilent()) {
    Serial.println("test2");
    loadConfig();
  }
  else {
    Serial.println("test3");

and the output is:

[RF12demo.12]start
 

So it seems it get stuck in the rf12_configSilent() function

digging a little deeper it stops in the call to RF69::configure_compat() in the rf69_initialize function

Okay I recreated the hardware with new PCB and radio and now it works. I will do a test of the radio to verify if it was DOA.

A feature request is to have it write to serial and flashing the led or something, if it cannot initialize the radio. Right now it just get stuck so you are not able to communicate with it. this behavior can be reproduced with a RFM69Pi without a radio mounted.

Thanks

for helping