Re: Deluge T2 and iris motes
Janos Sallai <sallai <at> isis.vanderbilt.edu>
2012-07-27 17:13:28 GMT
Thanks for reporting this issue. A quick recap, just for the record: a
recent change to chips/at45db/BlockStorageP.nc that allowed for
non-power-of-two page sizes broke deluge/tosboot on the iris and micaz
(probably other platforms, too), because deluge and tosboot were
expecting the page size to be 256.
For now, I reverted back to the old chips/at45db/BlockStorageP.nc,
which assumes that the page size is a power of 2. Deluge/tosboot needs
to be fixed post 2.1.2. I'm posting a google code issue, as well.
On Fri, Jul 27, 2012 at 8:54 AM, Yann Le Corre <yann.lecorre <at> uni.lu> wrote:
> Hi all,
> I think I have solved my issues with deluge T2 and iris motes with
> Ubuntu 11.04.
> I used the git repository (checked out on July 13th 2012) and all the
> latest versions of avr tools (locally recompiled with gcc4.6.1).
> I found 2 bugs in this version of the database/tools compiled for IRIS
> target. They are all related to the external flash (AT45DB) having pages
> of 264 bytes instead of 256 bytes:
> - the function StorageMap.getPhysicalAddress() in
> tos/lib/net/Deluge/BlockStorageManagerP.nc is obviously written for
> AT45DB with 256-bytes pages.
> - the function ExtFlash.startRead() in tos/lib/tosboot/at45db does not
> work for 264-bytes pages.
> I think the root of all evil lies in function multiplageContinue() in
> chips/at45db/BlockStorageP.nc. The version that is used in the Xubuntu
> vmware image (which does work), is written for 256-bytes pages while the
> version in the git repository is designed for 264-bytes pages.
> I guess we should either revert back to the old version of
> multiplageContinue(), or update StorageMap.getPhysicalAddress() and
> I would be glad to submit/discuss my corrections with an official
> maintainer of tinyOS/Deluge or anybody with needs them.
> On 07/10/2012 09:54 PM, András Bíró wrote:
>> Hi Guys,
>> It's seems there is a bunch of deluge related problem recently, and
>> altough I don't really know the source of your problems, Deluge T2
>> certainly works. I didn't use it on memsic motes for quite a long
>> time (although I could test it on irises if you wish), but I've ported
>> it to the motes our company manufactures, and recently I programmed
>> about 150 motes with it (all of them in the same room).
>> By the way, I'm using Arch linux, and the newest python2 package on it
>> for tinyos python scripts, I never had any problem with the tos-deluge
>> - mote connection.
>> Debugging a deluge related problem is really painful, since it's quite
>> complex protocol, handling awful lot of data.
>> Some issues I had problems with:
>> -TOSH_DATA_LENGTH _must_ be the same on all motes. If the receiver's
>> TOSH_DATA_LENGTH is bigger than the sender's, the receiver fills the
>> remaining data with garbage, and that will cause crc error in the
>> bootloader. That means it will restart with the old image, redownload
>> the new, reboots, detects the crc error and so on.
>> -Deluge doesn't like if there's serious communication in the area. It
>> really slows down the downloading of the image (from two minutes to
>> fifteen-thirty), and worst of all, it also causes image crc errors
>> (not sure why, but at first we could only reprogram about 50 of the
>> 150 motes. Fortunately, we could disable almost all communication on
>> the motes).
>> -Image 0 is the golden image (1; 2 and 3 are general purpose images),
>> but it's not well designed. You have to inject the golden image
>> yourself, but at some point deluge will stop you to use it as the
>> other images, and I think that point is the dissemination. Therefor,
>> you have to inject it with serial on all motes (but I'm not sure, I
>> didn't really cared this issue)
>> -You also have to be extramly unfortunate, if you encounter a mote
>> automaticly programs itself with golden image. Tosboot only incrases
>> the gesture counter (which counts to 3, and when reaches 3, tosboot
>> will program the golden image) if ther was some problem during copying
>> a page from the external flash to the internal, but I never had such
>> problem. It does not protect your mote from redownloading a crc error
>> image again and again, which happens quite often however.
>> On Tue, Jul 10, 2012 at 4:54 PM, Yann Le Corre <yann.lecorre <at> uni.lu> wrote:
>>> It looks similar to what I have here.
>>> I (almost) gave up and I tried the xubuntu VMWare from tinyOS wiki.
>>> Everything seems to be working fine now. I can disseminate and execute.
>>> It seems that Deluge T2 has issues with ubuntu 11.10 and 12.04 LS. I would
>>> be glad to help to solve them if anybody could give me some clues.
>>> On 07/10/2012 05:20 PM, Hamid Rafiei Karkvandi wrote:
>>> I have been having no success in using Deluge T2 with IRIS and MIB520. First
>>> I failed even to install Deluge correctly on Cygwin so I migrated to Ubuntu
>>> 12.04 LS and I installed the recent updated version of Tinyos. Deluge T2
>>> runs on the mote, I inject the image and I read the flash successfully and
>>> even mine doesn't give the error you mentioned (is it base station or not
>>> ... ) but still after dissemination I can see other motes start to get the
>>> image and write it down on their flash (the green LED blinks fast) but after
>>> all no one reboots and execute the new image ... I kinda gave up on it, but
>>> if anyone has a similar experience and knows how to solve these issues with
>>> IRIS and Deluge T2, I appreciate ...
>>> Hamid Rafiei Karkvandi
>>> On Tue, Jul 10, 2012 at 7:40 AM, Yann Le Corre <yann.lecorre <at> uni.lu> wrote:
>>>> Hi All,
>>>> I try to get Deluge T2 working on my Iris motes but with no success so
>>>> far. Starting with only one mote connected to the PC with a mib520, I
>>>> tried the following steps:
>>>> 1. compile and install apps/test/deluge/Basestation
>>>> 2. tos-deluge serial <at> /dev/ttyUSB1:57600 -p 0 ==> I can read the flash
>>>> content, everything seems OK
>>>> 3. compile and install apps/test/deluge/Blink ==> led0 is blinking
>>>> 4. tos-deluge serial <at> /dev/ttyUSB1:57600 -p 0 ==> "ERROR: Timeout. Is the
>>>> node a Deluge T2 base station?"
>>>> My PC is running Ubuntu 11.10 with avr-gcc 4.63, avr binutils 2.22,
>>>> nescc 1.3.3 and tinyOS tree from CVS. CFLAGS always contains
>>>> -DDELUGE_BASE_STATION or -DDELUGE_LIGHT_BASE_STATION.
>>>> After a lot of trials and errors, it appears that I can make
>>>> deluge/Blink answer to the "tos-deluge -p" if I change the
>>>> -DIDENT_APPNAME flag. Actually, what seems to matter is the length of
>>>> the application name. For example -DIDENT_APPNAME=\"BlinkAppC\" will not
>>>> work while -DIDENT_APPNAME=\"BlinkAppC______\" does work.
>>>> I know it sounds weird. It makes me think about alignment issues in the
>>>> Then, I tried to run the demo further. I checked that I can run the
>>>> blink and reverse-blink demos and that I can ping them with "tos-deluge
>>>> -p". Injecting an application with "tos-deluge -i" seems to be working.
>>>> But the mote never reboots and executes the injected application (i.e.,
>>>> the "burn" script does not work).
>>>> Is Deluge T2 supposed to be working on iris motes ? Does somebody
>>>> already bumped into similar issues ?
>>>> Yann Le Corre
>>>> Laboratory of Algorithmics, Cryptology and Security (LACS)
>>>> UNIVERSITE DU LUXEMBOURG
>>>> CAMPUS KIRCHBERG, E206
>>>> 6, rue Richard Coudenhove-Kalergi
>>>> L-1359 Luxembourg
>>>> T: +352 46 66 44 5795
>>>> yann.lecorre <at> uni.lu www.uni.lu www.uni.lu
>>>> Tinyos-help mailing list
>>>> Tinyos-help <at> millennium.berkeley.edu
>>> Yann Le Corre
>>> Laboratory of Algorithmics, Cryptology and Security (LACS)
>>> UNIVERSITE DU LUXEMBOURG
>>> CAMPUS KIRCHBERG, E206
>>> 6, rue Richard Coudenhove-Kalergi
>>> L-1359 Luxembourg
>>> T: +352 46 66 44 5795
>>> yann.lecorre <at> uni.lu www.uni.lu www.uni.lu
>>> Tinyos-help mailing list
>>> Tinyos-help <at> millennium.berkeley.edu
> Tinyos-help mailing list
> Tinyos-help <at> millennium.berkeley.edu