Yann, 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. Janos On Fri, Jul 27, 2012 at 8:54 AM, Yann Le Corre <[email protected]> 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 > ExtFlash.startRead(). > > I would be glad to submit/discuss my corrections with an official > maintainer of tinyOS/Deluge or anybody with needs them. > > Regards, > > Yann > > > > 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. >> >> Andris >> >> On Tue, Jul 10, 2012 at 4:54 PM, Yann Le Corre <[email protected]> wrote: >>> Hi, >>> >>> 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. >>> >>> Regards, >>> >>> Yann >>> >>> >>> >>> >>> On 07/10/2012 05:20 PM, Hamid Rafiei Karkvandi wrote: >>> >>> Hi, >>> >>> 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 ... >>> >>> >>> Regards, >>> >>> >>> Hamid Rafiei Karkvandi >>> >>> >>> >>> >>> >>> On Tue, Jul 10, 2012 at 7:40 AM, Yann Le Corre <[email protected]> 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@/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@/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 >>>> FLASH... >>>> >>>> >>>> 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 ? >>>> >>>> >>>> Thanks, >>>> >>>> Regards, >>>> >>>> yann >>>> >>>> -- >>>> Yann Le Corre >>>> Laboratory of Algorithmics, Cryptology and Security (LACS) >>>> FSTC/CSC >>>> >>>> UNIVERSITE DU LUXEMBOURG >>>> >>>> CAMPUS KIRCHBERG, E206 >>>> 6, rue Richard Coudenhove-Kalergi >>>> L-1359 Luxembourg >>>> T: +352 46 66 44 5795 >>>> [email protected] www.uni.lu www.uni.lu >>>> >>>> _______________________________________________ >>>> Tinyos-help mailing list >>>> [email protected] >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>> >>> >>> >>> -- >>> Yann Le Corre >>> Laboratory of Algorithmics, Cryptology and Security (LACS) >>> FSTC/CSC >>> >>> UNIVERSITE DU LUXEMBOURG >>> >>> CAMPUS KIRCHBERG, E206 >>> 6, rue Richard Coudenhove-Kalergi >>> L-1359 Luxembourg >>> T: +352 46 66 44 5795 >>> [email protected] www.uni.lu www.uni.lu >>> >>> >>> _______________________________________________ >>> Tinyos-help mailing list >>> [email protected] >>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
