Probably the AVR MCU is not in the RESET state

[vnalla]

Hi Everybody,
I am new to this forum.
I have two boards, Robostix and Roboaudio-Th and I have a question on Roboaudio board.
I followed the directions on "http://docwiki.gumstix.org/Robostix_gumstix_ISP" to program the Robostix from the Gumstix running version 1161. Every thing works fine with Robostix.
I have problem with Roboaudio: I am able play audio using the Roboaudio. But when I follow the same procedure to program the Atmel chip, I get "Probably the AVR MCU is not in the RESET state" message. I used the same mother board, jumper cable (which connects Atmel 0 Tx to PXA ST Rx and Atmel 0 Rx to PXA ST Tx) etc. to reduce the ambiguities.
L_DD12, L_DD14, L_DD15 are the only control signals (in my opinion) required from Gumstix. I have done the following to make sure the Atmel gets the correct control signals:
I have shorted the pins 1&2 of U$59 and U$60 to make sure the Atmel gets the VCC5 with out doubt and I confirmed the same.
I soldered a small wire to pin 20 (reset) of Atmel to measure the state. It goes high when GPIO73 is set high and goes low when GPIO73 is set low. So reset works fine.
I lost console communication when GPIO72 is set high which means ‘245 enable’ is also works fine.
DO I NEED TO DO ANYTHING WITH L_DD11?? (Of course I tried ‘./uisp’ by setting the L_DD11 once to ‘out clear’ and again to ‘out set’, but no luck)
I wrote a test program to write and read some text through ttyS2. That too works fine which means signals/paths upto UARTS pins 1 & 5 are fine.
I can check for clock etc. But I would like to kow if I missed out anything.
Can any one please suggest me what I need to do to fix the issue?
Highly appreciate any help.
Thanks
vnalla

[Shane Kirkbride]

Hi,
I'm working with some futaba S3004 servos using the servo program.
 The servos don't seem to settle...they shake back and forth and only
stop if I put my hand on them...does any one know how to fix this?
Also the values which work with the servo program are much smaller
(like between 0-100) than the recommended values. Thanks.
~Shane

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Dave Hylands]

Hi vnalla,

> I have two boards, Robostix and Roboaudio-Th and I have a question on
> Roboaudio board.
> I followed the directions on
> "http://docwiki.gumstix.org/Robostix_gumstix_ISP" to program the Robostix
> from the Gumstix running version 1161. Every thing works fine with Robostix.
> I have problem with Roboaudio: I am able play audio using the Roboaudio. But
> when I follow the same procedure to program the Atmel chip, I get "Probably
> the AVR MCU is not in the RESET state" message. I used the same mother
> board, jumper cable (which connects Atmel 0 Tx to PXA ST Rx and Atmel 0 Rx
> to PXA ST Tx) etc. to reduce the ambiguities.
> L_DD12, L_DD14, L_DD15 are the only control signals (in my opinion) required
> from Gumstix. I have done the following to make sure the Atmel gets the
> correct control signals:
> I have shorted the pins 1&2 of U$59 and U$60 to make sure the Atmel gets the
> VCC5 with out doubt and I confirmed the same.
> I soldered a small wire to pin 20 (reset) of Atmel to measure the state. It
> goes high when GPIO73 is set high and goes low when GPIO73 is set low. So
> reset works fine.
> I lost console communication when GPIO72 is set high which means '245
> enable' is also works fine.
> DO I NEED TO DO ANYTHING WITH L_DD11?? (Of course I tried './uisp' by
> setting the L_DD11 once to 'out clear' and again to 'out set', but no luck)
> I wrote a test program to write and read some text through ttyS2. That too
> works fine which means signals/paths upto UARTS pins 1 & 5 are fine.
> I can check for clock etc. But I would like to kow if I missed out anything.
> Can any one please suggest me what I need to do to fix the issue?
> Highly appreciate any help.

If the fuses got messed up, then it possible that the ATMega128 is in
a mode where it needs an external clock to be provided.

If you search gmane for "external clock" you'll find a bunch of threads.
Heres' one:
<http://article.gmane.org/gmane.linux.distributions.gumstix.general/25892/match=external+clock>

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Dave Hylands]

Hi Shane,

> I'm working with some futaba S3004 servos using the servo program.
>  The servos don't seem to settle...they shake back and forth and only
> stop if I put my hand on them...does any one know how to fix this?
> Also the values which work with the servo program are much smaller
> (like between 0-100) than the recommended values. Thanks.

That seems weird.

Did you set the fuses up? By default the ATMega128 runs at 1 MHz. The
servo program is expecting the fuses to be set to use the external
crystal - which runs it at 16 MHz.

Running at 1 MHz would cause the behaviour you're seeing.

1500 / 16 = 93.75.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[vnalla]

Thanks Dave,
I will look into the fuses. Now I need to look for external clock source.
vnalla

Dave Hylands <dhylands@...> wrote:

Hi vnalla,

> I have two boards, Robostix and Roboaudio-Th and I have a question on
> Roboaudio board.
> I followed the directions on
> "http://docwiki.gumstix.org/Robostix_gumstix_ISP" to program the Robostix
> from the Gumstix running version 1161. Every thing works fine with Robostix.
> I have problem with Roboaudio: I am able play audio using the Roboaudio. But
> when I follow the same procedure to program the Atmel chip, I get "Probably
> the AVR MCU is not in the RESET state" message. I used the same mother
> board, jumper cable (which connects Atmel 0 Tx to PXA ST Rx and Atmel 0 Rx
> to PXA ST Tx) etc. to reduce the ambiguities.
> L_DD12, L_DD14, L_DD15 are the only control signals (in my opinion) required
> from Gumstix. I have done the following to make sure the Atmel gets the
> correct control signals:
> I have shorted the pins 1&2 of U$59 and U$60 to make sure the Atmel gets the
> VCC5 with out doubt and I confirmed the same.
> I soldered a small wire to pin 20 (reset) of Atmel to measure the state. It
> goes high when GPIO73 is set high and goes low when GPIO73 is set low. So
> reset works fine.
> I lost console communication when GPIO72 is set high which means '245
> enable' is also works fine.
> DO I NEED TO DO ANYTHING WITH L_DD11?? (Of course I tried './uisp' by
> setting the L_DD11 once to 'out clear' and again to 'out set', but no luck)
> I wrote a test program to write and read some text through ttyS2. That too
> works fine which means signals/paths upto UARTS pins 1 & 5 are fine.
> I can check for clock etc. But I would like to kow if I missed out anything.
> Can any one please suggest me what I need to do to fix the issue?
> Highly appreciate any help.

If the fuses got messed up, then it possible that the ATMega128 is in
a mode where it needs an external clock to be provided.

If you search gmane for "external clock" you'll find a bunch of threads.
Heres' one:


--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Shane Kirkbride]

that was the problem...I forgot to set the clock...also, thanks for
that bit of info
i2c-load 0x0b run fixes the problem every time!
~Shane
On Thu, 10 Jul 2008 13:30:49 -0700
  "Dave Hylands" <dhylands@...> wrote:

> Hi Shane,
>
>> I'm working with some futaba S3004 servos using the servo program.
>>  The servos don't seem to settle...they shake back and forth and
>>only
>> stop if I put my hand on them...does any one know how to fix this?
>> Also the values which work with the servo program are much smaller
>> (like between 0-100) than the recommended values. Thanks.
>
> That seems weird.
>
> Did you set the fuses up? By default the ATMega128 runs at 1 MHz.
>The
> servo program is expecting the fuses to be set to use the external
> crystal - which runs it at 16 MHz.
>
> Running at 1 MHz would cause the behaviour you're seeing.
>
> 1500 / 16 = 93.75.
>
> --
> Dave Hylands
> Vancouver, BC, Canada
> http://www.DaveHylands.com/
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source
>project,
> along with a healthy diet, reduces your potential for chronic
>lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[vnalla]

Hi Dave,
You are awesome. It was indeed related to fuses. The issue is now fixed. I do not have any programmer as I have been using gumstix to program Atmega.  Here is what I have done for the benefit of others:
Since I have two boards with Atmega128, I just took 16 MHz clock from the working board and fed to the faulty one. (Shorted Atmega-pin24 of both boards). After that the ‘UISP’ found the Atmega.

Now, I have one more problem related to MMC/microSD
I have two mother boards,
- connex with MMC card (version 1161)
- Verdex with microSD (version 318M)
Both systems detect the cards on boot. I can un-mount and mount and any number times as long as I do not take the card physically out of the slot and list the contents.
But if I remove the card from slot after un-mount, the mount fails.
Here is the console output:
Case I: Connex with MMC card
Case II: Verdex with microSD card
CASE I:
# cat /etc/gumstix-release
DISTRIB_ID='gumstix'
DISTRIB_DESCRIPTION=''
DISTRIB_RELEASE='1161'
DISTRIB_CODENAME=''
BUILD_DATE='Mon Nov 6 11:20:28 PST 2006'
BUILD_HOSTNAME='azazel.hughes-family.org'
#
# ls /mnt/mmc/
OldSongs
#
# umount /mnt/mmc/
# ls /mnt/mmc/
#
==========The MMC card is left in the slot =============
# mount /mnt/mmc/
# ls /mnt/mmc/
OldSongs
#
# umount /mnt/mmc/
# ls /mnt/mmc/
#
==========The MMC card is taken out from the slot=========
# mount /mnt/mmc/
mmcblk0: error 1 sending read/write command
end_request: I/O error, dev mmcblk0, sector 32
FAT: unable to read boot sector
mount: Mounting /dev/mmcblk0p1 on /mnt/mmc failed: Input/output error
#
CASE II:
==========Now the micrlSD card with VERDEX board ============

root@gumstix-custom-verdex:~$
root@gumstix-custom-verdex:~$ cat /etc/gumstix-version
Revision 318M
Built on Tue Jul  1 22:35:56 PDT 2008
Build machine: west-l-cp-angu2.residential.local
Target machine: gumstix-custom-verdex
libc: glibc
root@gumstix-custom-verdex:~$
root@gumstix-custom-verdex:~$
root@gumstix-custom-verdex:~$
root@gumstix-custom-verdex:~$ ls /mnt/card/
song.mp3
root@gumstix-custom-verdex:~$ umount /mnt/card/
==========The microSD card is left in the slot =============
root@gumstix-custom-verdex:~$ ls /mnt/card/
root@gumstix-custom-verdex:~$
root@gumstix-custom-verdex:~$ mount /mnt/card/
root@gumstix-custom-verdex:~$ ls /mnt/card/
song.mp3
root@gumstix-custom-verdex:~$ umount /mnt/card/
==========The microSD card is taken out from the slot =============
root@gumstix-custom-verdex:~$ mount /mnt/card/
mmcblk0: error 1 sending read/write command
end_request: I/O error, dev mmcblk0, sector 8192
Buffer I/O error on device mmcblk0p1, logical block 0
mmcblk0: error 1 sending read/write command
end_request: I/O error, dev mmcblk0, sector 8200
Buffer I/O error on device mmcblk0p1, logical block 1
mmcblk0: error 1 sending read/write command
end_request: I/O error, dev mmcblk0, sector 8208
Buffer I/O error on device mmcblk0p1, logical block 2
mmcblk0: error 1 sending read/write command
end_request: I/O error, dev mmcblk0, sector 8216
Buffer I/O error on device mmcblk0p1, logical block 3
mmcblk0: error 1 sending read/write command
end_request: I/O error, dev mmcblk0, sector 8192
Buffer I/O error on device mmcblk0p1, logical block 0
mmcblk0: error 1 sending read/write command
end_request: I/O error, dev mmcblk0, sector 8256
Buffer I/O error on device mmcblk0p1, logical block 8
mmcblk0: error 1 sending read/write command
end_request: I/O error, dev mmcblk0, sector 8256
Buffer I/O error on device mmcblk0p1, logical block 8
/dev/mmcblk0p1: Input/output error
mmcblk0: error 1 sending read/write command
end_request: I/O error, dev mmcblk0, sector 8192
FAT: unable to read boot sector
mount: /dev/mmcblk0p1: can't read superblock
root@gumstix-custom-verdex:~$


Please advise what what needs to be done to fix the issue
Thanks
vnalla

Shane Kirkbride wrote:

that was the problem...I forgot to set the clock...also, thanks for
that bit of info
i2c-load 0x0b run fixes the problem every time!
~Shane
On Thu, 10 Jul 2008 13:30:49 -0700
  "Dave Hylands" <[e-mail]> wrote:
> Hi Shane,
>
>> I'm working with some futaba S3004 servos using the servo program.
>>  The servos don't seem to settle...they shake back and forth and
>>only
>> stop if I put my hand on them...does any one know how to fix this?
>> Also the values which work with the servo program are much smaller
>> (like between 0-100) than the recommended values. Thanks.
>
> That seems weird.
>
> Did you set the fuses up? By default the ATMega128 runs at 1 MHz.
>The
> servo program is expecting the fuses to be set to use the external
> crystal - which runs it at 16 MHz.
>
> Running at 1 MHz would cause the behaviour you're seeing.
>
> 1500 / 16 = 93.75.
>
> --
> Dave Hylands
> Vancouver, BC, Canada
> http://www.DaveHylands.com/
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source
>project,
> along with a healthy diet, reduces your potential for chronic
>lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> gumstix-users mailing list
> [e-mail]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
gumstix-users mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Dave Hylands]

Hi vnalla,

> Now, I have one more problem related to MMC/microSD
> I have two mother boards,
> - connex with MMC card (version 1161)
> - Verdex with microSD (version 318M)
> Both systems detect the cards on boot. I can un-mount and mount and any
> number times as long as I do not take the card physically out of the slot
> and list the contents.
> But if I remove the card from slot after un-mount, the mount fails.

I believe that this is a long-standing problem. I haven't heard of any
solution for it.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[vnalla]

Thanks for the update, Dave
vnalla

Dave Hylands wrote:

Hi vnalla,

> Now, I have one more problem related to MMC/microSD
> I have two mother boards,
> - connex with MMC card (version 1161)
> - Verdex with microSD (version 318M)
> Both systems detect the cards on boot. I can un-mount and mount and any
> number times as long as I do not take the card physically out of the slot
> and list the contents.
> But if I remove the card from slot after un-mount, the mount fails.

I believe that this is a long-standing problem. I haven't heard of any
solution for it.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gumstix-users mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Novicaine]

Dave Hylands wrote:

Hi vnalla,

> Now, I have one more problem related to MMC/microSD
> I have two mother boards,
> - connex with MMC card (version 1161)
> - Verdex with microSD (version 318M)
> Both systems detect the cards on boot. I can un-mount and mount and any
> number times as long as I do not take the card physically out of the slot
> and list the contents.
> But if I remove the card from slot after un-mount, the mount fails.

I believe that this is a long-standing problem. I haven't heard of any
solution for it.

Did anyone ever find a solution for this?  I am having the exact same problem, although on a different platform. (Once I physically remove the card, the next insert/mount fails with the same error as vnalla described.)

I would love to find a solution... Thanks!!