From: Adam M. <mcl...@gm...> - 2006-05-24 22:09:12
|
Thank you for bearing with me on this uphill battle. :) So I confirmed that the I2C modules are loaded into the kernel, and I sucessfully built i2c-load for the Gumstix, and i2c-Bootloader for the Atmega-8. I flashed i2c-Bootloader into the Atmega, and have every reason to believe that it's sitting there, running. I set the fuse bits as described in the wiki article 'Robostix-i2c-Bootloader', since I'm using an external 16Mhz resonator. I SCP'd i2c-load onto the gumstix and ran './i2c-load 0x0b info' as root, and got the familiar message: # ./i2c-load 0x0b info ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) ERROR: I2cReadBlock failed ERROR: Unable to retrieve boot information from i2c address 0x0b I figured that since I'm hooking an atmega-8 (5v) to the breakout-gs (3.3v), perhaps the level shifter was broken. I put oscilloscope probes on the 3.3v and 5v sides of both SDA and SCL, and found that like i2c-load is running, there is nary a wiggle on the pins (they as as if idle, pulled up to 3.3v and 5v respectively). This seem like the problem is on the gumstix side... Might it have anything to do with the 'freeing init memory' problem that was circumvented by Markus' patches to the uClibc configuration? Is this fixed in the current buildroot (I'm using 994)? Perhaps something was fried. Adam |
From: Nicholas S-A <no...@ma...> - 2006-05-27 20:21:41
Attachments:
ATmega8Programming.txt
|
> Nicholas, you said you managed to get the Bootloader running on the > same type of chip? Can you confirm the fuse settings? > > Adam > Yes, I did get the bootloader running (and i2c-io for that matter) on the same chip. This monsterous file is a cut down version of what I did in a few sessions to get to that phase. (through SSH) My original fuse settings: # uisp --wr_fuse_l=0xe4 --wr_fuse_h=0x99. However, I finally realized that this enabled the WDT, which gives this strange behavior: # i2c-load 0x0b info I2C Dev Addr: 0x0b Version: 1 MinVersion: 1 Part Number: 0x9307 (ATMega8) Reg Size: 96 RAM Size: 1024 EEPROM Size: 512 Page Size: 64 Flash Size: 8k ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) ERROR: BootLoaderRead: I2cReadBlock failed: Remote I/O error (121) Node Name: '?7' ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) ERROR: BootLoaderRead: I2cReadBlock failed: Remote I/O error (121) Boot Delay: 0 seconds ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) ERROR: BootLoaderRead: I2cReadBlock failed: Remote I/O error (121) I2C Addr: 0x00 Perfect for the first part, but the WDT overflows eventually and i2c fails. My eventual fuse settings were: # uisp --wr_fuse_l=0xe4 --wr_fuse_h=0xc9 . This works fine (I am not using an external crystal) with a single chip, but if you want an external crystal set the appropriate CLKSEL fuses (Dave Hylands says this should be Low Byte of 0xBF, that looks about right). The file cut some stuff out (like where I shorted the VCC and VDD that are next to each other on the ATmega8 and reset the gumstix stack, forcing a re-connect :0), but it should have a <Space> where stuff is cut out (except in dmesg listings, which were too long, so I shortened with ...). Also, most of the text is taken up by my -v=4 Uisp load of the bootloader, so sorry about the size ;-). hope that helps! (note: I removed the -v=4 download because the message was too big). Here is a shortened version: |
From: Dave H. <dhy...@gm...> - 2006-05-24 22:14:57
|
Hi Adam, > I figured that since I'm hooking an atmega-8 (5v) to the breakout-gs > (3.3v), perhaps the level shifter was broken. I put oscilloscope > probes on the 3.3v and 5v sides of both SDA and SCL, and found that > like i2c-load is running, there is nary a wiggle on the pins (they as > as if idle, pulled up to 3.3v and 5v respectively). This seem like > the problem is on the gumstix side... Might it have anything to do > with the 'freeing init memory' problem that was circumvented by > Markus' patches to the uClibc configuration? Is this fixed in the > current buildroot (I'm using 994)? Perhaps something was fried. I haven't loaded a recent build in a while. I'll see if I can test it tonig= ht. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2006-05-25 06:25:42
|
Hi Adam, > > I figured that since I'm hooking an atmega-8 (5v) to the breakout-gs > > (3.3v), perhaps the level shifter was broken. I put oscilloscope > > probes on the 3.3v and 5v sides of both SDA and SCL, and found that > > like i2c-load is running, there is nary a wiggle on the pins (they as > > as if idle, pulled up to 3.3v and 5v respectively). This seem like > > the problem is on the gumstix side... Might it have anything to do > > with the 'freeing init memory' problem that was circumvented by > > Markus' patches to the uClibc configuration? Is this fixed in the > > current buildroot (I'm using 994)? Perhaps something was fried. I built using the latest buildroot (996) and everything built and ran fine (from the i2c perspective). One thing to be aware of, there was a labelling mistake on the breakout-gs board (R277) The connector labeled ST is the STUART port. The I2C port is right next to the USB connector. The I2C connector is silkscreened to read: GND, TXD, VCC RXD and it should read: GND, SDA, VCC, SCL Similarly the ST connector is silscreened to read: GND SDA VCC SCL and it should read GND TXD VCC RXD. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Adam M. <mcl...@gm...> - 2006-05-25 11:52:23
|
No problems there; the labeling error is documented in the wiki. I'll try r996. I guess the only possible problems are a wonky buildroot, or a damaged gums= tix. Adam On 5/25/06, Dave Hylands <dhy...@gm...> wrote: > Hi Adam, > > I built using the latest buildroot (996) and everything built and ran > fine (from the i2c perspective). > > One thing to be aware of, there was a labelling mistake on the > breakout-gs board (R277) > > The connector labeled ST is the STUART port. The I2C port is right > next to the USB connector. > |
From: Dave H. <dhy...@gm...> - 2006-05-25 14:53:56
|
Hi Adam, > No problems there; the labeling error is documented in the wiki. I'll > try r996. > > I guess the only possible problems are a wonky buildroot, or a damaged gu= mstix. Oh yeah - I just used defconfig and used the precompiled modules for the test I did. Do you have an LED on your ATMega8? Was it flashing appropriately? Finally, when you connected the scope, was the ATMega8 connected to the gum= stix? What voltage level did you observe on the i2c bus? It should idle at the pulled up state. The fuse bytes have different definitions, so I wouldn't just blindly copy them. Some of the bits are common, but things like the bootloader sizes have totally different meanings. # For ATMega8 HFUSE #=09RSTDISBL=09=09=090x80 (want this set to 1) #=09WDTON=09=09=09=090x40 (1 =3D controlled by WDTCR) #=09SPIEN=09=09=09=090x20 (want this set to 0) #=09CKOPT=09=09=09=090x10 (set to 0 for external crystals/resonators) #=09EESAVE=09=09=09=090x08 (off) 0x00 (eeprom is saved) #=09BOOTSZ 0x06 #=09BOOTRST=09=09=09=090x01 (normal) 0x00 (bootloader) # # For ATMega8 LFUSE #=09BODLEVEL=09=09=090x80 (1 =3D 2.7v, 0 =3D 4.0v) #=09BODEN=09=09=09=090x40 (1 =3D BOD disabled) #=09SUT=09=09=09=09=090x30 #=09CKSEL=09=09=09=090x0F Accoring to AVRStudio, CKSEL=3D1111, SUT=3D11 gives: Ext crystal resonator High Freq; startup time 16k CK + 64ms On the ATMega8, I reserved the max of 2k, so BOOTSZ =3D 00 On the ATMega12 I reserved 4k for the bootloader, so BOOTSZ =3D 01 If just so happens that the upper two bits of hfuse have totally different meanings on the ATMega8 & 128, but using the defaults happens to give reasonable behaviour :) The real difference is the interpretation of the bootloader sizes, which are quite a bit different, So, keeping as much in common with the robostix fuses, I'd recommend the following settings for the ATMega8 fuses: hfuse: 11000000 (0xC0) For proper bootloading lfuse: 10111111 (0xBF) for external ceramic resonator --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Nicholas S-A <no...@ma...> - 2006-05-25 19:50:09
|
Yes, I thought along the same lines as Adam and left the high byte alone, but with the ATmega128 high byte, the watchdog timer is enabled, which means that the bootloader is continually reset. This doesn't work, and if you time it correctly (or try alot ;-)), you can get it to give you some info (e.g. give you Type: ATmega8, Version: 977, Timeout: i2c read error!, etc). You could probably modify the program to reset the WDT every few clock cycles, but it is easier to just disable WDT altogether. > > # For ATMega8 HFUSE > # RSTDISBL 0x80 (want this set to 1) > # WDTON 0x40 (1 = controlled by WDTCR) > # SPIEN 0x20 (want this set to 0) > # CKOPT 0x10 (set to 0 for external crystals/resonators) > # EESAVE 0x08 (off) 0x00 (eeprom is saved) > # BOOTSZ 0x06 > # BOOTRST 0x01 (normal) 0x00 (bootloader) > # > # For ATMega8 LFUSE > # BODLEVEL 0x80 (1 = 2.7v, 0 = 4.0v) > # BODEN 0x40 (1 = BOD disabled) > # SUT 0x30 > # CKSEL 0x0F > > > hfuse: 11000000 (0xC0) For proper bootloading > lfuse: 10111111 (0xBF) for external ceramic resonator > nick |
From: Adam M. <mcl...@gm...> - 2006-05-25 15:07:29
|
Oh, maybe this has something to do with it: Just checked out a fresh buildroot (r995 as of this morning... Shouldn't it be 996?), did a make ARCH=3Darm menuconfig ...and turned off bluez since I have no need for it. Then let it grind until it finished, went into the build_arm_nofpu/linux-2.6.15gum directory, and did another make ARCH=3Darm menuconfig. According to the wiki, there should exist a selection called 'I2C interface in Intel PXA2x0' under Device Drivers --> I2C Support --> I2C Hardware Bus Support. However, there is not. There is, however, something close that I picked last time: Intel PXA2XX I2C adapter (EXPERIMENTAL) Buggy drivers would explain I2C failure. Dave, am I missing anything in my incantations? Adam On 5/25/06, Adam McLeod <mcl...@gm...> wrote: > No problems there; the labeling error is documented in the wiki. I'll > try r996. > > I guess the only possible problems are a wonky buildroot, or a damaged gu= mstix. > > Adam > > On 5/25/06, Dave Hylands <dhy...@gm...> wrote: > > Hi Adam, > > > > I built using the latest buildroot (996) and everything built and ran > > fine (from the i2c perspective). > > > > One thing to be aware of, there was a labelling mistake on the > > breakout-gs board (R277) > > > > The connector labeled ST is the STUART port. The I2C port is right > > next to the USB connector. > > > |
From: Adam M. <mcl...@gm...> - 2006-05-25 16:15:58
|
On 5/25/06, Dave Hylands <dhy...@gm...> wrote: > Hi Adam, > > > No problems there; the labeling error is documented in the wiki. I'll > > try r996. > > > > I guess the only possible problems are a wonky buildroot, or a damaged = gumstix. > > Oh yeah - I just used defconfig and used the precompiled modules for > the test I did. > > Do you have an LED on your ATMega8? Was it flashing appropriately? No LED. The Robostix schematic says that the red LED is connected to /RESET, which is PC6 on the Atmega-8. > Finally, when you connected the scope, was the ATMega8 connected to the g= umstix? Yes. > What voltage level did you observe on the i2c bus? It should idle at > the pulled up state. As described, both sides of the level shifter were pulled up to the correct levels. > hfuse: 11000000 (0xC0) For proper bootloading > lfuse: 10111111 (0xBF) for external ceramic resonator What are you programming your Atmega with? Atmel has that bizzare convention wherein 0 means 'programmed' and 1 means 'unprogrammed'.; does your programmer reverse that convention, or preserve it? (I'm using PonyProg, which reverses the convention so 'checked' =3D=3D programmed =3D=3D 0). I'll assume that your '1' means 'unprogrammed', which means 'unchecked'. PonyProg2000 doesn't allow SPIEN to be programmed, for reasons I dont understand, but regardless we'll see what happens... Same thing, only this time it appears the Gumstix is pulling SCL low and leaving it that way. However, I can't detect any flashing on any pin on the Atmega-8, which would either explain the unresponsiveness, or imply there are two problems. Adam |
From: Dave H. <dhy...@gm...> - 2006-05-25 17:52:16
|
Hi Adam, > > Do you have an LED on your ATMega8? Was it flashing appropriately? > > No LED. The Robostix schematic says that the red LED is connected to > /RESET, which is PC6 on the Atmega-8. Huh. On the Robostix, the Red LED is connected to PG4. The i2c-Bootloader uses Config-LED.h to control which pin the LED maps to for various cpus. I set it up to map to PB4 which is MISO. > > Finally, when you connected the scope, was the ATMega8 connected to the= gumstix? > > Yes. OK - so it would be useful to try it with just the pullups on the gumstix side and no atmega. > What are you programming your Atmega with? My gumstix, using uisp. > Atmel has that bizzare > convention wherein 0 means 'programmed' and 1 means 'unprogrammed'.; > does your programmer reverse that convention, or preserve it? I'm using 0's and 1's exactly as they're mentioned in the datasheet. Much less confusion than trying to translate to checked/no-checked. And yes, 0 means programmed, 1 means unprogrammed (which is how flash works= ). > (I'm > using PonyProg, which reverses the convention so 'checked' =3D=3D > programmed =3D=3D 0). I'll assume that your '1' means 'unprogrammed', > which means 'unchecked'. PonyProg2000 doesn't allow SPIEN to be > programmed, for reasons I dont understand, but regardless we'll see > what happens... PonyProg doesn't allow SPIEN to be unprogrammed (regardless of what the UI shows). It's actually programmed, and unprogramming it would cause ISP (In System Programming) to fail, since ISP requires the SPI interface. > Same thing, only this time it appears the Gumstix is pulling SCL low > and leaving it that way. However, I can't detect any flashing on any > pin on the Atmega-8, which would either explain the unresponsiveness, > or imply there are two problems. I think that the ATMega8 may be the problem in this case. If you can't get the LED flashing, then something is wrong. And just to clarify, you are using i2c-Boot-m8-16MHz.hex and not i2c-Boot-m128-16MHz.hex right? --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Adam M. <mcl...@gm...> - 2006-05-25 19:01:45
|
On 5/25/06, Dave Hylands <dhy...@gm...> wrote: > Huh. On the Robostix, the Red LED is connected to PG4. Oh, we're both right. The anode is at ATM_RESET and the cathode is at PG4. > OK - so it would be useful to try it with just the pullups on the > gumstix side and no atmega. I'll have an opportunity to do that in a few hours, so I'll try it. > I think that the ATMega8 may be the problem in this case. If you can't > get the LED flashing, then something is wrong. I flashed it with another program and confirmed that it was still operating. Also verified the bootloader was written to the Atmega-8, and that the fuses were set correctly. Also flashed the bootloader to another Atmega-8, with the same results. > And just to clarify, you are using i2c-Boot-m8-16MHz.hex and not > i2c-Boot-m128-16MHz.hex right? The entirety of the robostix module checked out from SVN built with CPU_MCU=3D8 and CPU_FREQ=3D16, so yes. md5sum on Fedora and Cygwin also report that nothing was changed during the file transfer. If you'd like to compare: c7d29f5452774eb81e97a2f4420ab599 i2c-Boot-m8-16MHz.hex Perhaps I need to build avr-gcc with a specific version of gcc? Adam |
From: Dave H. <dhy...@gm...> - 2006-05-25 19:21:55
|
Hi Adam, > Perhaps I need to build avr-gcc with a specific version of gcc? I doubt that's the issue. As a sanity test, you could try the precompiled known working: http://www.davehylands.com/gumstix-wiki/ATMega8/i2c-Boot-m8-8MHz.hex The frequency really only affects the LED blink rate, so it should blink twice as fast as expected when running at 16 MHz. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Adam M. <mcl...@gm...> - 2006-05-25 19:52:13
|
No dice. It could be a problem with the wiring, but since the circuit flashes and runs other programs just fine, that would be odd. I'll review the hookup I have just in case, and change out the buildroot on the gumstix, but this is stabbing in the dark, really. MOSI is floating when I run the program (ISP disconnected), and the only other pins used on the Atmega at run time are power, ground, XTAL1 and 2, PD4 connected to a peripheral, PC5 and 6 pulled high by the I2C bus. I'll check for shorts next chance I get. On 5/25/06, Dave Hylands <dhy...@gm...> wrote: > Hi Adam, > > > Perhaps I need to build avr-gcc with a specific version of gcc? > > I doubt that's the issue. > > As a sanity test, you could try the precompiled known working: > http://www.davehylands.com/gumstix-wiki/ATMega8/i2c-Boot-m8-8MHz.hex > The frequency really only affects the LED blink rate, so it should > blink twice as fast as expected when running at 16 MHz. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications i= n > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmdlnk&kid=107521&bid$8729&dat=121642 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Adam M. <mcl...@gm...> - 2006-05-26 18:37:17
|
I hooked up another Atmega-8 on a separate breadboard; 8MHz resonator, power, ground, and ISP pins only. I confirmed that the Atmega was operational by running a program that should have produced a 50Hz square wave on PB4, which was observed. I downloaded and verified the Bootloader hex file that Dave linked to; http://www.davehylands.com/gumstix-wiki/ATMega8/i2c-Boot-m8-8MHz.hex ...and still couldn't see any flashing. I think that rules out shorts in my circuit. Nicholas, you said you managed to get the Bootloader running on the same type of chip? Can you confirm the fuse settings? Adam On 5/25/06, Adam McLeod <mcl...@gm...> wrote: > No dice. It could be a problem with the wiring, but since the circuit > flashes and runs other programs just fine, that would be odd. I'll > review the hookup I have just in case, and change out the buildroot on > the gumstix, but this is stabbing in the dark, really. MOSI is > floating when I run the program (ISP disconnected), and the only other > pins used on the Atmega at run time are power, ground, XTAL1 and 2, > PD4 connected to a peripheral, PC5 and 6 pulled high by the I2C bus. > I'll check for shorts next chance I get. > |
From: Dave H. <dhy...@gm...> - 2006-05-26 19:47:32
|
> I hooked up another Atmega-8 on a separate breadboard; 8MHz resonator, > power, ground, and ISP pins only. I confirmed that the Atmega was > operational by running a program that should have produced a 50Hz > square wave on PB4, which was observed. I downloaded and verified the > Bootloader hex file that Dave linked to; > http://www.davehylands.com/gumstix-wiki/ATMega8/i2c-Boot-m8-8MHz.hex > ...and still couldn't see any flashing. I think that rules out shorts > in my circuit. I'll double check that image tonight and verify which pin the LED should be= on. --=20 Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Adam M. <mcl...@gm...> - 2006-06-13 20:11:54
|
Dave, First, thanks for going out of your way to offer so much support. Are you sure that any pin should flash on the ATMega-8 build of the bootloader? I've loaded it (your version) onto several chips, and tested all of their GPIO pins, and haven't seen any flashing. I've confirmed that the chips are functional by running other programs on them (with the same fuse settings), and I've also tested my level shifter. If it turns out that the program is running despite there being no flashing pin, my only guess as to the cause of the problem is what I stated earlier, about the PXA drivers: According to the wiki, there should exist a selection called 'I2C interface in Intel PXA2x0' under Device Drivers --> I2C Support --> I2C Hardware Bus Support. However, there is not. There is something close that I picked last time: Intel PXA2XX I2C adapter (EXPERIMENTAL) Could this be an issue? Adam On 5/26/06, Dave Hylands <dhy...@gm...> wrote: > > I'll double check that image tonight and verify which pin the LED should be on. > |
From: Dave H. <dhy...@gm...> - 2006-06-13 21:44:23
|
Hi Adam, > Are you sure that any pin should flash on the ATMega-8 build of the > bootloader? I've loaded it (your version) onto several chips, and > tested all of their GPIO pins, and haven't seen any flashing. I've > confirmed that the chips are functional by running other programs on > them (with the same fuse settings), and I've also tested my level > shifter. I'll double check by reloading the precompiled image onto my ATMega8 (which is a 28 pin DIP version) tonight when I get home. I'll also double check which way I had the LED conencted up (to +5 or Gnd), although this should only change when the LED is on versus off. When you were testing, do you have the programmer connected? > If it turns out that the program is running despite there being no > flashing pin, my only guess as to the cause of the problem is what I > stated earlier, about the PXA drivers: > > According to the wiki, there should exist a selection called 'I2C > interface in Intel PXA2x0' under Device Drivers --> I2C Support --> > I2C Hardware Bus Support. > > However, there is not. There is something close that I > picked last time: > > Intel PXA2XX I2C adapter (EXPERIMENTAL) > > Could this be an issue? That's the right thing to choose. I updated the I2CQuickStart page. Other items to check (I don't recall whether these have been mentioned already or not): - Make sure you have a common ground between the gumstix and the ATMega8 - Make sure that you have pullup resistors on the SDA and SCL lines that pull them upto 3.3v. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Adam M. <mcl...@gm...> - 2006-06-13 22:15:40
|
On 6/13/06, Dave Hylands <dhy...@gm...> wrote: > Hi Adam, > When you were testing, do you have the programmer connected? I began to think that might have been an issue, so no; in the last test I did to confirm that what I was saying was correct, I pulled the programmer out before testing the pins. I had been doing that in the past, though. > Other items to check (I don't recall whether these have been mentioned > already or not): > - Make sure you have a common ground between the gumstix and the ATMega8 They share a ground through the I2C connector. I just changed the setup such that they now share also share the power (they're now fed by the same regulator), but this doesn't change anything. > - Make sure that you have pullup resistors on the SDA and SCL lines > that pull them upto 3.3v. I'm using the level shifting circuit that Philips reccomends to go from 3.3v to 5v (application note AN97055). It's just two FETs and four pull-up resistors. I isolated that section of the circuit and made sure each side could pull the bus low. If I run i2c-io a few times on the gumstix, I can occasionally see the burst on the oscilloscope, so I'm pretty confident that the bus circuitry is fine. Adam |
From: Dave H. <dhy...@gm...> - 2006-06-14 07:17:46
|
Hi Adam, > I began to think that might have been an issue, so no; in the last > test I did to confirm that what I was saying was correct, I pulled the > programmer out before testing the pins. I had been doing that in the > past, though. OK - I reprogrammed my 28 pin DIP ATMega8 using the i2c-Boot-m8-8MHz.hex file from http://www.davehylands.com/gumstix-wiki/ATMega8/ Pin 18 (which is PB4/MISO) flashes twice per second. My LED is connected up like this: PB4 ------/\/\/\/\-----|>|----- Gnd using a 470 ohm resistor. To test your LED, connect the resistor to +5 to verify that it lights. Do you have all of the power and grounds connected on the ATMega8? Mine has pins 8 and 22 going to groound, and pins 7, and 20 going to +5. All of the remaining pins are unconnected (except for PB4 to the LED). My fuses are set with hfuse being 0xD8 and lfuse being 0xE4, which is appropriate for using the 8 MHz internal oscillator. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |