EmonTx Arduino shield + Leonardo + RFM69CW = problem

blazejka · 2018-05-18T20:28:38.399Z

Hello,

I have a problem with EmonTx shield v2.4. I added RFM69CW radio and followed wiki + spent whole weekend doing fault finding unsuccessfully if shield is connected to Arduino UNO - everything works fine but if connected to Arduino Leonardo it simply won’t work I have tried older version JeeLib and all sorts of pin swaps but sketch (CT1234)always hangs here “rf12_sleep(RF12_SLEEP);”. I know that easiest thing to do would be just use UNO with EmonTX shield but I’m sort of obsessed now about it. If someone would find few minutes to help I would be very grateful.

Robert.Wall · 2018-05-18T21:28:18.602Z

Is this the Wiki you followed? GitHub - openenergymonitor/emontx-shield: emonTx Arduino Shield

blazejka:

sketch (CT1234)always hangs here “rf12_sleep(RF12_SLEEP);”.

Do you mean it never reaches that statement, or that it fails to return after it?

blazejka · 2018-05-18T21:33:24.009Z

I’m not an expert but I believe it never comes back from sleep. What I’ve done was this:

Serial.print(“dbg1”);
rf12_initialize(nodeID, RF_freq, networkGroup);
Serial.print(“dbg2”);
rf12_sleep(RF12_SLEEP);
Serial.print(“dbg3”);

and in serial monitor I can only see dbg1dbg2 that’s why I believe that it never comes back from sleep.

Robert.Wall · 2018-05-18T21:46:04.249Z

OK, thanks. The usual problem with radios is a bad connection, then usually it is inside rf12_initialize(...) that it gets lost and fails to return.

Other people have used a Leonardo successfully, so it can be done.

Which option did you choose for the jumper settings?

blazejka · 2018-05-18T21:47:07.667Z

digi10 for SS pin and digi3 for IRQ

Robert.Wall · 2018-05-18T22:00:51.095Z

I’m not an Arduino expert, so I think I cannot help you any more. Hopefully, someone else will be able to get your working.

blazejka · 2018-05-22T11:09:55.504Z

This weekend I went even further with debugging and this is what I found:

fresh install of win7x64 and latest arduino + fresh libraries (so far all my work was done under Ubuntu) - no change
using Bus Pirate as a SPI sniffer I see that there is nothing transmitted to FRM69CW module when shield is connected to Leonardo.
in the same time when shield is connected to UNO there is a lot transmitted to RFM69CW (I don’t have to understand SPI protocol - all I wanted to see is there anything going on on SPI)
I programmed Leonardo as a ArduinoISP and used Leonardo to upload sketches to UNO - that works as it should so ICSP header on Leonardo is not the problem here
I uploaded blink sketch to Leonardo and verified where pins are mapped (D14, D15, D16, D9, D10 and D3) so it’s not pins_arduino.h for Leonardo being wrong.

The only thing that is left is JeeLib.h but debugging that is beyond my skills. It’s worth highlighting that if anyone is to follow wiki, even step by step, emontx shield will not work with Leonardo

Robert.Wall · 2018-05-22T11:48:51.273Z

If you wish, you could ‘steal’ the file “rfm.ino” from the 3-phase PLL sketch (on Github) and try that, instead of JeeLib. It is a stripped-down version that only transmits, and it is slightly different, so you’ll need to look at the 3-phase sketch itself to see the exact way to use it - you’ll need to include in your sketch some pins and some definitions as well as the function calls.

blazejka · 2018-05-22T20:48:09.515Z

Thanks for advice but rfm.ino looks even more complex to me so I’ll pass on this one. For now I’ll use Uno. I might move to Due or IoTaWatt.

Robert.Wall · 2018-05-22T21:40:41.264Z

blazejka:

looks even more complex to me

It is actually a much simplified, cut down version of the transmit part of JeeLib, but as you wish.

dBC · 2018-05-22T23:16:11.766Z

blazejka:

using Bus Pirate as a SPI sniffer I see that there is nothing transmitted to FRM69CW module when shield is connected to Leonardo.

Where are you picking up /CS (aka SS) for the Bus Pirate? If you’re seeing "nothing transmitted’ on the Bus Pirate, that makes me think you’re seeing no transitions on /CS.

blazejka · 2018-05-23T15:27:41.698Z

I started with soldering cable to leg/pin 7 of the RFM69 module (NSS) there was nothing there to trigger data capture so I moved to digi10 on the shield itself - still nothing there. Re attached shield to UNO ant there was SPI transmission. So taken Lonardo back uploaded blink sketch, changed LED pin to 10 connected an LED to pin 10 just to check is the pin 10 working with different sketch and LED was blinking Of course I also have used different jumper to link leg 7 of RMF69 to digi10 on the shield (as you can choose between digi10 and digi5).

blazejka · 2018-05-23T16:43:10.954Z

I read your question again. When I say no transmission I mean nothing is happening on either of the pins 10/14/15/16 which are (in my understanding) SPI bus pins. And this is only true for leonardo where for uno there is a lot going on on those pins.

dBC · 2018-05-23T22:18:37.845Z

I’d probably focus on why /CS is not going low because without that, nothing will happen. If you look in the jeelib sources you’ll see a lot of:

bitClear(SS_PORT, cs_pin);
...
bitSet(SS_PORT, cs_pin);

They’re doing direct port/pin manipulation to drive that, and they go to some effort to calculate that based on cpu type in

// function to set chip select pin from within sketch
void rf12_set_cs (uint8_t pin) {
#if defined(__AVR_ATmega32U4__) //Arduino Leonardo
  cs_pin = pin - 4;             // Dig10 (PB6), Dig9 (PB5), or Dig8 (PB4)
#elif defined(__AVR_ATmega168__) || defined(__AVR_ATmega328__) || defined (__AVR_ATmega328P__) // ATmega168, ATmega328
  cs_pin = pin - 8;             // Dig10 (PB2), Dig9 (PB1), or Dig8 (PB0)
#endif
}

And the shield wiki tells you to edit that to do it slightly differently, although I suspect that was written when jeelib didn’t handle the different cpu types. Some Serial.print()s in there to see which pin it’s actually driving should narrow it down.

dBC · 2018-05-24T04:27:12.670Z

blazejka:

pins 10/14/15/16 which are (in my understanding) SPI bus pins.

What do you mean by pins 14, 15 and 16? The Uno and the Leonardo use different pins for the SPI bus, but shields can pick them up at a common place via the ICSP header.

I think the best approach would be to get your /CS (aka SS) up and running first.

blazejka · 2018-05-30T18:37:49.443Z

I’ve tried wiki version & unmodified latest version of JeeLib.h. I’ve read somewhere that issue with CS pin it’s all sorted for mega32u4 after library update but I can’t find reference at the moment.

If you check PCB:

RFM69CW	UNO	LEONARDO
MISO	D12	ICSP1 (D14)
MOSI	D11	ICSP4 (D16)
SCK	D13	ICSP3 (D15)

SEL (SS) can be connected (by jumper) to D10 or D5
IRQ can be connected (by jumper) to D3 or D2

MISO/MOSI/SCK are connected on PCB with D12/D11/D13 so shield would work on both UNO and Leonardo.

dBC · 2018-05-30T22:34:45.454Z

My suggestion would to be to focus on the code inside jeelib that drives the CS (aka SS) pin. It looks like this:

bitClear(SS_PORT, cs_pin);
...
bitSet(SS_PORT, cs_pin);

Work out why that’s not driving the pin you want it to drive (I think you said you confirmed that there’s no activity on /CS with the Leonardo?).

bitClear() and bitSet() are pretty fundamental operations so they must be changing some pin (or there’s a conflict on the pin that prevents it from changing). With your logic analyser and some Serial.prints to determine the value of SS_PORT and cs_pin it should be pretty easy to get to the bottom of it.

blazejka · 2018-05-31T19:43:09.448Z

I started this thread in hope that there is something simple that I’m missing. I spent a lot of time debugging without any success. In the same time I have learnt a lot but that wasn’t my original target Thank you for all help and support but I cannot spend any more time on something that should work anyway I wanted to leave something in writing if someone else will run into similar problems in future. My guess is that at some point JeeLib library was changed/updated and since then shield won’t work with Leonardo. My original plan is to move from my custom breadboard copies / modifications of yours great products and just standardise everything and move away from ESP8266 to RFM69 which I have never used before also get rid of raspberry PI and run emoncms on my VM. It’s not going great at the moment but I need to have this finish before I move from my rented property to my 1st home. So please don’t get me wrong but shield works with Uno so I’ll stick with that. Thanks again for your time.

pb66 · 2018-05-31T20:36:53.582Z

blazejka:

My guess is that at some point JeeLib library was changed/updated and since then shield won’t work with Leonardo.

I think you are right there, whilst I do not know the answer to your problem, I do recall some changes being made in JeeLib that might or might not be related.

The discussion I recall is this one from Nov '17 that questions the changes made in May '17.

github.com/jeelabs/jeelib

Make SPI_BIT and SPI_SS consistent

committed 12:37PM - 18 May 17 UTC

JohnOH

+5 -5

That discussion seems to have led to those changes being reverted and these changes being made

Prior to that there were some earlier changes too in Feb '14 , Mar '15 and Oct '16, which pins are correct, current or compatible with the OEM emonTx shield I wouldn’t like to guess, but perhaps you, or someone else reading this if it’s too late for your project, might be able to make head or tail of it.

blazejka · 2018-05-31T20:55:09.695Z

I’ve tried all variants of the pin configuration that you mentioned above. None of them worked. There must bee more changes in the code. There also were some changes in Arduino pins configuration for mega32u4. At some point D17 was used as a SS in JeeLib.h but same pin is used for RX LED so that was quickly changed to D10. I’m willing to donate my Leonardo to anyone who want’s to have a go at it