Hi Miles,

my XRFs seem to become unresponsive sometimes. I have three XRFs v1.5/2012 with firmware 0.47B.

One is connected to a PC through an Nanode/Wicked Device FTDI adapter. That one has the MCU/RESET line wired to pin 16:

https://picasaweb.google.com/lh/photo/cOXwU1V_56PWp63m9-GDfpkAR_Ec8GLtOpSHvLBP8uc?feat=directlink

Another is plugged straight into an Arduino Fio:

https://picasaweb.google.com/lh/photo/gUlvZjvW2kMMXrh-2RjL4JkAR_Ec8GLtOpSHvLBP8uc?feat=directlink

And the last one is connected to a Nanode running at 3.3V:

https://picasaweb.google.com/lh/photo/EaW9zSlrTmIIo2QVZBL1NpkAR_Ec8GLtOpSHvLBP8uc?feat=directlink

When programming the Fio, it sometimes works and sometimes doesn't. In both cases the XRF on the FTDI becomes unresponsive and needs to be power cycled.

The XRF connected to the Nanode board also sometimes becomes unresponsive during boot up or usage. Seems to be a random process. I have the Nanode to echo back characters transmitted and I can see it stop to communicate. The Nanode still works fine as I can access it over the Ethernet link. Power cycling the XRF brings it back to life.

The setup options are:

ATBDE100 -- Baud rate 57600
ATRC3 -- Enable channel hop for programming, both ends need to match
ATDR4 -- Radio data rate 100 kBaud
ATEE1 -- Enable encryption
ATEK<key> -- Set encryption key in HEX (32 chars)
ATFC0 -- Serial output flow control - no flow control
ATID514D -- Set PANID to MQ (hex 514D)
ATLIR -- RSSI mode (PWM between 10-100% indicating RSSI level, clears to 0 after 5 seconds of no RX)
ATPK20 -- Maximum radio packet data length in hex (min 1, max 240 = 0xF0)

And the FTDI connected one obviosuly has

ATRIXX -- Temporarily set the remote ID as "XX"
ATRP1 -- Turn on the generation of the remote reset request

set and the devices the corresponding

ATMYXX -- ID XX

XX is just a placeholder, I use different IDs for the Nanode and the Fio.

What strikes me is that only the XRFs on the XBBO breakout boards seem to become unresponsive. Am I missing some connections here? Should I connect some other XRF pins on the XBBO to ground or Vcc? Could it be that leaving some of them floating can trigger the crashes?

Any other idea, what could cause the effect?

Thanks,
Marc

Hi,

did some more tests:

1) Set the packet size back to 12, no difference.

2) Soldered the 1k resistors (pullup + 2 LED) in plus LEDs. That confirms that the chip is really stuck. With ATLIH I can see the heartbeat stop.

3) Soldered a wire from GND to SLEEP, no difference. Sleep mode was set to off any way, but I thought some noise on the line might trigger the problem.

All the best,
Marc

What I suggest is to issue ATRE to restore defaults, just set up with Remote ID, remote reset and baudrate, anything else leave off to start with. No channel hop, no PANID change, certainly no AES or over the air rate change. Then perhaps swap the XRF's over if the same is happening.

Let me know where you end up. I am actually quite surprised you got so far with all those changes to settings, we wont have tested them. The TI AES, processes in chunks and adds a resonable overhead, lowering the over the air data rate, upping the baud rate and turning on AES sounds like a recipe for stretching the operating parameters to the max.

We have had spencers nanode programming fine (we don't have any of them at ciseco) this was with all generic settings and channel hop of 3.

In the articles section is the odd drop of test code, do normal wireless comms work as you would expect? is it just the reset that causes this or is it at the end of programming?

Hi Miles,

OK, that seems to work much better. The XRFs do not crash and about half the time the programming works. The other half I get:

avrdude: stk500_loadaddr(): (a) protocol error, expect=0x14, resp=0x4e
avrdude: stk500_paged_load(): (a) protocol error, expect=0x14, resp=0x61
avrdude: stk500_cmd(): programmer is out of sync

Not sure, what this is trying to tell me.

Next step is to enable encryption again, because that was my main reason for using the XRF over the RFM12 modules.

All the best,
Marc

Hi Miles,

same test as before, but with

ATEK <key>
ATEE1

added to the setup and now I get the XRF to lock up not just on programming, but also if I send a 140 character string. The trigger is sending larger chunks of data, not the reset. The reset works fine all the time.

Any idea how to fix this?

Thanks,
Marc

Hi Miles,

lowered the baud rate to 9600, but doesn't make a difference. Obviously, programming won't work at that rate, but even at 9600 the XRF crash with my 140 character string (I'm just copy & pasting it into the terminal program).

Will now try the lowest possible baud rate of 1200...

All the best,
Marc

Hi Miles,

good news! 1200 baud works with encryption. Couldn't crash the XRF any more at that speed.

Can you do some tests with encryption enabled and see what the maximum reliable baud rate is? It must be between 1200 and 9600...

Also, do you know if there is a way to change the upload speed for reprogramming? If I can lower the 57600 to 1200 I'm fine. I don't care that it will take ages as long as it works reliable.

All the best,
Marc

Hi Miles,

one more question: AES uses a block size of 128 bits. Does that mean I should set the packet size to 16 bytes? Or does something in the TI chip add 4 extra bytes so that 12 is the best choice to work in chunks of AES blocks?

Thanks,
Marc

You wrote - "avrdude: stk500_loadaddr(): (a) protocol error, expect=0x14, resp=0x4e
avrdude: stk500_paged_load(): (a) protocol error, expect=0x14, resp=0x61
avrdude: stk500_cmd(): programmer is out of sync"

The arduino bootloader has no inbuilt mechanism for retries, if any data is missing or currupt the upload will fail. If the bootloader were rewritten to do acknowledgements and retires it could be made totally reliable. The channel hop is recommended if you have other XRF's broadcasting in the same location so they dont "clash".

When using radio, methods need to be added to ensure integrity at both ends, as we have no control over the IDE or the AVR dude loader it's the best than can be achieved with our hardware and standard bootloader. We talked about modifying the Arduino bootloader to "do i"t, but then AVR dude would need changing too. In the end we concluded that very few people would want to use a none standard Arduino bootloader. As over the air programming becomes more used and well known, it's something that I'm sure will be addressed one day, I keep meaning to engage with Arduino themselves, having support built into the IDE would be the only sensible approach. Time has prevented this so far.

You wrote - "added to the setup and now I get the XRF to lock up not just on programming, but also if I send a 140 character string. The trigger is sending larger chunks of data, not the reset. The reset works fine all the time. Any idea how to fix this?"

Excellent discovery, it's almost certainly something we need to add to our bug list.

If the data being pushed through is less than the AES block we pad it and then remove at the other end so you dont see it, it's not something the TI chip does, it's something we "discovered" that and the other million and one other things we have to work around.

On the v1.4 we clocked over 70k throughput with AES on.

The packet length being set to 16 mmmmmm, I totally understand what you mean. It's something I need to discuss, if there were no over the air part then yes this would probably be good. I'll check if any multiple is a better choice than any other.

You are so detailed and patient, it makes supporting you so much easier, huge thanks, it really helps. We'll test AES here and figure out why it's not doing what we intended.

Hi Miles,

any update on this?

Thanks,
Marc

We havent been able to reproduce the same behaviour, in looking it did however mean we found a bug elsewhere in AES, I think poping on our latest alph firmware is worth a try, we think it's perhaps not in AES it;s just turning it on might make it show up. Can you email me direct milesatciseco and I'll pop it over to you.