Xbee Prop progaming, why only load some spin files

Anubispod

Hi , im back from my break with electronics , and now facing a new chalange with the xbee bootloader ,

I get all working , i load the spincode via normal USB to the board i have with the prop,
then start the tool to load the new firmware via xbee, that tool loads and says ok done.

But no new firmware is there.

Unless i pic a diffrent file like ping.spin from the lib, then he loads the file to the prop via xbee and also says loading to eeprom and all is good , except that the ping.spin does not is my file i want to upload, but mine does not work ????

I hope my wiered english is good enoughf to explain my problem

Best regards
O.Rennfort

StefanL38

Hi O.

please upload your code that we can analyse what the difference is

best regards
Stefan

Anubispod

Here is a zip file with the spin files.
I load the xbeetest via usb on the prop and it runs , so the xbee upload tool finds the prop and data in the loop of the xbee serial woks great.
So now i want to upload some new code like the xbeetest file just with some new text in it.
The xbeeloader starts transmitting and i see the nice animation of data going over , and then he say done. , but nothing has realy happend no new firmware in the epprom. mhhh
so next i try to load a diffrent file, like ping, RCtime there the xbeeloader starts with the nice anim , but also shows wrting to epprom in the staus, and then it worked , the softbootloader is overwritten on the prop epprom but , with junk in the moment .
it seems if the file is small it works but some must be off

Best regards
O.Rennfort

Mike Green

The Propeller loader is very timing sensitive. The actual time required for transmitting bits varies with the bit values and there's a timeout. The xBee packages up groups of bytes for transmission as a packet with error detection and correction and that introduces additional delays. As a result, the downloading process via xBee (or WiFi for that matter) can have a variety of delays that depend on the data sent, the length of the data, and the environment (noise) in which the transmission is done. Bigger programs and a noisier environment increase the likelihood that the download will fail.

There's a different download protocol used with the Propeller Backpack that's designed to be less timing sensitive. It requires the use of a 64K or larger EEPROM and the loader resides in the low end of the EEPROM and the low end of the 2nd 32K of the EEPROM. There's a modified Propeller downloading program for the PC that can handle this. Look at the Backpack documentation for details.

Anubispod

Thank you Mike, i know that the build in Bootloader is not working over xbee, due to timing.
But my thought was that the xbee bootloader just copys all the data first into ram and then overwrites after a checksum to epprom.

So just that i get that right , if i were to go to write my own bootloader, due to the fact that i need my xbees to run in API mode,

1.setting up Serial with xbee 57600k connection in API mode.
2.i send API packets with data to the prop i need to send 5 8bit values in each frame to the prop from what the first byte is to say just data or get ready for new firmware upload.
3. If firmware Upload then the next API frames will include the firmware byte by byte and stores that into Ram , and if at the end the checksum fits it just overwrites the epprom and reset.

So here timing would be not a matter, just that the checksum fits at the end ?????
Since i dont need timing to get the code to know that there will be new firmware, instead i write my byteflag in the API frame and then copy all epprom bytes over.
Xbee api frames have there own checksum system for each frame send so lets say there goes some wrong it will be resend bevore the next frames with new firmware parts go ourt..

I hope that makes sense what i wrote mow

Best regards
O.Rennfort

Mike Green

Yes, the built-in bootloader first downloads into RAM, verifies the download with a checksum, then, if instructed by the PC, copies the entire contents of RAM to the EEPROM (or its 1st 32K if bigger than 32K). You can write your own bootloader if you want. The problem is that your download program has to use part of the 32K for itself, unless it's written in assembly and fits entirely in one or more cogs' memory. That limits the size of the program you can download. Look at the Propeller Backpack downloader for a model (here - PC Loader and Firmware Source).