RS Media fault help please :)

55 posts / 0 new
Last post
Urgentemente
Urgentemente's picture
RS Media fault help please :)

Hi ,
I recently got hold of an RS MEdia from ebay, that was listed as "makes a clicking noise, possible OS wiped".

Sure enough, on poweron, the eyes go solid red, the LCD is plain white, and for a few seconds there is a 'p p p p p p" sound from the speaker, then it appears to power down, then about 5 seconds later there's a short burst of 'speech' (sounds more like a burp/gulp LOL !)

I tried the couple of scripts I found on here from nocturnal on an SD card but no joy (I suspect it's not booting far enough to be running them).

Anyone got any ideas? I'm thinking I'll need to figure out how to make and fit the serial hack to have any chance of resurrecting it, any suggestions much appreciated. (I've got a RSV2 currently in bits for the last 6 months as I've mixed the screws up , oooops!)

Here's a short video if it being switched on..

http://www.youtube.com/watch?v=a48jiSjP75s

Jamie
Jamie's picture

Hello,

This looks to be a big problem. It isn't caused by no software. You have most likely a blown component on the robot board or the media board. Take the bot apart and take some pictures of the boards on both sides so we can see the problem.

Cheers,

Jamie Kugelmann

Urgentemente
Urgentemente's picture

Wow, thanks for the quick response Jamie,
I was planning to take it apart soon anyway, just for curiosity and to see if there was anything obviously blown (or obvious to my amateur eyes that is..).

I'll probably get it apart between now and the weekend, will take plenty of pics and post once I've done.

I was quite happy when I managed to get my RSV2 mostly working again as it had a lot of the crumbling insulation on the wiring,so fingers crossed that this RS Media is rescuable :)

FreddyA
FreddyA's picture

Hi Urgentemente, like jamie said, it could be a blown component but I will probably guess it is on the motor board. I can see in the video that your rsm doesnt move its head left and right which it does normally before booting. You will need to manually position the head to the right by gently sliding the motor out of the gearbox a bit enough to allow freely to move the neck left and right slider contact to the right position. Then try again to power the robot and if the media board is good it will show wowwee and continue booting. Watch out! the robot will move around and so be careful with the lcd ribbon while testing. if it does the same, try powering up again but this time, move the slider far to the right and back and forth to the left simulating the head turning to the sideds by the motor.

If that works and it boots up then the problem is a blown part in the motorboard neck motor components. there are parts available for that.

Good luck let us know.

Freddy

Urgentemente
Urgentemente's picture

Thanks Jamie,
I did gently (were talking very light finger pressure as I didn't want to strain/break anything) turn the head, but it doesn't feel as if there's any tension, in fact it seems quite loose left/right and forward/back, but to be honest I'd need to compare it to my RSV2 , as I haven't been near that either for a while, and it's not dismantled yet.

I'd read another thread elsewhere on here I think, about the ribbon connector to the head, so I was originally planning to open him up and remove that connector, but your suggestion sounds better to start with

I'll probably wait till later this week, or the weekend before stripping it down, I've learnt the hard way not to do things in a rush !

thanks again both of you for the quick replies,

Helibot
Helibot's picture

Hi Urgentemente,
I have had a similar issue on my RSMedia. I agree with Freddy , it may well be related to Neck and head movement. You may be able to confirm this without taking him apart.
Try this :-
- Lie him on his back (it will stop him moving the limbs if you get further into the boot).
- Adjust the position of the head all the way to one side or the other (which ever is easier to turn it to)
- try booting up. You may find he gets further through the boot.
- If it doesn't work then turn the head to about 45 degrees to one side. And try booting up again. This worked for me!!
(The reason is that RSMedia will always move his head a bit when he first boots up, if the motor drivers are damaged then it causes over current, which causes the voltage to drop and he powers down. But if the head is at about 45 it seems the head is not moved during bootup, so overvoltage/current is not caused and he will continue to boot.)

If you get him to boot all the way then press C and X on the remote (to turn ears nad eyes off) then stand him up. Now you can use the remote to move the various arms/limbs and see what works. Note down any limb or movement that doesnt work or causes shutdown....these will be where you need to look closer!

Cheers
Helibot

Jamie
Jamie's picture

Hi all,

Helibot is specialized in the way of robotics. He has fixed his robot from even worse problems! He has given great advice, and I agree with him. Hope you get it working

Cheers,

Jamie Kugelmann

Urgentemente
Urgentemente's picture

Once again, thanks for the quick and detailed replies :)

Helibot, I'll go through your list of checks as soon as I get 20 mins spare, hopefully tonight
I did try lying him on his back to see if it booted any further (I've read quite a few threads on here and probably read many of yours!), but haven't tried moving his head with any 'effort' yet whilst he's laying down, I'll try that tonight hopefully.

Great to see there's still a thriving community, can't wait to try some of the other stuff available, assuming I get him resurrected..

Urgentemente
Urgentemente's picture

It's alive...ALIVE.!!

Thanks Helibot, we have the first glimmers of hope :)
Laid him on his back, felt the head, it was VERY stiff to try and turn right (when looking from the back of the robot for a reference frame), so I turned it left, powered on...a few seconds and then "Woweee.." and blinking eyes.
Silly me had left the SD card in with the rsupdate script I'd tried at the weekend , so it booted to the SD card and tried updating, tho it said there was a checksum error on one of them, and failed nand flash, then it went to "updating person" (personas I guess...), left it for a couple of mins,no change, so powered off, removed SD card and rebooted.
GOt to the "Loading..." with full progress bar but no further, but at this point I could move the head with the remote(easily to turn left, barely moves to turn right..), and also make it lean forward and back, tho in that movement, it sounds like the motor/cog spins quite a bit with no movement, then if I repeatedly tap it, it will lean forward or back.

I'm going to check what's on the SD card now, probably format it and recopy the update fies.

I just rebooted it again, stood upright, after about 1 min or so of "loading", it went to tilt backwards...and rebooted.

Urgentemente
Urgentemente's picture

OK,formatted SD card, recopied the rsupdate folder ,left it longer and it finished the "Updating persona", but still fails the applications update with this displayed:
UPDATING
APPLICATIONS
CHECKING
CHECKSUM ERROR
NAND WRITE ERROR

(no error about kernel size, so I guess this is a RSMV2? was going to check when it's apart anyway..)

Helibot, Does that point to a faulty NAND memory chip/partition, or a corrupted application file failing the checksum? I'll try and find another SD card to test with, and re-extract the files etc. Is there any way I can the files aside from on the bot, ? md5sum on my linux box? (I didn't notice the script suite was yours when I posted earlier, just spotted your name at the bottom of the readme..)

Movement wise, it's not looking great:
i) Head turn and body turn to the left seem to be fine,smooth and strong motion
ii) Leaning forward/back to an extent are OK, aside from it sounding like the motor is spinning for a while before there is any movement.

but pretty much anything else at the moment results in shutdown. Trying to turn the head right as earlier, the head *barely* moves and sounds likes it's struggling.

I think it's time for him to meet the screwdrivers and take his covers off, see what's going on inside when various actions are requested.

Vader
Vader's picture

GOt to the "Loading..." with full progress bar but no further

You'll most likely still have a usable OS at this point, which you can use to dump the boot log (dmesg) and reflash the NAND if you need to.

I just rebooted it again, stood upright, after about 1 min or so of "loading", it went to tilt backwards...

This is because the startup dance is started by a timer on robot board, so it'll run even if you have a full media board brick.

Does that point to a faulty NAND memory chip/partition, or a corrupted application file failing the checksum?

It means that the MD5 of the system image doesn't match the one in the corresponding .md5 file.

Is there any way I can the files aside from on the bot

You can just mount them as a cramfs partition on a linux box. Something like mount -o loop -t cramfs [IMAGE NAME] [MOUNT POINT]

Urgentemente
Urgentemente's picture

Thanks Vader,
I just re-read my post, I meant to say "is there any way I can check the files",.. somehow missed "check" . d'oh

So the checksum failure for the application is checking what's been written to /dev/nand1 against the md5 sum in rfs_system_v2.md5 , from the line:

"Checking..."
/mnt/sd/rsupdate/md5-arm /mnt/sd/rsupdate/rfs_system_V2.md5 /dev/nand1

I just copied the zip file to my linux box and did a md5sum on rfs_system_V2.cramfs, and it matches the checksum in rfs_system_V2.md5 (5e0120294c44f055094e10e960ed5407) :(
so it sounds like it's not writing to /dev/nand1 correctly ..

I'll leave it for tonight, and tommorow I'll make a smaller rsupdateapp script with just the app flash part it, saves waiting for the other 2 parts each time, that should be safe shouldn't it?
Is there anyway to test /dev/nand1? does the OS on the bot have fsck ?

Jamie
Jamie's picture

I wouldn't make a smaller script, it isn't safe. Why are you trying to update it? You don't need to do that, you have the risk of bricking the bot. /dev/nand1 is the first partition of the NAND chip on the media board.

Vader
Vader's picture

Actually /dev/nand0 is the first partiton, which contains the kernel.

I just copied the zip file to my linux box and did a md5sum on rfs_system_V2.cramfs, and it matches the checksum in rfs_system_V2.md5 (5e0120294c44f055094e10e960ed5407) :(
so it sounds like it's not writing to /dev/nand1 correctly ..

Forgot to mention that is also checks the size of the image against the size in the md5 file. That may be what's causing the error.

Just in case you were wondering, the NAND write error means that the md5 and size of /dev/nand1 does not match the hash in rfs_system_V2.md5.

I'll leave it for tonight, and tommorow I'll make a smaller rsupdateapp script with just the app flash part it, saves waiting for the other 2 parts each time, that should be safe shouldn't it?

That shouldn't be a problem. I've done it quite a few times while flashing my custom firmware.

Is there anyway to test /dev/nand1? does the OS on the bot have fsck ?

Not sure, but if it doesn't I guess you could do a dump of nand1 and check it with cramfsck on your linux box. If you have a Linux distro which uses APT you can install it by using this command: sudo apt-get install cramfstools

Urgentemente
Urgentemente's picture

 

Vader said: Forgot to mention that is also checks the size of the image against the size in the md5 file. That may be what's causing the error. Just in case you were wondering, the NAND write error means that the md5 and size of /dev/nand1 does not match the hash in rfs_system_V2.md5.

Is there anyway to test /dev/nand1? does the OS on the bot have fsck ?

Not sure, but if it doesn't I guess you could do a dump of nand1 and check it with cramfsck on your linux box. If you have a Linux distro which uses APT you can install it by using this command: sudo apt-get install cramfstools

 

Ah, yes, I see the 786430 on the end of the md5-arm command, just checked the size of the file itself on my box and it matches too, I could see from the script that it was comparing the nand1 size,not the file itself, but at least I know the file is the right size and matches the md5 sum prior to writing (or appears to be..)

so I'll need to get a dump of /dev/nand1 off the bot to compare.

I guess a small rsupdateapp script with:

mount /dev/mmc /mnt/sd -o rw,remount

chmod 755 /mnt/sd/rsupdate/*

cat /dev/nand1 > /mnt/sd/nand1dump

or similar should do the trick,cribbing from the existing rsupdateapp just a bit :) (I know the linux commands,been using it for years (I think redhat 5 was my first ever,mid 90's..) , just getting used to how the bot executes the 'special' case of rsupdate folder/rsupdateapp script .

I do like the logic of how the script works out wether it's a NAND write error, or the file itself, didn't spot that last night (otherwise I wouldn't have needed to manually md5sum the file myself), tho obviously I would prefer it to be a SD read error instead!!!

 

Jamie, I'm trying to update it as it's not loading completely, stops with a full progress bar but never completes, possibly it was already that way (the SD card that was in the bot had evidence of someone already looking at these scripts).

 

Urgentemente
Urgentemente's picture

Forgot to add earlier, I'm running Fedora 14, and fsck has the cramfs part already installed, so I just used "fsck -V -t cramfs rfs_system_V2.cramfs" , no errors listed.

I also mounted the rfs_system_V2 image with no problems,
quite interesting having a browse through the files, I can see me losing a few hours reading through the various scripts and figuring out when/why they are run, what they perform etc :)

Vader
Vader's picture

By the way, is your RS Media one of the newer revisions that include the USBNET feature?

Urgentemente
Urgentemente's picture

Vader said: By the way, is your RS Media one of the newer revisions that include the USBNET feature?

Err, I don't know  :)

I haven't had the covers off yet to see what version board(s) it has, just assumed it's a RSMV2 as the update script didn't complain about a lack of space for the images.

 

Given that it's not fully operational at the moment, is there an easy way to check, or do I need to wait until the covers are off and/or I've got it's application partition sorted out (hopefully..)

I did connect the USB between the bot and the PC now that it's at least partially alive, and an empty USB drive appeared in Explorer, but clicking it just asked for "insert a disk into drive".

Fired up RSMEdia suite and it doesn't seem to see the bot, tho I pretty much expected that if the application suite isn't working on the bot yet.

 

I haven't had a chance to grab and play with the various USB/TCP tools from here yet.

Vader
Vader's picture

Just noticed you had a progress bar on startup, which the older versions don't have. So it must be one of the newer ones :).

Urgentemente
Urgentemente's picture

Ah, cool :)
Much better to have a non-working newer version, wouldn't want a non-working older version :) LOL

Handy tip to know actually, this is the first RSMedia I've seen so didn't know the startup looked different between versions.

Helibot
Helibot's picture

HI Urgentemente,
Sounds like you are progressing well and have good linux knowledge - that will help you through getting the software going again!! (Through i guess you have some HW issues to address as well.)
Here are some suggestions for you:-
1) check that you have some personality files installed in the robot or the SDCard. If there are no personality files the robot can appear to lock up (ie get stuck at the loading screen).
There are TWO places that personality files can be loaded -
A) Internal flash partition /dev/nand3. This is mapped to /mnt/sd if NO sdcard is installed.
B) On the SDCard. (Which is mapped to /mnt/sd if the SD card IS installed.)
So you can try booting your robot with and without the SDCard installed (without an rsupdateapp script installed) and see if the behaviour is any different. Let me know if the behaviour is different for either - If it is I will tell you more about how to fix personalities.

2) As Vader said "You'll most likely still have a usable OS at this point, which you can use to dump the boot log (dmesg) and reflash the NAND if you need to."
I suggest that you run the RSMdump script , it will collect the dmesg log and make a backup of all nand partitions to the SDCard. Get the script from here
https://sourceforge.net/projects/rsmediadevkit/files/RSMFirmwareDump/RS%...
(There is a lot of RSMedia info and programs in the RSMediadevkit on sourceforge, so you may like to have a poke around if you havent found it already. Tika C and I are mostly maintaining/adding to it)
See the README.HTML for detailed instructions on how to run it.
Hopefully it will run to completion and give you a full backup. At least it should create the rsmdump/dmesg.txt file on the SDCard. Then I suggest you upload the results to this thread and we can see if there are any errors occuring during the bootup sequence.

3) Actually you could also try putting a formatted (and empty) SDCard into the robot and booting it. If all is running correctly the robot should create directory and files on the card and may allow it to boot further. If you try this let me know if the files/directories were created.

Other commenst for you:-
> mount /dev/mmc /mnt/sd -o rw,remount
> chmod 755 /mnt/sd/rsupdate/*
> cat /dev/nand1 > /mnt/sd/nand1dump
This should work OK. but you should add another line with this:-
sync
It forces the kernel to write all pending/cached data to the SDcard (so if you pull the card out or powerdown the robot then all data will have been flushed to the SDCard. (As a general rule always use sync after writing to the SDCard.)

>I did connect the USB between the bot and the PC now that it's at least
>partially alive, and an empty USB drive appeared in Explorer, but clicking it
>just asked for "insert a disk into drive".
Yes thats normal. When you have a fully working bot you can goto Media mode and select USB Mode, and the SCDard (if inserted) will be mapped to the drive. (or the internal memory if the SDCard is not mapped)

>Handy tip to know actually, this is the first RSMedia I've seen
>so didn't know the startup looked different between versions.
Yep, the startup bar is different and kernel ramsize is bigger for V2. (V2 includes TCP/IP networking in the kernel and some extra files in the filesystem to allow more networking.)

>Fired up RSMEdia suite and it doesn't seem to see the bot,
>tho I pretty much expected that if the application suite
>isn't working on the bot yet.
Yes I think that is correct.

>I haven't had a chance to grab and play with the various
>USB/TCP tools from here yet.
You could try the 'USBConsole' tool - it gives you access to a linux prompt over the USB cable. But its a bit tricky to setup....I think you should try the other suggestions first...but you can get USBConsole from the Robocommunity download area or sourceforge site if you are keen ;-)

Another handy tip- You can prevent the startup dance from moving any motors (and triggering a reset) by pressing the stop key on the remote. As the progress bar gets near the end start pressing stop once a second. After he say "stopped" or other response you can stop....not sure if you will get this far yet though!!

Another handy tip- If you get to pulling him apart a good thing todo is to uncouple the motors of any suspect joint, this way the motor can run , but arent driving any gears so so they dont cause over current and reset. You can 'uncouple' most motors by pulling off the plastic straps (u may need pliers) that hold the motors in then slide them out a bit.

Thats all I can think of now....good luck!!
Cheers
Helibot

Urgentemente
Urgentemente's picture

Wow, mammoth post Helibot :)
I'd already found the devkit site on sourceforge thanks, one of the first places I started with , like you say, plenty of things to play with in there, you're doing a good job with it.

Nice point about the possible missing personalities, I know the SD card doesn't have any on there anymore,as I wiped it clean before recopying that update/reload script, so I'll put one back on it, as I don't know yet if there are any definately stored on the bot's internal memory, tho the reload script did say it had completed updateing persona , so there should be... (only the applications section failed)

I should get time tonight to run the RSDump script and then we can see what's lurking in the bot's NAND at the moment.

I can't believe I forgot 'sync', d'oh. I do that as a matter of habit formed many years ago when first using USB sticks on linux, even tho these days the shiny icon does it, I still tend to fire off a sync from the shell before removing, just to be sure.

So far to stop him doing the startup dance, I've left him on his back, and have been pressing Stop numerous times, after which I can stand him up, haven't heard *ANY* speech out of him yet (aside from the weird guttural noise it makes when it powers off due to the current movement problems) - I just assumed this was due to the possible software issues. When it's switched on and stationary, there is still the constant " p p p p p" noise from the sub, and a slight high pitched noise (like electrical motor/interfence noise you'd pick up on a speaker).

I'm beginning to suspect it's either already been dismantled, or has suffered perhaps some rough limb movement by hand, what with the stiff head turning right problem, and when I tried to move the arms, I can hear the motors whirring, but nothing moves. Moving the arm that's linked to the head-turn-right also causes the powerdown, as I'd expect.
Hopefully from the hardware side of things I can dismantle and free up the gears etc (I found another post on here that had some pics of the gearbox etc)

Definately will try the USBConsole also, yes, I'm keen :)
Only thing I lack is time, and a decent work area to leave it all in various stages of dismantling...

Urgentemente
Urgentemente's picture

Urrg,
it's getting worse..
for some reason it's now not booting from the SD card.
I removed the previous files, unpacked the RSMDump contents to the root of the SDcard using a card reader, put it in the bot..and... it still just boots (or tries to ) with the same "WowWee Loading.." and the progress bar... !

Is there any particular format of filesystem that the SD card has to be in? I think this one is now FAT32 from when I reformatted it after the "NAND write error" , on the chance that it had bad format (checkdisk afterwards said it was fine)

EDIT:
Odd..
I've just removed the SDcard from the bot, put it back in the reader, and the bot HAS been reading it, it's created the default directories (Application, Java etc etc),
and the rsmdump dir now has the nand0 1 , 2 dumps in it), but there wasn't anything on the LCD.
I'll put it back in and leave it for 15-20 mins while I get some food etc.

gerber
gerber's picture

Hi Urgentemente

The SD card I use on my RS media is formatted to just Fat

Hope you get your bot going.

Cheers
Gerber

Urgentemente
Urgentemente's picture

gerber said: Hi Urgentemente The SD card I use on my RS media is formatted to just Fat not Fat32. Hope you get your bot going. Cheers Gerber

Ah,bad timing, you must have been replying as I was editing my post..!

It has read the card, just nothing displayed on the LCD

Urgentemente
Urgentemente's picture

OK, it shut off(sounded like the over current reset again), but there are files written to the rsdump directory, I just don't know if it had finished or not (had been running for about 5-10 mins when I heard it shutdown).
This SD card seems particularly slow when writing on the PC at least, at the moment I'm copying a personality to the card and it's only doing 22K/sec !

First off, dmesg, I can see mention of a bad block detected, then right at the end, a failure to decompress something,mentioned just after the audio driver is initialised..

Here's the full dmesg file:

Linux version 2.4.18-rmk5-mx1ads-p3 (root@michael) (gcc version 2.95.3 20010315 (release)) #507 Fri Aug 25 20:10:50 HKT 2006
Processor: ARM/CIRRUS Arm920Tsid(wb) revision 0
Architecture: Motorola MX1ADS
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=fe01 ro mem=16M
Relocating machine vectors to 0xffff0000
Console: colour dummy device 80x30
Calibrating delay loop... 98.50 BogoMIPS
Memory: 16MB = 16MB total
Memory: 15000KB available (741K code, 297K data, 48K init)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
ttySA0 at I/O 0x206000 (irq = 29) is a MX1ADS
ttySA1 at I/O 0x207000 (irq = 23) is a MX1ADS
pty: 256 Unix98 ptys configured
DMA Initializing
block: 64 slots per queue, batch=16
SSFDC core support installed
MX1ADS nand I/O driver installed
SSFDC Partitions
nand0 : block 0x0000-0x003e : "Kernel" 1008 KB direct map
nand1 : block 0x003f-0x01fe : "RootDisk" 7168 KB random map
nand2 : block 0x01ff-0x047e : "DefaultDisk" 10240 KB random map
nand3 : block 0x047f-0x0f5a : "UserDisk" 44480 KB random map
nand4 : block 0x0f5b-0x0f7a : "WritableDisk" 512 KB random map
nand5 : block 0x0f7b-0x0f9a : "PassDisk" 512 KB random map
MX1ADS nand flash partition definitions installed
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com
found bad block 0x121 -> 0x121, block status 0x0, data status 0xff
[ ff ff ff ff ff 00 12 42 03 cf ff 12 42 6a 69 97 ]
reserved: 0xffffffff
data status: 0xff, block status: 0x00
addr1: 0x4212, addr2: 0x4212
ecc1: 0x6a 0x69 0x97, ecc2: 0x03 0xcf 0xff
VFS: Mounted root (cramfs filesystem) readonly.
Freeing init memory: 48K
mx1ads_startup
HD66770 Recycle LCD drivers 132x176 Version 0.1 installed
MXL-ADS Video Capture Module initialized
Call ssfdc_udisk_register_partition
Call usb_disk_register
USB Device mass storage interface installed
Date : 2005/01/06
Register usb_mmc_disk complete
MMC disk driver initialized
MX1ADS USB Device controller glue driver installed
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
Chip ID: 1b, Chip Revision: 0
MX1ADS : AC97 driver initialized.
#Error -3 while decompressing!
c00ec9b0(-7448380)->c0ac3000(4096)
framebuffer ioctl not supported: 17924
####

FreddyA
FreddyA's picture

Hi Urgentemente, I have a gut feeling the problem might be something i've run into before. I'll make up a story here to nudge you to try this and it might turn out to be a quick fix.
So the robot has been probed before in an attempt to fix him, and put back together after spotting the chared components on the motorboard. While connecting the robot media board a mistake was made and the two ribbon wires were left loose or badly seated OR swapped as they look identical. Lucky you, everything was fixed before you had to flash the robot and still not get past the loading....
Just as before i have accidently swapped the ribbons or had a broken ribbon and robots would not go past the wowwee loading screen. similar symptoms, similar fix. I say this since the robot media board is doing everything else its supposed to correctly, seemingly.
Hope that works that easy.

Freddy

Urgentemente
Urgentemente's picture

OOh, sounds intriguing FreddyA.
I'll take a look when I get the covers off,probably be friday evening or over the weekend (if I can resist that long!).

I've just copied the contents from the rsmdump over to my linux box, and mounted the nand3 dump, sure enough, it contains Billy Joe,Spacebot and Butler personalities files, so that answers wether my bot has personalities onboard (I tried with one on the sdcard as well earlier,no change).
Question: why does the personalities.txt file contain 4 entries, one of which is just a duplicate of spacebot, but all in lowercase , there's no corresponding directory for it (nor could there be, the nand3 dump on mine at least, is vfat, so Spacebot and spacebot would be the same filename...

FreddyA
FreddyA's picture

Id guess your personality will get fully loaded after the hangup and the reason there is a second spacebot is because its the last personality that was run, so it gets writen on the sd personality folder . my guess
Freddy

Helibot
Helibot's picture

Hi again,

There is a problem in the dmesg.txt. Normally it would look like the one posted at http://www.robocommunity.com/forum/thread/11947/Video-of-my-faulty-RS-Me...
Dont worry about the Badblock (many RSMedais have that and run OK). But you do have to worry about the decomprsssion.
#Error -3 while decompressing!
c00ec9b0(-7448380)->c0ac3000(4096)
But I am sorry I dont know whats caused it - havent seen this before. Have a look in /etc/profile (its the startup script) So you maybe able to find what it was trying todo after initialising the sound driver. I can investigate more tonight.

>Question: why does the personalities.txt file contain 4 entries, one of which
>is just a duplicate of spacebot, but all in lowercase , there's no
>corresponding directory for it (nor could there be, the nand3 dump on mine at
>least, is vfat, so Spacebot and spacebot would be the same filename...
There should only be three. It means that RSMedia Suite on the pc has probably been used by a previous someone to put a customised personality

Also See this link http://www.robocommunity.com/forum/thread/12477/RSMedia-can-t-boot./#10847. This thread describes the problem that Freddy was talking about. If teh two LCD cables are swapped he wont boot.... That may well be the problem in you bot.

Cheers
Helibot

Urgentemente
Urgentemente's picture

Thanks again Helibot (and everyone else who's commented so far).

I've had a quick look at the profile, and it looks like the audio driver is insmod'd as part of one of the SD / NonSD loops, followed by numerous file touches,and some mounting, then /usr/bin/robot/init_sd.sh and /usr/bin/robot/run.sh

About the swapped/loose cables thread, I read it, and it does sound almost exactly like the problem my bot has. At the end of the thread it said it was the camera connection causing all the problems, so when I take it apart we will see if it boots further with the various connectors disconnected.

Pages