From: mike2323 <mmi...@gm...> - 2009-02-13 19:32:17
|
Hello, I'm hoping that someone can help me with this. I'm a robostix novice. In the past, I've been able to get the i2c working with the robostix, but have recently come up against a problem that I just can't get past. I did quite a bit of searching for an answer, and I did come across one post that discussed the error, but I never found a resolution. I'm getting a 111 error when I use i2c-io or i2c-load. It happens about every other time I issue the command. Sometimes I'll get two successive non-error executions, but mostly it alternates between working correctly and getting the error. Below is a screenshot of 6 successive i2c-io executions on my Verdex: root@verdex2:/$ i2c-io 0x0b info version: 2 minVersion: 1 SVN Revision: 1604 root@verdex2:/$ i2c-io 0x0b info ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: I2cReadBlock failed ERROR: Unable to retrieve information from i2c address 0x0b root@verdex2:/$ i2c-io 0x0b info version: 2 minVersion: 1 SVN Revision: 1604 root@verdex2:/$ i2c-io 0x0b info ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: I2cReadBlock failed ERROR: Unable to retrieve information from i2c address 0x0b root@verdex2:/$ i2c-io 0x0b info version: 2 minVersion: 1 SVN Revision: 1604 root@verdex2:/$ i2c-io 0x0b info version: 2 minVersion: 1 SVN Revision: 1604 root@verdex2:/$ Here's my gumstix-version info: Revision 318M Built on Tue Feb 10 13:35:25 CST 2009 Build machine: dell-desktop Target machine: gumstix-custom-verdex libc: glibc Any ideas would be greatly appreciated. Thanks, - Mike -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p22003358.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: mike2323 <mmi...@gm...> - 2009-02-16 15:22:35
|
Here's some more information regarding the robostix 111 error that I was hoping might be helpful. I apologize for the verbosity of the message as I am still new to all of this. I seem to get better results when connecting the robostix to a connex board. Also, I'm using the i2c-Boot-m128-16MHz.hex and i2c-io.hex binaries from Dave Hyland's website. I still get the 111 error, but a lot less frequently. The most frequent error occurs while trying to load the i2c-io.hex file using i2c-load --reset 0x0b write i2c-io.hex as part of a startup script as shown below. I removed the repeated portions of the output for brevity. # ./rs_reboot.sh mknod: /dev/robostix: File exists insmod: error inserting '/rs/robostix_drv.ko': -1 File exists Atmel AVR ATmega128 is found. Fuse Low Byte set to 0xbf Fuse High Byte set to 0xc2 Fuse Extended Byte set to 0xff Atmel AVR ATmega128 is found. Erasing device ... Reinitializing device Atmel AVR ATmega128 is found. Uploading: flash Detected ATMega128 Write: ##ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderWrite: I2cWriteBlock failed: Connection refused (111) ERROR: Error writing 4 bytes to 0x4fc # ./rs_reboot.sh Write: #ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderWrite: I2cWriteBlock failed: Connection refused (111) ERROR: Error writing 28 bytes to 0x38 # ./rs_reboot.sh Write: ## Verify: #ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderRead: I2cReadBlock failed: Connection refused (111) ERROR: Error reading 28 bytes from 0x2a0 # ./rs_reboot.sh Write: #ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderWrite: I2cWriteBlock failed: Connection refused (111) ERROR: Error writing 28 bytes to 0x0 # ./rs_reboot.sh Write: #ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderWrite: I2cWriteBlock failed: Connection refused (111) ERROR: Error writing 28 bytes to 0x0 # ./rs_reboot.sh Write: ## Verify: ## Verify sucessful Write sucessful, rebooting... Once loaded, I was unable to get the 111 error on the i2-io 0x0b info command after issuing 50 of them in a row. Below is the repeated output. version: 2 minVersion: 1 SVN Revision: 1134 I followed that with twenty i2c-load 0x0b info commands without error until the 21st one. Below is the output for the last two commands. # i2c-load 0x0b info I2C Dev Addr: 0x00 Version: 1 MinVersion: 1 Part Number: 0x9702 (ATMega128) Reg Size: 256 RAM Size: 4096 EEPROM Size: 4096 Page Size: 256 Flash Size: 128k Node Name: not set Boot Delay: unset, defaults to 5 seconds I2C Addr: unset, defaults to 0x0b # i2c-load 0x0b info I2C Dev Addr: 0x00 Version: 1 MinVersion: 1 Part Number: 0x9702 (ATMega128) Reg Size: 256 RAM Size: 4096 EEPROM Size: 4096 Page Size: 256 Flash Size: 128k Node Name: not set ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderRead: I2cReadBlock failed: Connection refused (111) Boot Delay: 0 seconds ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderRead: I2cReadBlock failed: Connection refused (111) I2C Addr: 0x00 After that, I issued several more successful i2c-load 0x0b info commands until getting the error again as shown below. # i2c-load 0x0b info I2C Dev Addr: 0x00 Version: 1 MinVersion: 1 Part Number: 0x9702 (ATMega128) Reg Size: 256 RAM Size: 4096 EEPROM Size: 4096 Page Size: 256 Flash Size: 128k ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderRead: I2cReadBlock failed: Connection refused (111) Node Name: '(P' ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderRead: I2cReadBlock failed: Connection refused (111) Boot Delay: 0 seconds ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderRead: I2cReadBlock failed: Connection refused (111) I2C Addr: 0x00 Anyway, I hope someone will find this added information useful. Thanks for your help, - Mike Miller mike2323 wrote: > > Hello, > > I'm hoping that someone can help me with this. I'm a robostix novice. In > the past, I've been able to get the i2c working with the robostix, but > have recently come up against a problem that I just can't get past. I did > quite a bit of searching for an answer, and I did come across one post > that discussed the error, but I never found a resolution. > > I'm getting a 111 error when I use i2c-io or i2c-load. It happens about > every other time I issue the command. Sometimes I'll get two successive > non-error executions, but mostly it alternates between working correctly > and getting the error. > > Below is a screenshot of 6 successive i2c-io executions on my Verdex: > > root@verdex2:/$ i2c-io 0x0b info > version: 2 > minVersion: 1 > SVN Revision: 1604 > root@verdex2:/$ i2c-io 0x0b info > ERROR: I2cTransfer: ioctl failed: Connection refused (111) > ERROR: I2cReadBlock failed > ERROR: Unable to retrieve information from i2c address 0x0b > root@verdex2:/$ i2c-io 0x0b info > version: 2 > minVersion: 1 > SVN Revision: 1604 > root@verdex2:/$ i2c-io 0x0b info > ERROR: I2cTransfer: ioctl failed: Connection refused (111) > ERROR: I2cReadBlock failed > ERROR: Unable to retrieve information from i2c address 0x0b > root@verdex2:/$ i2c-io 0x0b info > version: 2 > minVersion: 1 > SVN Revision: 1604 > root@verdex2:/$ i2c-io 0x0b info > version: 2 > minVersion: 1 > SVN Revision: 1604 > root@verdex2:/$ > > Here's my gumstix-version info: > > Revision 318M > Built on Tue Feb 10 13:35:25 CST 2009 > Build machine: dell-desktop > Target machine: gumstix-custom-verdex > libc: glibc > > Any ideas would be greatly appreciated. > > Thanks, > > - Mike > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p22039249.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-02-16 20:32:21
|
Hi Mike, > # ./rs_reboot.sh What does this script look like? It appears like you're reprogramming the robostix each and every time you run the script? The ATMega128 has it's own flash, and it only needs to be reprogrammed when you actually want to change the program. It probably isn't relevant, but I figured I'd mention it. Can you show us the rs_reboot.sh script? The 111 error means that the gumstix sent out a command and failed to get an ACK to the address sent. This typically happens when the device is missing, although it can also happen if the device just isn't ready for the command, or there are physical problems with the bus, like the pullup resistors are not behaving properly. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: mike2323 <mmi...@gm...> - 2009-02-16 22:26:15
|
Hi Dave, Here's the script: modprobe i2c-dev modprobe i2c-pxa mknod /dev/robostix c 240 0 insmod /rs/robostix_drv.ko /rs/uisp --wr_fuse_l=0xbf --wr_fuse_h=0xc2 --wr_fuse_e=0xff /rs/uisp --erase --upload if=i2c-Boot-m128-16MHz.hex i2c-load --reset 0x0b write i2c-io.hex - Mike Dave Hylands wrote: > > Hi Mike, > >> # ./rs_reboot.sh > > What does this script look like? > > It appears like you're reprogramming the robostix each and every time > you run the script? > > The ATMega128 has it's own flash, and it only needs to be reprogrammed > when you actually want to change the program. It probably isn't > relevant, but I figured I'd mention it. > > Can you show us the rs_reboot.sh script? > > The 111 error means that the gumstix sent out a command and failed to > get an ACK to the address sent. This typically happens when the device > is missing, although it can also happen if the device just isn't ready > for the command, or there are physical problems with the bus, like the > pullup resistors are not behaving properly. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p22046929.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-02-16 22:46:40
|
Hi Mike, > modprobe i2c-dev > modprobe i2c-pxa > mknod /dev/robostix c 240 0 > insmod /rs/robostix_drv.ko > /rs/uisp --wr_fuse_l=0xbf --wr_fuse_h=0xc2 --wr_fuse_e=0xff > /rs/uisp --erase --upload if=i2c-Boot-m128-16MHz.hex > i2c-load --reset 0x0b write i2c-io.hex I think that something might be causing the gumstix side to get hung. And IIRC once the gumstix side is hung, it stays that way until the HW is reinitialized. Can you try doing rmmod i2c-pxa after it gets hung and see if that fixes things? -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2009-02-17 02:10:46
|
Hi Mike, > I tried the rmmod i2c-pxa. It didn't fix everything, but it did make a > difference. Now the i2c-load 0x0b info command works every time. However, > the i2c-io 0x0b get c.0 gets the 111 error more often. It takes about 5 or > so reads to get a value instead of every other time. It sounds like a timing problem? What speed motherboard do you have? Do the LEDs on the robostix blink at the right rate (a double heartbeat about once per second)? It could also be something like a cold solder joint on the pullups or the voltage converter, or something like that. You wouldn't happen to have another robostix you could try this with? -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: mike2323 <mmi...@gm...> - 2009-02-17 12:11:29
|
Dave Hylands wrote: > > Hi Mike, > >> I tried the rmmod i2c-pxa. It didn't fix everything, but it did make a >> difference. Now the i2c-load 0x0b info command works every time. >> However, >> the i2c-io 0x0b get c.0 gets the 111 error more often. It takes about 5 >> or >> so reads to get a value instead of every other time. > > It sounds like a timing problem? > What speed motherboard do you have? > > 600MHz > > Do the LEDs on the robostix blink at the right rate (a double > heartbeat about once per second)? > > Yes > > It could also be something like a cold solder joint on the pullups or > the voltage converter, or something like that. You wouldn't happen to > have another robostix you could try this with? > > I have 2 more. I'll give them a try. > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p22055645.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: mike2323 <mmi...@gm...> - 2009-02-17 13:49:03
|
Hi Dave, I tried the other two boards, I still get the 111 errors, but the boards did behave a little differently. On the first robostix, I got the following when I first tried uisp commands: Probably the AVR MCU is not in the RESET state. Check it out and run me again. Tried using robostix reset pulse. but it didnt' help. Finally wound up putting the etc/init.d/S10robostix script back in, which contains the following, and rebooting. /sbin/modprobe proc_gpio echo "AF2 in" > /proc/gpio/GPIO46 echo "AF1 out" > /proc/gpio/GPIO47 echo "GPIO out clear" > /proc/gpio/GPIO72 echo "GPIO out set" > /proc/gpio/GPIO70 echo "GPIO out set" > /proc/gpio/GPIO73 After that, the robostix behaved pretty much as the original robostix - no 111 errors on i2c-load 0x0b info, and 111 errors every other time on i2c-io 0x0b info. On the second robostix, I had an odd thing happen. I left the S10robostix in, and on boot I wound up with a blue flashing light on the robostix. I think I had only run modprobe robostix_drv to get uisp to work after booting before I noticed the light. From there, I was able to run the rs_reboot script, and have everything behave as on the original robostix with respect to the 111 errors. One thing to note, I did experiment with some rmmod's and modprobe's on the other drivers (i2c-dev, i2c-core, robostix-drv) prior to attaching the 2nd robostix. I hope that didn't mess up troubleshooting. If so, I apologize. Also, I wasn't sure if the following i2c-pxa output was normal: # modprobe i2c-pxa : Enabling slave mode I2C: i2c-0: PXA I2C adapter, slave address 1 : Enabling slave mode I2C: i2c-1: PXA I2C adapter, slave address 1 - Mike mike2323 wrote: > > > > Dave Hylands wrote: >> >> Hi Mike, >> >>> I tried the rmmod i2c-pxa. It didn't fix everything, but it did make a >>> difference. Now the i2c-load 0x0b info command works every time. >>> However, >>> the i2c-io 0x0b get c.0 gets the 111 error more often. It takes about 5 >>> or >>> so reads to get a value instead of every other time. >> >> It sounds like a timing problem? >> What speed motherboard do you have? >> >> 600MHz >> >> Do the LEDs on the robostix blink at the right rate (a double >> heartbeat about once per second)? >> >> Yes >> >> It could also be something like a cold solder joint on the pullups or >> the voltage converter, or something like that. You wouldn't happen to >> have another robostix you could try this with? >> >> I have 2 more. I'll give them a try. >> -- >> Dave Hylands >> Shuswap, BC, Canada >> http://www.DaveHylands.com/ >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >> CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source code: >> SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p22057647.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-02-17 16:41:46
|
Hi Mike, > Tried using robostix reset pulse. but it didnt' help. Finally wound up > putting the etc/init.d/S10robostix script back in, which contains the > following, and rebooting. > > /sbin/modprobe proc_gpio > echo "AF2 in" > /proc/gpio/GPIO46 > echo "AF1 out" > /proc/gpio/GPIO47 > echo "GPIO out clear" > /proc/gpio/GPIO72 > echo "GPIO out set" > /proc/gpio/GPIO70 > echo "GPIO out set" > /proc/gpio/GPIO73 > > After that, the robostix behaved pretty much as the original robostix - no > 111 errors on i2c-load 0x0b info, and 111 errors every other time on i2c-io > 0x0b info. The S10robostix script basically turns on the power, and takes the robostix out of reset so that it can run whatever program is burned into flash. Also, all of my testing was done with the 400 MHz parts. So it's possible that this is some type of timing issue with the u2c bus. Which version of buildroot/OE are you using? > On the second robostix, I had an odd thing happen. I left the S10robostix > in, and on boot I wound up with a blue flashing light on the robostix. I > think I had only run modprobe robostix_drv to get uisp to work after booting > before I noticed the light. From there, I was able to run the rs_reboot > script, and have everything behave as on the original robostix with respect > to the 111 errors. The robostix_drv.ko file needs to be loaded for uisp to work (one of the things that the robostix driver does is to fake out the parallel port API, so that uisp thinks its talking to a parallel port). > One thing to note, I did experiment with some rmmod's and modprobe's on the > other drivers (i2c-dev, i2c-core, robostix-drv) prior to attaching the 2nd > robostix. I hope that didn't mess up troubleshooting. If so, I apologize. The robostix one shouldn't make any difference. Unloading and reloading the i2c ones can sometimes clear up the HW if it gets into a weird state. Your problem sounds more like timing. I'm on my windows laptop right now and don't have access to the source code, but you might want to try increasing the i2c timeout. > Also, I wasn't sure if the following i2c-pxa output was normal: > > # modprobe i2c-pxa > : Enabling slave mode > I2C: i2c-0: PXA I2C adapter, slave address 1 > : Enabling slave mode > I2C: i2c-1: PXA I2C adapter, slave address 1 Yeah - the verdex has 2 i2c buses, one is connected to the power management chip. i2c-0 is still the one connected to the robostix. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: mike2323 <mmi...@gm...> - 2009-02-17 17:46:22
|
Dave Hylands wrote: > > Hi Mike, > >> Tried using robostix reset pulse. but it didnt' help. Finally wound up >> putting the etc/init.d/S10robostix script back in, which contains the >> following, and rebooting. >> >> /sbin/modprobe proc_gpio >> echo "AF2 in" > /proc/gpio/GPIO46 >> echo "AF1 out" > /proc/gpio/GPIO47 >> echo "GPIO out clear" > /proc/gpio/GPIO72 >> echo "GPIO out set" > /proc/gpio/GPIO70 >> echo "GPIO out set" > /proc/gpio/GPIO73 >> >> After that, the robostix behaved pretty much as the original robostix - >> no >> 111 errors on i2c-load 0x0b info, and 111 errors every other time on >> i2c-io >> 0x0b info. > > The S10robostix script basically turns on the power, and takes the > robostix out of reset so that it can run whatever program is burned > into flash. > > Also, all of my testing was done with the 400 MHz parts. So it's > possible that this is some type of timing issue with the u2c bus. > > Which version of buildroot/OE are you using? > > Buildroot 1545M > OE 318M > >> On the second robostix, I had an odd thing happen. I left the >> S10robostix >> in, and on boot I wound up with a blue flashing light on the robostix. I >> think I had only run modprobe robostix_drv to get uisp to work after >> booting >> before I noticed the light. From there, I was able to run the rs_reboot >> script, and have everything behave as on the original robostix with >> respect >> to the 111 errors. > > The robostix_drv.ko file needs to be loaded for uisp to work (one of > the things that the robostix driver does is to fake out the parallel > port API, so that uisp thinks its talking to a parallel port). > >> One thing to note, I did experiment with some rmmod's and modprobe's on >> the >> other drivers (i2c-dev, i2c-core, robostix-drv) prior to attaching the >> 2nd >> robostix. I hope that didn't mess up troubleshooting. If so, I >> apologize. > > The robostix one shouldn't make any difference. Unloading and > reloading the i2c ones can sometimes clear up the HW if it gets into a > weird state. Your problem sounds more like timing. > > I'm on my windows laptop right now and don't have access to the source > code, but you might want to try increasing the i2c timeout. > > I'd be glad to give it a try. Where do I make the change? > >> Also, I wasn't sure if the following i2c-pxa output was normal: >> >> # modprobe i2c-pxa >> : Enabling slave mode >> I2C: i2c-0: PXA I2C adapter, slave address 1 >> : Enabling slave mode >> I2C: i2c-1: PXA I2C adapter, slave address 1 > > Yeah - the verdex has 2 i2c buses, one is connected to the power > management chip. i2c-0 is still the one connected to the robostix. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p22062550.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: batoub <ba...@gm...> - 2009-04-22 10:10:56
|
Hi! I have the same problem, I can write the i2c-bootloader but I can't use i2c-load: root@gumstix-custom-verdex:~$ i2c-load 0x0b write i2c-io.hex Detected ATMega128 Write: #ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderWrite: I2cWriteBlock failed: Connection refused (111) Well, have you got a solution? Thank! mike2323 wrote: > > > > Dave Hylands wrote: >> >> Hi Mike, >> >>> Tried using robostix reset pulse. but it didnt' help. Finally wound up >>> putting the etc/init.d/S10robostix script back in, which contains the >>> following, and rebooting. >>> >>> /sbin/modprobe proc_gpio >>> echo "AF2 in" > /proc/gpio/GPIO46 >>> echo "AF1 out" > /proc/gpio/GPIO47 >>> echo "GPIO out clear" > /proc/gpio/GPIO72 >>> echo "GPIO out set" > /proc/gpio/GPIO70 >>> echo "GPIO out set" > /proc/gpio/GPIO73 >>> >>> After that, the robostix behaved pretty much as the original robostix - >>> no >>> 111 errors on i2c-load 0x0b info, and 111 errors every other time on >>> i2c-io >>> 0x0b info. >> >> The S10robostix script basically turns on the power, and takes the >> robostix out of reset so that it can run whatever program is burned >> into flash. >> >> Also, all of my testing was done with the 400 MHz parts. So it's >> possible that this is some type of timing issue with the u2c bus. >> >> Which version of buildroot/OE are you using? >> >> Buildroot 1545M >> OE 318M >> >>> On the second robostix, I had an odd thing happen. I left the >>> S10robostix >>> in, and on boot I wound up with a blue flashing light on the robostix. >>> I >>> think I had only run modprobe robostix_drv to get uisp to work after >>> booting >>> before I noticed the light. From there, I was able to run the rs_reboot >>> script, and have everything behave as on the original robostix with >>> respect >>> to the 111 errors. >> >> The robostix_drv.ko file needs to be loaded for uisp to work (one of >> the things that the robostix driver does is to fake out the parallel >> port API, so that uisp thinks its talking to a parallel port). >> >>> One thing to note, I did experiment with some rmmod's and modprobe's on >>> the >>> other drivers (i2c-dev, i2c-core, robostix-drv) prior to attaching the >>> 2nd >>> robostix. I hope that didn't mess up troubleshooting. If so, I >>> apologize. >> >> The robostix one shouldn't make any difference. Unloading and >> reloading the i2c ones can sometimes clear up the HW if it gets into a >> weird state. Your problem sounds more like timing. >> >> I'm on my windows laptop right now and don't have access to the source >> code, but you might want to try increasing the i2c timeout. >> >> I'd be glad to give it a try. Where do I make the change? >> >>> Also, I wasn't sure if the following i2c-pxa output was normal: >>> >>> # modprobe i2c-pxa >>> : Enabling slave mode >>> I2C: i2c-0: PXA I2C adapter, slave address 1 >>> : Enabling slave mode >>> I2C: i2c-1: PXA I2C adapter, slave address 1 >> >> Yeah - the verdex has 2 i2c buses, one is connected to the power >> management chip. i2c-0 is still the one connected to the robostix. >> >> -- >> Dave Hylands >> Shuswap, BC, Canada >> http://www.DaveHylands.com/ >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >> CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source code: >> SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p23173393.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-02-17 18:39:55
|
Hi Mike, > >> After that, the robostix behaved pretty much as the original robostix - > >> no > >> 111 errors on i2c-load 0x0b info, and 111 errors every other time on > >> i2c-io > >> 0x0b info. Hmm. I looked at the drivers/i2c/busses/i2c-pxa.c file, and there is only one place that the -111 error gets returned. XFER_NAKED is #defined to be ECONNREFUSED, which is 111. The one place in the code happens when the address was ACKed but some of the later data was NAKed. I thought there was a delay in here, but I'm not seeing what I was thinking of. It could have been from an earlier version of the driver. Sorry I can't be of much more help here. I know I have a 600 MHz verdex at home somewhere. If I can find it, I'll try and reproduce your setup (I won't be home until the weekend though). -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: mike2323 <mmi...@gm...> - 2009-02-17 19:40:42
|
Dave Hylands wrote: > > Hi Mike, > >> >> After that, the robostix behaved pretty much as the original robostix >> - >> >> no >> >> 111 errors on i2c-load 0x0b info, and 111 errors every other time on >> >> i2c-io >> >> 0x0b info. > > Hmm. I looked at the drivers/i2c/busses/i2c-pxa.c file, and there is > only one place that the -111 error gets returned. XFER_NAKED is > #defined to be ECONNREFUSED, which is 111. > > The one place in the code happens when the address was ACKed but some > of the later data was NAKed. > > I thought there was a delay in here, but I'm not seeing what I was > thinking of. It could have been from an earlier version of the driver. > > Sorry I can't be of much more help here. I know I have a 600 MHz > verdex at home somewhere. If I can find it, I'll try and reproduce > your setup (I won't be home until the weekend though). > > If you're able to, that would be great. In the meantime, thanks for all > your time. > > I have to say that this is very perplexing. I'm almost certain that I had > these verdex and robostix boards working just fine. In fact, I used one > of them to create an image backup that I copied to three others. I sent > one of them to my colleague, which he was able to run 24/7 for more than 6 > months. Unfortunately, it was bricked while being shipping back to me > recently. > > As far as I know, there were only two differences between them - I had to > install a later uboot image in order to read the microsd at the GUM > prompt, and the jumpers that I use between the gumstix and robostix. My > wires that connect the gumstix STUART to the robostix UART0 are slightly > thicker, and the resister on the robostix gumstix pins is 3.23kOhm. > > One other thing that might be worth mentioning is that we put together our > own power adapter. It outputs 5V at 3A, which is split into two plugs. > One for the wifimicrosd card, and the other for the robostix. I've used > it at times on both verdex stacks. For troubleshooting, I've tried > various combinations of adapters - 2x5v on the microsd/verdex/robostix > stack, 1x5v and 1x4v + 1x5v on the tweener/verdex/robostix stack. > > Anyway, I just thought I'd toss that out there. Again, thanks for your > help. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p22064736.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: batoub <ba...@gm...> - 2009-04-22 10:16:34
|
Hi! I have the same problem, I can write the i2c-bootloader but I can't use i2c-load: root@gumstix-custom-verdex:~$ i2c-load 0x0b write i2c-io.hex Detected ATMega128 Write: #ERROR: I2cTransfer: ioctl failed: Connection refused (111) ERROR: BootLoaderWrite: I2cWriteBlock failed: Connection refused (111) Well, have you got a solution? Thank! mike2323 wrote: > > > > Dave Hylands wrote: >> >> Hi Mike, >> >>> Tried using robostix reset pulse. but it didnt' help. Finally wound up >>> putting the etc/init.d/S10robostix script back in, which contains the >>> following, and rebooting. >>> >>> /sbin/modprobe proc_gpio >>> echo "AF2 in" > /proc/gpio/GPIO46 >>> echo "AF1 out" > /proc/gpio/GPIO47 >>> echo "GPIO out clear" > /proc/gpio/GPIO72 >>> echo "GPIO out set" > /proc/gpio/GPIO70 >>> echo "GPIO out set" > /proc/gpio/GPIO73 >>> >>> After that, the robostix behaved pretty much as the original robostix - >>> no >>> 111 errors on i2c-load 0x0b info, and 111 errors every other time on >>> i2c-io >>> 0x0b info. >> >> The S10robostix script basically turns on the power, and takes the >> robostix out of reset so that it can run whatever program is burned >> into flash. >> >> Also, all of my testing was done with the 400 MHz parts. So it's >> possible that this is some type of timing issue with the u2c bus. >> >> Which version of buildroot/OE are you using? >> >> Buildroot 1545M >> OE 318M >> >>> On the second robostix, I had an odd thing happen. I left the >>> S10robostix >>> in, and on boot I wound up with a blue flashing light on the robostix. >>> I >>> think I had only run modprobe robostix_drv to get uisp to work after >>> booting >>> before I noticed the light. From there, I was able to run the rs_reboot >>> script, and have everything behave as on the original robostix with >>> respect >>> to the 111 errors. >> >> The robostix_drv.ko file needs to be loaded for uisp to work (one of >> the things that the robostix driver does is to fake out the parallel >> port API, so that uisp thinks its talking to a parallel port). >> >>> One thing to note, I did experiment with some rmmod's and modprobe's on >>> the >>> other drivers (i2c-dev, i2c-core, robostix-drv) prior to attaching the >>> 2nd >>> robostix. I hope that didn't mess up troubleshooting. If so, I >>> apologize. >> >> The robostix one shouldn't make any difference. Unloading and >> reloading the i2c ones can sometimes clear up the HW if it gets into a >> weird state. Your problem sounds more like timing. >> >> I'm on my windows laptop right now and don't have access to the source >> code, but you might want to try increasing the i2c timeout. >> >> I'd be glad to give it a try. Where do I make the change? >> >>> Also, I wasn't sure if the following i2c-pxa output was normal: >>> >>> # modprobe i2c-pxa >>> : Enabling slave mode >>> I2C: i2c-0: PXA I2C adapter, slave address 1 >>> : Enabling slave mode >>> I2C: i2c-1: PXA I2C adapter, slave address 1 >> >> Yeah - the verdex has 2 i2c buses, one is connected to the power >> management chip. i2c-0 is still the one connected to the robostix. >> >> -- >> Dave Hylands >> Shuswap, BC, Canada >> http://www.DaveHylands.com/ >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >> CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source code: >> SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p23173473.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: mike2323 <mmi...@gm...> - 2009-02-16 23:20:26
|
Hi Dave, I tried the rmmod i2c-pxa. It didn't fix everything, but it did make a difference. Now the i2c-load 0x0b info command works every time. However, the i2c-io 0x0b get c.0 gets the 111 error more often. It takes about 5 or so reads to get a value instead of every other time. - Mike Dave Hylands wrote: > > Hi Mike, > >> modprobe i2c-dev >> modprobe i2c-pxa >> mknod /dev/robostix c 240 0 >> insmod /rs/robostix_drv.ko >> /rs/uisp --wr_fuse_l=0xbf --wr_fuse_h=0xc2 --wr_fuse_e=0xff >> /rs/uisp --erase --upload if=i2c-Boot-m128-16MHz.hex >> i2c-load --reset 0x0b write i2c-io.hex > > I think that something might be causing the gumstix side to get hung. > And IIRC once the gumstix side is hung, it stays that way until the HW > is reinitialized. > > Can you try doing > > rmmod i2c-pxa > > after it gets hung and see if that fixes things? > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p22047999.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: batoub <ba...@gm...> - 2009-04-24 10:29:34
|
Ok, but I have only one robostix and no way to try an other :/ Hummm... What can I do? Steve can you tell us if there is some problem with some robostix version ? Thank you! 2009/4/22 mike2323 <mmi...@gm...> > > Not sure if it's the best solution, but I wound up ordering two new > robostix > boards. > > We had a set of boards at an installation that were working fine. So I had > them send me one, and it also worked with all of my verdex boards. To be > sure, I alternated between my old robostix boards and theirs, and all of > mine still had the 111 error. Not sure if the old boards are in some weird > state, and can be fixed, or if they've got a voltage problem or something. > Anyway, I had to move on with my project, so I opted to go the new board > route. Hope this helps. I would be interested to see if anyone comes up > with a better solution as I'd like to be able to use my other boards. > > > batoub wrote: > > > > Hi! > > > > I have the same problem, I can write the i2c-bootloader but I can't use > > i2c-load: > > root@gumstix-custom-verdex:~$ i2c-load 0x0b write i2c-io.hex > > Detected ATMega128 > > Write: #ERROR: I2cTransfer: ioctl failed: Connection refused (111) > > ERROR: BootLoaderWrite: I2cWriteBlock failed: Connection refused (111) > > > > > > Well, have you got a solution? > > > > Thank! > > > > > > > > > > mike2323 wrote: > >> > >> > >> > >> Dave Hylands wrote: > >>> > >>> Hi Mike, > >>> > >>>> Tried using robostix reset pulse. but it didnt' help. Finally wound > up > >>>> putting the etc/init.d/S10robostix script back in, which contains the > >>>> following, and rebooting. > >>>> > >>>> /sbin/modprobe proc_gpio > >>>> echo "AF2 in" > /proc/gpio/GPIO46 > >>>> echo "AF1 out" > /proc/gpio/GPIO47 > >>>> echo "GPIO out clear" > /proc/gpio/GPIO72 > >>>> echo "GPIO out set" > /proc/gpio/GPIO70 > >>>> echo "GPIO out set" > /proc/gpio/GPIO73 > >>>> > >>>> After that, the robostix behaved pretty much as the original robostix > - > >>>> no > >>>> 111 errors on i2c-load 0x0b info, and 111 errors every other time on > >>>> i2c-io > >>>> 0x0b info. > >>> > >>> The S10robostix script basically turns on the power, and takes the > >>> robostix out of reset so that it can run whatever program is burned > >>> into flash. > >>> > >>> Also, all of my testing was done with the 400 MHz parts. So it's > >>> possible that this is some type of timing issue with the u2c bus. > >>> > >>> Which version of buildroot/OE are you using? > >>> > >>> Buildroot 1545M > >>> OE 318M > >>> > >>>> On the second robostix, I had an odd thing happen. I left the > >>>> S10robostix > >>>> in, and on boot I wound up with a blue flashing light on the robostix. > >>>> I > >>>> think I had only run modprobe robostix_drv to get uisp to work after > >>>> booting > >>>> before I noticed the light. From there, I was able to run the > >>>> rs_reboot > >>>> script, and have everything behave as on the original robostix with > >>>> respect > >>>> to the 111 errors. > >>> > >>> The robostix_drv.ko file needs to be loaded for uisp to work (one of > >>> the things that the robostix driver does is to fake out the parallel > >>> port API, so that uisp thinks its talking to a parallel port). > >>> > >>>> One thing to note, I did experiment with some rmmod's and modprobe's > on > >>>> the > >>>> other drivers (i2c-dev, i2c-core, robostix-drv) prior to attaching the > >>>> 2nd > >>>> robostix. I hope that didn't mess up troubleshooting. If so, I > >>>> apologize. > >>> > >>> The robostix one shouldn't make any difference. Unloading and > >>> reloading the i2c ones can sometimes clear up the HW if it gets into a > >>> weird state. Your problem sounds more like timing. > >>> > >>> I'm on my windows laptop right now and don't have access to the source > >>> code, but you might want to try increasing the i2c timeout. > >>> > >>> I'd be glad to give it a try. Where do I make the change? > >>> > >>>> Also, I wasn't sure if the following i2c-pxa output was normal: > >>>> > >>>> # modprobe i2c-pxa > >>>> : Enabling slave mode > >>>> I2C: i2c-0: PXA I2C adapter, slave address 1 > >>>> : Enabling slave mode > >>>> I2C: i2c-1: PXA I2C adapter, slave address 1 > >>> > >>> Yeah - the verdex has 2 i2c buses, one is connected to the power > >>> management chip. i2c-0 is still the one connected to the robostix. > >>> > >>> -- > >>> Dave Hylands > >>> Shuswap, BC, Canada > >>> http://www.DaveHylands.com/ > >>> > >>> > ------------------------------------------------------------------------------ > >>> Open Source Business Conference (OSBC), March 24-25, 2009, San > >>> Francisco, CA > >>> -OSBC tackles the biggest issue in open source: Open Sourcing the > >>> Enterprise > >>> -Strategies to boost innovation and cut costs with open source > >>> participation > >>> -Receive a $600 discount off the registration fee with the source code: > >>> SFAD > >>> http://p.sf.net/sfu/XcvMzF8H > >>> _______________________________________________ > >>> gumstix-users mailing list > >>> gum...@li... > >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users > >>> > >>> > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/i2c-robostix-problem-tp22003358p23175481.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Linus C. <li...@li...> - 2010-05-22 04:28:48
|
Has someone figure this out? On Fri, Apr 24, 2009 at 6:29 AM, batoub <ba...@gm...> wrote: > Ok, but I have only one robostix and no way to try an other :/ > > Hummm... What can I do? > Steve can you tell us if there is some problem with some robostix version ? > > Thank you! > > 2009/4/22 mike2323 <mmi...@gm...> >> >> Not sure if it's the best solution, but I wound up ordering two new >> robostix >> boards. >> >> We had a set of boards at an installation that were working fine. So I >> had >> them send me one, and it also worked with all of my verdex boards. To be >> sure, I alternated between my old robostix boards and theirs, and all of >> mine still had the 111 error. Not sure if the old boards are in some >> weird >> state, and can be fixed, or if they've got a voltage problem or something. >> Anyway, I had to move on with my project, so I opted to go the new board >> route. Hope this helps. I would be interested to see if anyone comes up >> with a better solution as I'd like to be able to use my other boards. >> >> >> batoub wrote: >> > >> > Hi! >> > >> > I have the same problem, I can write the i2c-bootloader but I can't use >> > i2c-load: >> > root@gumstix-custom-verdex:~$ i2c-load 0x0b write i2c-io.hex >> > Detected ATMega128 >> > Write: #ERROR: I2cTransfer: ioctl failed: Connection refused (111) >> > ERROR: BootLoaderWrite: I2cWriteBlock failed: Connection refused (111) >> > >> > >> > Well, have you got a solution? >> > >> > Thank! >> > >> > >> > >> > >> > mike2323 wrote: >> >> >> >> >> >> >> >> Dave Hylands wrote: >> >>> >> >>> Hi Mike, >> >>> >> >>>> Tried using robostix reset pulse. but it didnt' help. Finally wound >> >>>> up >> >>>> putting the etc/init.d/S10robostix script back in, which contains the >> >>>> following, and rebooting. >> >>>> >> >>>> /sbin/modprobe proc_gpio >> >>>> echo "AF2 in" > /proc/gpio/GPIO46 >> >>>> echo "AF1 out" > /proc/gpio/GPIO47 >> >>>> echo "GPIO out clear" > /proc/gpio/GPIO72 >> >>>> echo "GPIO out set" > /proc/gpio/GPIO70 >> >>>> echo "GPIO out set" > /proc/gpio/GPIO73 >> >>>> >> >>>> After that, the robostix behaved pretty much as the original robostix >> >>>> - >> >>>> no >> >>>> 111 errors on i2c-load 0x0b info, and 111 errors every other time on >> >>>> i2c-io >> >>>> 0x0b info. >> >>> >> >>> The S10robostix script basically turns on the power, and takes the >> >>> robostix out of reset so that it can run whatever program is burned >> >>> into flash. >> >>> >> >>> Also, all of my testing was done with the 400 MHz parts. So it's >> >>> possible that this is some type of timing issue with the u2c bus. >> >>> >> >>> Which version of buildroot/OE are you using? >> >>> >> >>> Buildroot 1545M >> >>> OE 318M >> >>> >> >>>> On the second robostix, I had an odd thing happen. I left the >> >>>> S10robostix >> >>>> in, and on boot I wound up with a blue flashing light on the >> >>>> robostix. >> >>>> I >> >>>> think I had only run modprobe robostix_drv to get uisp to work after >> >>>> booting >> >>>> before I noticed the light. From there, I was able to run the >> >>>> rs_reboot >> >>>> script, and have everything behave as on the original robostix with >> >>>> respect >> >>>> to the 111 errors. >> >>> >> >>> The robostix_drv.ko file needs to be loaded for uisp to work (one of >> >>> the things that the robostix driver does is to fake out the parallel >> >>> port API, so that uisp thinks its talking to a parallel port). >> >>> >> >>>> One thing to note, I did experiment with some rmmod's and modprobe's >> >>>> on >> >>>> the >> >>>> other drivers (i2c-dev, i2c-core, robostix-drv) prior to attaching >> >>>> the >> >>>> 2nd >> >>>> robostix. I hope that didn't mess up troubleshooting. If so, I >> >>>> apologize. >> >>> >> >>> The robostix one shouldn't make any difference. Unloading and >> >>> reloading the i2c ones can sometimes clear up the HW if it gets into a >> >>> weird state. Your problem sounds more like timing. >> >>> >> >>> I'm on my windows laptop right now and don't have access to the source >> >>> code, but you might want to try increasing the i2c timeout. >> >>> >> >>> I'd be glad to give it a try. Where do I make the change? >> >>> >> >>>> Also, I wasn't sure if the following i2c-pxa output was normal: >> >>>> >> >>>> # modprobe i2c-pxa >> >>>> : Enabling slave mode >> >>>> I2C: i2c-0: PXA I2C adapter, slave address 1 >> >>>> : Enabling slave mode >> >>>> I2C: i2c-1: PXA I2C adapter, slave address 1 >> >>> >> >>> Yeah - the verdex has 2 i2c buses, one is connected to the power >> >>> management chip. i2c-0 is still the one connected to the robostix. >> >>> >> >>> -- >> >>> Dave Hylands >> >>> Shuswap, BC, Canada >> >>> http://www.DaveHylands.com/ >> >>> >> >>> >> >>> ------------------------------------------------------------------------------ >> >>> Open Source Business Conference (OSBC), March 24-25, 2009, San >> >>> Francisco, CA >> >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >> >>> Enterprise >> >>> -Strategies to boost innovation and cut costs with open source >> >>> participation >> >>> -Receive a $600 discount off the registration fee with the source >> >>> code: >> >>> SFAD >> >>> http://p.sf.net/sfu/XcvMzF8H >> >>> _______________________________________________ >> >>> gumstix-users mailing list >> >>> gum...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >>> >> >>> >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/i2c-robostix-problem-tp22003358p23175481.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> >> ------------------------------------------------------------------------------ >> Stay on top of everything new and different, both inside and >> around Java (TM) technology - register by April 22, and save >> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. >> 300 plus technical and hands-on sessions. Register today. >> Use priority code J9JMT32. http://p.sf.net/sfu/p >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensign option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- Linus Casassa Estudiante Ingeniería Civil Electrónica Universidad Técnica Federico Santa María Fono: 56-9-97776941 |
From: mike2323 <mmi...@gm...> - 2009-04-22 14:24:03
|
Not sure if it's the best solution, but I wound up ordering two new robostix boards. We had a set of boards at an installation that were working fine. So I had them send me one, and it also worked with all of my verdex boards. To be sure, I alternated between my old robostix boards and theirs, and all of mine still had the 111 error. Not sure if the old boards are in some weird state, and can be fixed, or if they've got a voltage problem or something. Anyway, I had to move on with my project, so I opted to go the new board route. Hope this helps. I would be interested to see if anyone comes up with a better solution as I'd like to be able to use my other boards. batoub wrote: > > Hi! > > I have the same problem, I can write the i2c-bootloader but I can't use > i2c-load: > root@gumstix-custom-verdex:~$ i2c-load 0x0b write i2c-io.hex > Detected ATMega128 > Write: #ERROR: I2cTransfer: ioctl failed: Connection refused (111) > ERROR: BootLoaderWrite: I2cWriteBlock failed: Connection refused (111) > > > Well, have you got a solution? > > Thank! > > > > > mike2323 wrote: >> >> >> >> Dave Hylands wrote: >>> >>> Hi Mike, >>> >>>> Tried using robostix reset pulse. but it didnt' help. Finally wound up >>>> putting the etc/init.d/S10robostix script back in, which contains the >>>> following, and rebooting. >>>> >>>> /sbin/modprobe proc_gpio >>>> echo "AF2 in" > /proc/gpio/GPIO46 >>>> echo "AF1 out" > /proc/gpio/GPIO47 >>>> echo "GPIO out clear" > /proc/gpio/GPIO72 >>>> echo "GPIO out set" > /proc/gpio/GPIO70 >>>> echo "GPIO out set" > /proc/gpio/GPIO73 >>>> >>>> After that, the robostix behaved pretty much as the original robostix - >>>> no >>>> 111 errors on i2c-load 0x0b info, and 111 errors every other time on >>>> i2c-io >>>> 0x0b info. >>> >>> The S10robostix script basically turns on the power, and takes the >>> robostix out of reset so that it can run whatever program is burned >>> into flash. >>> >>> Also, all of my testing was done with the 400 MHz parts. So it's >>> possible that this is some type of timing issue with the u2c bus. >>> >>> Which version of buildroot/OE are you using? >>> >>> Buildroot 1545M >>> OE 318M >>> >>>> On the second robostix, I had an odd thing happen. I left the >>>> S10robostix >>>> in, and on boot I wound up with a blue flashing light on the robostix. >>>> I >>>> think I had only run modprobe robostix_drv to get uisp to work after >>>> booting >>>> before I noticed the light. From there, I was able to run the >>>> rs_reboot >>>> script, and have everything behave as on the original robostix with >>>> respect >>>> to the 111 errors. >>> >>> The robostix_drv.ko file needs to be loaded for uisp to work (one of >>> the things that the robostix driver does is to fake out the parallel >>> port API, so that uisp thinks its talking to a parallel port). >>> >>>> One thing to note, I did experiment with some rmmod's and modprobe's on >>>> the >>>> other drivers (i2c-dev, i2c-core, robostix-drv) prior to attaching the >>>> 2nd >>>> robostix. I hope that didn't mess up troubleshooting. If so, I >>>> apologize. >>> >>> The robostix one shouldn't make any difference. Unloading and >>> reloading the i2c ones can sometimes clear up the HW if it gets into a >>> weird state. Your problem sounds more like timing. >>> >>> I'm on my windows laptop right now and don't have access to the source >>> code, but you might want to try increasing the i2c timeout. >>> >>> I'd be glad to give it a try. Where do I make the change? >>> >>>> Also, I wasn't sure if the following i2c-pxa output was normal: >>>> >>>> # modprobe i2c-pxa >>>> : Enabling slave mode >>>> I2C: i2c-0: PXA I2C adapter, slave address 1 >>>> : Enabling slave mode >>>> I2C: i2c-1: PXA I2C adapter, slave address 1 >>> >>> Yeah - the verdex has 2 i2c buses, one is connected to the power >>> management chip. i2c-0 is still the one connected to the robostix. >>> >>> -- >>> Dave Hylands >>> Shuswap, BC, Canada >>> http://www.DaveHylands.com/ >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San >>> Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>> Enterprise >>> -Strategies to boost innovation and cut costs with open source >>> participation >>> -Receive a $600 discount off the registration fee with the source code: >>> SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/i2c-robostix-problem-tp22003358p23175481.html Sent from the Gumstix mailing list archive at Nabble.com. |