I tried the new tool uploaded by Felix for OTA programming from Windows.
I was running the tool on a Windows 7 box and it continually crashed after the first packet. I attached a screen shot showing the screen and as much of the error message as I could show.
I have another report of this, I will look into it asap. Thanks for the screenshot.
Quote from: Felix on January 04, 2016, 08:07:08 AM
I have another report of this, I will look into it asap. Thanks for the screenshot.
My h/w partner is also having the same trouble but he's using Windows 10.
If you need any other troubleshooting info let me know.
I think it's because CheckForSerialHex() is called with DEBUG=true in the programmer. I just set this to FALSE in the programmer sketch (https://github.com/LowPowerLab/RFM69/blob/master/Examples/WirelessProgramming_gateway/WirelessProgramming_gateway.ino).
The difference with no DEBUG is this:
(http://i.imgur.com/uv3ZqK8.png)
I added some more error checking, can you please try the latest exe and report if this still happens?
Just downloaded latest copy.
Now all I get is "No response from Moteino programmer, is it connected to COM7?" It is.
Or, "[Timeout receiving FLASH image from SERIAL, aborting...FLASH IMG TRANSMISSION FAIL]
---------------------------------------
My bad.....didn't notice the change in the debug flag in CheckForSerialHex(). I made that change and it worked OK.
Thanks Felix...
I too was having the same problem running the app on a Windows 10 machine.
Works perfectly now!!!
Great, I would still hope these work with DEBUG mode enabled (true as last parameter to CheckForSerialHex() in the programmer sketch (https://github.com/LowPowerLab/RFM69/blob/master/Examples/WirelessProgramming_gateway/WirelessProgramming_gateway.ino)).
I cannot really reproduce any further issue though. If I have some time I will look more, but in the meantime if someone is having a problem please post more details and I can dig into it.
I downloaded today's .exe and used the WirelessProgramming_gateway with CheckForSerialHEX debug set to "true". I got :
FAIL: No response from Moteino programmer, is it connected to COM14?
I clicked the start button a few times, (without touching any hardware!) and eventually got a
Moteino: [FLX?OK]
HANDSHAKE OK!
followed by a successful upload.
I repeated with CheckForSerialHEX debug set to "false" but could only get
FAIL: No response from Moteino programmer, is it connected to COM14?
Log dump attached.
I’m running Windows XP and .NET version 4.0 .
Any ideas?
---------------------
Jan7 Update: RE CheckForSerialHEX debug set to "false" but could only get
FAIL: No response from Moteino programmer, is it connected to COM14?: Well it seems this was due to a self-inflicted stupid mistake. In my enthusiasm to download the latest version of WirelessProgramming_gateway (i.e. CheckForSerialHEX debug set to "false") , I neglected to assign correct Node ID and Encryption Key values. This would no doubt explain the non-response from the Moteino programmer! After correcting this, all seems to work now ......
Hi,
there is another bug:
When I try to use the application when the COM Port is already open by another process, the app will Crash. (When pressing start)
A Error Message would be great...
Thanks guys, I will look more into these issues and follow up.
Thanks for the patience.
For now please use it with DEBUG=false.
The latest change (https://github.com/LowPowerLab/WirelessProgramming/commit/a0b63f4f35ced243c65ef330d756a7d8ed396165) to the exe should take care of the busy port exception.
Felix,
Not to sound ungrateful, but in your next release could you add an "About" menu option or button showing the current version?
The "Version" field displays "1.0.0.0" when you view the "Properties" via the OS.
How about in the title bar?
See the latest exe for that.
Quote from: Felix on January 08, 2016, 01:30:53 PM
How about in the title bar?
See the latest exe for that.
That will do nicely, thanks.
I ran v1.3 today, and it seems to work well. As a test sketch, I sent the node the sketch that it already has. Using the example sketches for the WirelessProgramming_gateway and the WirelessProgramming_node, that took 30 seconds at the "slow" rate, and 20 seconds at the "faster" rate (i.e. at 3 HEX lines per RF packet). So, the "faster" rate is a worthwhile improvement. As a cross-check, 30 seconds is also roughly how long msjfb's upload application takes for the same file.
Since the WirelessProgramming_node hex file is 38KB in size, that effectively corresponds to an upload speed of about 1,267bps and 1,900bps respectively. That's quite a reduction from the OTA bitrate of about 55Kbps that the sketches are using, and so I'm guessing the OTA bitrate is not the primary bottleneck. Nonetheless, has anyone tried it yet with the radios configured to use a higher OTA bitrate, and, if so, how big a difference did that make?
Any thoughts on where the bottleneck might be? Is it the write-time to the flash memory? If so, then would recycling the same idea and batching up received HEX strings and then writing longer HEX strings to flash memory (perhaps a page at a time?) speed things up considerably?
Quote from: WhiteHare on March 30, 2016, 07:24:54 PM
Any thoughts on where the bottleneck might be? Is it the write-time to the flash memory?
I expect it's the 'wordy' protocol used in the Wireless Hex transfer. Lots of exchanges of ASCII data...
I use my own binary transfer method (HEX file converted at the source) so packets are stored directly into flash (although in a secondary region - so that I can totally lose random packets and these will get re-requested in time). This method is not to shorten the update time, in fact, my method takes much much longer, but is used to shorten the RX/Mote awake time to save battery life. Re my comment about taking longer, I only accept blocks for a short period of time and then will sleep for the normal sampling period. Next time around I'll grab some more blocks. Definitely a 'pull' technology. Eventually the whole image is gathered and only then, transfered to low flash in a way compatible with the Dual Optibootloader. Definitely NOT a fast update method, but definitely a battery efficient one.
However, once Sammy Sentient gets his wireless bootloader available to us this will all be replaced. ;)
Tom
I just ran a quick and dirty test by raising the OTA bitrate to 200,000 on both the gateway and the node. Actually, at that bitrate the gateway's serial connection of 115,200 baud is a bottleneck relative to the 200,000 OTA bitrate, but whatever, because the serial baud is a fixed given by the v1.3 program. Anyhow, total time was only slightly reduced to 19.63 seconds, which by itself is not a meaningful improvement.
Do you believe the replacement you're referring to is likely to be available sometime in 2016?
I don't know the protocol Felix uses but I suspect that the speed issues are caused by frequent acknowledge packets from the client. That really slows things down in particular when using a usb/serial bridge (see http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf for causes and fixes).
My boot loader is making good progress. Get this: I now have an app that replaces dualoptiboot with my boot loader without the need for an ISP. Just upload the sketch to your Moteino and you're set for wireless installs without external flash.
In terms of speed an upload of a 28k sketch in under 3s is definitely doable.
QuoteDo you believe the replacement you're referring to is likely to be available sometime in 2016?
Yes.
Quote from: joelucid on March 31, 2016, 02:13:36 AM
My boot loader is making good progress. Get this: I now have an app that replaces dualoptiboot with my boot loader without the need for an ISP. Just upload the sketch to your Moteino and you're set for wireless installs without external flash.
In terms of speed an upload of a 28k sketch in under 3s is definitely doable.
That would certainly make for easy installation. Sounds fabulous!
QuoteThat would certainly make for easy installation. Sounds fabulous!
Yeah - the consequence being though that it really needs to be absolutely rock solid. If the bootloader fails people without ISP programmer it's pretty bad. But I thought it was pretty cool that there was enough flexibility in the DualOptiboot to make installing without ISP possible.
Quote from: Westy87 on January 06, 2016, 11:41:50 PM
I got :
FAIL: No response from Moteino programmer, is it connected to COM14?
I clicked the start button a few times, (without touching any hardware!) and eventually got a
Moteino: [FLX?OK]
HANDSHAKE OK!
followed by a successful upload.
Same issue here, managed to send a sketch twice with a few failures in between with the above error, but now I can't seem to get a response from the Moteino programmer at all.
No settings were changed, and it appears random.
Debug was set to false on both programmer and receiving end, using V1.3 OTA on Windows 7.
Has anyone had a similar experience and fixed it to run reliably?
The node I'm testing on will be in a remote place, so I'd like to make sure I can program it without having to get the ladder out every time ;).
EDIT:
-----------
Programming from Moteino R4 to Moteino R4, using Felix's FTDI programmer, updated to the latest RFM69HW & Wirelesshex libraries & OTA binary. Fiddled with WirelessProgramming_Gateway sketch timeouts as last resort. Can't seem to figure out why the programmer does not respond to 'FLX?'.
I haven't tried the command line method yet; if that's more reliable I might give that a go next.
I have run into this before as well. I figured out it is because I'm using ATC. If I move the wireless programming node closer to the node I want to program it works just fine. If you are too far away the programming node probably does not receive the acks.
I've just added a change to the ATC lib (https://github.com/LowPowerLab/RFM69/commit/191daf4f3efb27ba476b668bd46f5e6e6729da9b) to allow the mote dialing power up when it can't get the ACK through. Without this change, a lower threshold would effectively lockup the end mote. You may want to try this or increase your ATC threshold.
See this comment (https://lowpowerlab.com/forum/index.php/topic,1701.msg12249.html#msg12249) and Tom's response for more details.