Hello everyone,

Miles sent me over here to ask you for some help in installing a couple of radios with the correct firmware for OTA programming and using the Ciseco carrier shield for the XRF radios.

OK so this is what I have. 2 XRF radios revision 1.4 they are both running a version .35 of the firmware that will not allow me to us XCM to configure them for OTA programming.

I am also using the "active" versions of the XBBO v1.3.

My questions are :

1. where do I get the latest firmware from to allow OTA programming
2. does the MCU reset pin on the breakout board connect to pin 17 and alow me to use the Arduino IDE to programme through without the need to use AVRDUDE natively.

Thanks in advance for all your help.

Cheers Pete.

OK first we are going to need to update your firmware to 0.41 and make sure thats still a talking serially then we can move on to setting up the OTAMP bits

form openmicros.org/index.php/articles/84-xrf-basics/180-all-xrf-firmware-updates
download the following
Bootloader.hex
XRFv1-3andv1-4/SerialPassThru-0.41.hex

make sure your XCM is upto date, build number should be 1.0.4451.39256 or higher, there should also be and advance button on the upload firmware tab.
if not latest XCM can be found here
openmicros.org/index.php/articles/84-xrf-basics/105-xcm-software-config-for-the-xrf

using the two .hex's you have follow this guide to updating the firmware's for both 1.4 XRF's
openmicros.org/index.php/articles/84-xrf-basics/134-uploading-to-bootloaderv2hex
for best results you need to do the bootloader then the Serialpass one after the other with out quitting XCM or removing the XRF

also before uploading check that your XRF's are set to baud rate(ATBD) of 9600, as thats the speed for the bootloaders

let me know how you get on with this, ill have more on the OTAMP later today, back to work for now


Matt

Thanks for the quick response Mat,

I Used the files from the section marked "Version 1.3 & 1.4" since my XRF is marked v1.4.

Uploaded the bootloader with no problems but when I go to upload the firmware I get the following message from XCM "Error- file is the wrong hex version"



Cheers Pete.

ah sorry try the version posted in this thread

openmicros.org/index.php/component/kunena/10-ciseco-support/714-xrf-firmware?limit=15&Itemid=0&start=15#748

Thought Spencer might have updated the website copy by now.

Thank You Mat,

Now I have one pair of radios re-flashed with the 4.1 firmware and ready to rock and roll. Time to break out the ATMega's slap on some xtals and lets see if we can OTA program the little beasties.

Cheers Pete.

OK Here are the setting need for the XRF's there given as if typed into a serial terminal but if you have XCM running you can use that to set the rite box's just remember changing the ATBD Baud rate, once written ATWR and then applied ATAC you need to change the Baud rate for XCM in the top box to match!

The baud rate to use will be dependant on the bootloader of the target ATmega, 115k for optioboot 56k for the older loaders

Pin 17 of the XRF socket on the XBBO is wired to the MCU reset pin, note there is also a 0.1uf capacitor in there

You didn't mention how the local XRF was connect to your computer so I assume some FDTI board?
You will need to connect the DTR and/or the RTS line form the FTDI to pin 16 of the local XRF


remote XRF settings based on OTAMP guide


local XRF setting based on OTAMP guide

OK that is all set up .... BUT i am not seing a reset pulse on the remote XRF

I have my DTR conected to pin 16 on the local one. I have an LED confirming that it is being toggled.

I am not seeing any response from the remote XRF when i toggle it using X-CTU. Also have an LED connected on the remote to see if i am getting any response. ... nada, nothing.


If however i use the old nija trick of pressing the reset button myself as the avrdude is searching the it "sometimes" attempts to send the file but ALWAYS results in a series of blocks being send and ending up with the following error

avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x10
#################### | 100% 65.48s

avrdude: failed to write flash memory, rc=-4
avrdude: Send: Q [51] [20]
avrdude: Recv:
avrdude: Recv:

avrdude done. Thank you.



Cheers Pete.

You could try putting the XRF's into test mode to confirm the reset is being received at the remote end. This article shows you how...

openmicros.org/index.php/articles/84-xrf-basics/150-otamp

The AT command for both XRF's are.

ATNT1
ATWR
ATDN

and use the same sequence but ATNT0 to turn test mode off. When you toggle reset in XTCU you should see it being send and acknowledged in the Serial terminal

How far apart are the XRFs? The problem might not be anything to do with OTAMP, but might be that they're too close together. I've had some very odd things happen when they're under a meter away.

This article may help openmicros.org/index.php/articles/84-xrf-basics/149-troubleshooting-xrfs

Spencer

Pete, what would be really useful for us to know is if you are using mac/windows/linux as we are finding out the reset procedure differs on platform and even revision of arduino IDE.

A good test is to put an LED to pin 12 and GND of the XRF, you'll see a very brief (3ms) flash, this shows the XRF is recieving and actioning the remote reset request (pin17 does a 3ms low in tandem). There's also the test mode refered to earlier which really helps.

Hi Miles,

I am running it in windows XP pro. I know the DTR line is being toggled as I have an LED on that. I can also use the same USB-Serial bridge to program the AMD directly through the serial interface. This eliminates the protocols, AVRDUDE command line parameters, DTR/RTS compatibility issues etc. I have placed LEDs on the slave XRF but am not seeing any LED pulses. I also have my logic analyser set up and it is also not getting a trigger on either edge. I tried setting the XRFs into debug mode but they both stopped responding to serial commands and I had to do a factory reset to bring them back to life again. I have another job that is pressing me for attention at the moment but I will be back to this soon as the client is asking me for a feasibility assessment. I have no doubt that this will all work in the end 

Cheers Pete

From the doc, the best 2 bits are

It senses a 'wiggle' on pin 16 of the XRF connected to your PC (usually DTR) and then 'wiggles' pin 17 for 3ms on the XRF at the remote end to perform a reset of the micro.

Remote reset, how do I know it’s working?

What we can do is turn on a test mode (yes it probably stops RF to serial) at either end which will show us in plain text what is happening. I suggest using XCTU as it’s convenient, there’s a tick box to wiggle RTS (this is the pin connected on a ciseco USB interface) your interface might be using DTR instead. This control signal on pin 16 is identical to shorting pin 16 on the XRF to ground, you can also do this manually with a wire. When you have set up the XRF as shown below you will see aMYRESETSENT. From the far end once it is set to the settings below you will get back aMYRESETRCVD. You could also put an LED, short leg to pin 17 and long leg to pin 1 (3v3). It will flash for half a second.


Master (PC Connected) XRF
+++
ATRP1
ATNT1 (testmode)
ATRIMY
ATWR
ATDN

Slave (Remote) XRF
+++
ATMYMY
ATNT1 (testmode)
ATWR
ATDN