emonTx blocked while booting

Hardware emonTx
1

HI,
I have two emonTX boards.
one board stopped at below

'+++' then [Enter] for RF config mode

also it can’t enter to RF config mode.
I did tested my FTDI board to another emonTX board working.
another One board works well and can enter to RF Config mode with my FTDI board.

at oscilloscope RX pin shows my +++ input key is send to emonTX.
Also I verified Fuse is same with another board like below.
Signature : 0x1E 0x95 0X0F
Fuse: 0xFD 0xD6 0xFF
LockBits: 0xCF

Boot procedure:

emonTx V3.4 Discrete Sampling V3.00
OpenEnergyMonitor.org

Loaded EEPROM RF config >
RFM69CW Node: 255 Freq:  Group: 0

POST.....wait 10s
'+++' then [Enter] for RF config mode

and I did flashed firmware.hex by my ISP programmer but blocked at above.

Any advise would be appreciated.

2

That is incorrect, the NodeID should be < 31 - the default is 8, and the Group should be 210.
I think your hex image might be wrong.

Do you have the Arduino IDE? Can you compile and load the standard default sketch from GitHub - https://github.com/openenergymonitor/emontx3/tree/master/firmware/src
(You need both files.)

3

Yes EEPROM data looks broken,

however although eeprom data is incorrect, board must go into RF configuration mode with +++

And I download below link hex file again.

emontx3-master\firmware\compiled\firmware.hex
same result.

also i rebuilt firmware.hex again below.
result is same.

emonTx V3.4 Discrete Sampling V3.10
OpenEnergyMonitor.org

Loaded EEPROM RF config >
RFM69CW Node: 255 Freq: Group: 0

POST…wait 10s
‘+++’ then [Enter] for RF config mode
(Arduino IDE Serial Monitor: make sure ‘Both NL & CR’ is selected)

Thanks in advance.

4

According to the source code on that forked github link (why are you using the fork and not the original?), you can update the the nodeID to 8, RF freq to 433 and group to 10 in the EEPROM by typing:

+++
i8
g10
b4
s

when you see that prompt.

If you already have a different one with node ID 8, use a different node-id :slight_smile:

5

@Greebo
I was working on the premise that the .hex file is corrupt - therefore we have no assurance that the rest of the code is intact. That is why I suggested downloading the source and recompiling.

6

From the post above, it appears that the OP has recompiled (albeit from a forked repo, although I couldn’t find any changes in there to the two src files from the original repo…)

Reading through the source code, a corrupt RFfreq EEPROM setting will also cause this behaviour. It looks like somehow the 2nd and 3rd EEPROM bytes have been set to zero making the code think they had valid values in them.

Alternatively, the OP could run one of the myriad “clear EEPROM” Arduino sketches and try it again, which (according to the source code) will use the following defaults:

byte RF_freq=RF12_433MHZ;                                           // Frequency of RF69CW module can be RF12_433MHZ, RF12_868MHZ or RF12_915MHZ. You should use the one matching the module you have.
byte nodeID = 8;                                                    // emonTx RFM12B node ID
int networkGroup = 210;
7

But a corrupt EEPROM didn’t explain why it won’t enter the reconfiguration routine ("+++"), whereas loading a corrupt .hex file might. As we appear to have ruled that out now, it’s looking very much like a hardware fault. I think an email to the shop is next: [email protected] .

8

Oops, I missed that line in the first post…

If you pass a node ID of 0 to

rf12_initialize(nodeID, RF_freq, networkGroup);                         // initialize RFM12B/rfm69CW

what is the behaviour? According to the comments, ID 0 is reserved for OOK use
Could that be locking something up in this section ?

9

Yes, it’s blocked at rf12_initialize(nodeID, RF_freq, networkGroup); // initialize RFM12B/rfm69CW

And I cant use Arduino or pio flash programmer by uncertain issue.
So I use AS4 ISP programmer.
When I erase flash , EEPROM data becomes 0xff so then it makes blocking RF12 initialize routine.
any idea for recover EEPROM , would be appreciated.
or i should modify source code.

Thanks.

10

If the EEPROM values read are all 0xff (255), a set of appropriate defaults are loaded instead. If that is still blocking at the initialize routine then as @Robert.Wall suggests you probably have a hardware fault.

11

when I add below for manually configure program works.
if (flag > 0){
Serial.println(“Loaded EEPROM RF config >”);
}
else {
Serial.println(“No EEPROM config”);
}
// for protect blocking init rf12
nodeID = 8;
RF_freq = RF12_433MHZ;
networkGroup = 210;
Thenk hardware is working.
i m curious why 0xff makes blocking.

12

NodeID = 0 DOES cause the RFM initialisation to block (as does the wrong RF module type - RFM12B instead of RFM69CW)

But NodeID = 255 does not - it reads it as 31 as expected.

If you can erase the EEPROM (with another sketch) to all locations = 0xFF, that will load the values in the sketch and it should allow you use the EEPROM normally.

13

Thank you,
I did manually set RF config then save to EEPROM.
next remove manual RF config routine, then it works normally.

Thanks again.

14

The original EEPROM ended up setting nodeID to 255, RF_freq was 0 which was essentially undefined and networkGroup was 0.

If nodeID = 255 is interpreted as 31, then that shouldn’t have locked it up, networkGroup = 0 means all groups, so that shouldn’t have locked it up which only leaves the RF_freq being undefined as the root cause?

15

Apparently not. When I do that, the EEPROM config works normally, and after a restart the sketch runs, but I can’t say whether it transmits or not, as I’m monitoring 868 MHz and the emonTx I’m using is a 433 MHz RFM12B one.

16

Thats very odd then, did you try setting the networkGroup to 0?

17

I hadn’t, but same behaviour as frequency.

18

Sounds like a mystery that I need to let go of then. :smiley:

19

But nevertheless, all bytes=0 is a lock-up that can be prevented, as 0 is an illegal value for our purposes for all 3 bytes. I’ve PM’d Glyn & you about this.