Hello SAM7 Group,
I got the USB to work via the CDC Serial port emulation.
When I connect, it maps in as the next available COM port.
In my case, it maps as COM3.
If I ever unplug or stop my program for a recompile, I lose the COM3
link and must exit the Terminal program and re-enter the terminal
program to have it find COM3 again.
This is only half of my problem.
The other half is I'm not sure how to get my program in the SAM7S64 to
properly reconnect without a full reset of the chip.
If I simply unplug, I'm not sure what register sets to use to monitor
this other than just looking at the USB power pin.
Any tips or suggestions on how the reconnect can be done so that COM
programs don't have to exit and restart and how to avoid resets of the
ARM chip?
USB - Reconnect process after disconnect/ halt
Started by ●November 26, 2005
Reply by ●November 26, 20052005-11-26
Which CDC code are you using? I wrote the one that I think is included
with
FreeRTOS now. I don't think there *is* a way to not have to disconnect from
the COM port, at least not with the standard CDC driver. You could probably
cause a disconnect event so that the terminal program automatically releases
the COM port. It's been awhile since I messed with it, though.
As for reconnecting when the SAM7S restarts, I always set up my startup code
to force a disconnect for a few seconds (through the USB pull-up control)
before reconnecting. If the SAM7S never resets the bus, the host doesn't
know what's happened and it won't go through enumeration again.
If you're using the FreeRTOS code, let me know and I'll find the reset code
I'm using. If you're using Atmel's, then you're on your own. I really
didn't like how that one was put together, and it wasn't well suited to a
multitasking environment if I remember right.
Scott
> -----Original Message-----
> From: AT91SAM7@AT91...
> [mailto:AT91SAM7@AT91...] On Behalf Of vt_snapshot
> Sent: Saturday, November 26, 2005 4:18 PM
> To: AT91SAM7@AT91...
> Subject: [AT91SAM7] USB - Reconnect process after disconnect/ halt
>
> Hello SAM7 Group,
>
> I got the USB to work via the CDC Serial port emulation.
> When I connect, it maps in as the next available COM port.
> In my case, it maps as COM3.
> If I ever unplug or stop my program for a recompile, I lose the COM3
> link and must exit the Terminal program and re-enter the terminal
> program to have it find COM3 again.
>
> This is only half of my problem.
> The other half is I'm not sure how to get my program in the SAM7S64 to
> properly reconnect without a full reset of the chip.
>
> If I simply unplug, I'm not sure what register sets to use to monitor
> this other than just looking at the USB power pin.
>
> Any tips or suggestions on how the reconnect can be done so that COM
> programs don't have to exit and restart and how to avoid resets of the
> ARM chip? > ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Get fast access to your favorite Yahoo! Groups. Make Yahoo!
> your home page
> http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/dN_tlB/TM
> --------------------------
> ------~- > Yahoo! Groups Links
FreeRTOS now. I don't think there *is* a way to not have to disconnect from
the COM port, at least not with the standard CDC driver. You could probably
cause a disconnect event so that the terminal program automatically releases
the COM port. It's been awhile since I messed with it, though.
As for reconnecting when the SAM7S restarts, I always set up my startup code
to force a disconnect for a few seconds (through the USB pull-up control)
before reconnecting. If the SAM7S never resets the bus, the host doesn't
know what's happened and it won't go through enumeration again.
If you're using the FreeRTOS code, let me know and I'll find the reset code
I'm using. If you're using Atmel's, then you're on your own. I really
didn't like how that one was put together, and it wasn't well suited to a
multitasking environment if I remember right.
Scott
> -----Original Message-----
> From: AT91SAM7@AT91...
> [mailto:AT91SAM7@AT91...] On Behalf Of vt_snapshot
> Sent: Saturday, November 26, 2005 4:18 PM
> To: AT91SAM7@AT91...
> Subject: [AT91SAM7] USB - Reconnect process after disconnect/ halt
>
> Hello SAM7 Group,
>
> I got the USB to work via the CDC Serial port emulation.
> When I connect, it maps in as the next available COM port.
> In my case, it maps as COM3.
> If I ever unplug or stop my program for a recompile, I lose the COM3
> link and must exit the Terminal program and re-enter the terminal
> program to have it find COM3 again.
>
> This is only half of my problem.
> The other half is I'm not sure how to get my program in the SAM7S64 to
> properly reconnect without a full reset of the chip.
>
> If I simply unplug, I'm not sure what register sets to use to monitor
> this other than just looking at the USB power pin.
>
> Any tips or suggestions on how the reconnect can be done so that COM
> programs don't have to exit and restart and how to avoid resets of the
> ARM chip? > ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Get fast access to your favorite Yahoo! Groups. Make Yahoo!
> your home page
> http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/dN_tlB/TM
> --------------------------
> ------~- > Yahoo! Groups Links
Reply by ●November 27, 20052005-11-27
Hi Scott,
I am using a derivative of Atmel's Basic USB code.
I agree that it was very limited in how it was set up.
I found where I needed to add checking for USB power / connect events
as well as some exit methods from some of their never ending loops.
Pulsing the pullup resistor was the solution I found after posting
that last message to help with reconnect.
So I've solved half of my problem but as you said, I'm not sure there
is a good solution for some of these Terminal programs to re-connect
once they think that a COM port is no longer there.
I will take a further look through your FreeRTOS and see if I can
adapt to some of the USB routines. My first ARM application can't
justify the full RTOS but I'm sure it will become handy at some point
down the road on other projects.
It looks like a great program and is well documented.
My PC application will be running under the LabView programming
language. It's a great language for graphs, data processing and
control systems.
--- In AT91SAM7@AT91..., <scott@o...> wrote:
>
> Which CDC code are you using? I wrote the one that I think is
included with
> FreeRTOS now. I don't think there *is* a way to not have to
disconnect from
> the COM port, at least not with the standard CDC driver. You could
probably
> cause a disconnect event so that the terminal program automatically
releases
> the COM port. It's been awhile since I messed with it, though.
>
> As for reconnecting when the SAM7S restarts, I always set up my
startup code
> to force a disconnect for a few seconds (through the USB pull-up
control)
> before reconnecting. If the SAM7S never resets the bus, the host
doesn't
> know what's happened and it won't go through enumeration again.
>
> If you're using the FreeRTOS code, let me know and I'll find the
reset code
> I'm using. If you're using Atmel's, then you're on your own. I
really
> didn't like how that one was put together, and it wasn't well
suited to a
> multitasking environment if I remember right.
>
> Scott
>
I am using a derivative of Atmel's Basic USB code.
I agree that it was very limited in how it was set up.
I found where I needed to add checking for USB power / connect events
as well as some exit methods from some of their never ending loops.
Pulsing the pullup resistor was the solution I found after posting
that last message to help with reconnect.
So I've solved half of my problem but as you said, I'm not sure there
is a good solution for some of these Terminal programs to re-connect
once they think that a COM port is no longer there.
I will take a further look through your FreeRTOS and see if I can
adapt to some of the USB routines. My first ARM application can't
justify the full RTOS but I'm sure it will become handy at some point
down the road on other projects.
It looks like a great program and is well documented.
My PC application will be running under the LabView programming
language. It's a great language for graphs, data processing and
control systems.
--- In AT91SAM7@AT91..., <scott@o...> wrote:
>
> Which CDC code are you using? I wrote the one that I think is
included with
> FreeRTOS now. I don't think there *is* a way to not have to
disconnect from
> the COM port, at least not with the standard CDC driver. You could
probably
> cause a disconnect event so that the terminal program automatically
releases
> the COM port. It's been awhile since I messed with it, though.
>
> As for reconnecting when the SAM7S restarts, I always set up my
startup code
> to force a disconnect for a few seconds (through the USB pull-up
control)
> before reconnecting. If the SAM7S never resets the bus, the host
doesn't
> know what's happened and it won't go through enumeration again.
>
> If you're using the FreeRTOS code, let me know and I'll find the
reset code
> I'm using. If you're using Atmel's, then you're on your own. I
really
> didn't like how that one was put together, and it wasn't well
suited to a
> multitasking environment if I remember right.
>
> Scott
>
Reply by ●November 29, 20052005-11-29
Hi Scott,
I jumped in late on this thread.
I read you were after the project running under Crossworks CWARM.
I ported the project a little while ago to CWARM for the hell of it.
It worked great - wasn't much to it , really.
If you still need the project, send me an Email, and I'll zip it for you.
I have a client that extensively uses CP1201 (Si Labs), and it's same story with that
driver.
The terminal program I use crashes if you hot-unplug it.
The exception is Telix for DOS, that handles it (also COM3), but I've always been a big
fan of Telix.
(I hate the win version though)
About unplugging during COM, (don't quote me on this) AFAIK an UNPLUG event, and then a
PLUG/resume event, will need the whole enumeration process to restart (the end points are
reset)
and since WIN sees your COM process still running, it will not and can not give that
resource to
the LUN.
For example, with Mass Storage devices you can see that the driver (in device manager XP)
properties gives you the option to allow unplug while running, albeit reduced disk
performance
(caching is turned off).
I never tried whether that helps on XP.
I despise it myself too though, when you're forced to fire up the "safe HW removal"
_every_time
you want to unplug....
For my 802.11 I use Digimates, that have the ZD1201 chipset, and they too require safe HW
remove first, but that doesn't matter there, since they always stay connected. B rgds
Kris
>-----Original Message-----
>From: AT91SAM7@AT91... [mailto:AT91SAM7@AT91...] On Behalf Of
>vt_snapshot
>Sent: Sunday, 27 November 2005 3:24 PM
>To: AT91SAM7@AT91...
>Subject: [AT91SAM7] Re: USB - Reconnect process after disconnect/ halt
>
>Hi Scott,
>
>I am using a derivative of Atmel's Basic USB code.
>I agree that it was very limited in how it was set up.
>I found where I needed to add checking for USB power / connect events
>as well as some exit methods from some of their never ending loops.
>Pulsing the pullup resistor was the solution I found after posting
>that last message to help with reconnect.
>
>So I've solved half of my problem but as you said, I'm not sure there
>is a good solution for some of these Terminal programs to re-connect
>once they think that a COM port is no longer there.
>
>I will take a further look through your FreeRTOS and see if I can
>adapt to some of the USB routines. My first ARM application can't
>justify the full RTOS but I'm sure it will become handy at some point
>down the road on other projects.
>It looks like a great program and is well documented.
>
>My PC application will be running under the LabView programming
>language. It's a great language for graphs, data processing and
>control systems. >
>--- In AT91SAM7@AT91..., <scott@o...> wrote:
>>
>> Which CDC code are you using? I wrote the one that I think is
>included with
>> FreeRTOS now. I don't think there *is* a way to not have to
>disconnect from
>> the COM port, at least not with the standard CDC driver. You could
>probably
>> cause a disconnect event so that the terminal program automatically
>releases
>> the COM port. It's been awhile since I messed with it, though.
>>
>> As for reconnecting when the SAM7S restarts, I always set up my
>startup code
>> to force a disconnect for a few seconds (through the USB pull-up
>control)
>> before reconnecting. If the SAM7S never resets the bus, the host
>doesn't
>> know what's happened and it won't go through enumeration again.
>>
>> If you're using the FreeRTOS code, let me know and I'll find the
>reset code
>> I'm using. If you're using Atmel's, then you're on your own. I
>really
>> didn't like how that one was put together, and it wasn't well
>suited to a
>> multitasking environment if I remember right.
>>
>> Scott
> >Yahoo! Groups Links >
>
I jumped in late on this thread.
I read you were after the project running under Crossworks CWARM.
I ported the project a little while ago to CWARM for the hell of it.
It worked great - wasn't much to it , really.
If you still need the project, send me an Email, and I'll zip it for you.
I have a client that extensively uses CP1201 (Si Labs), and it's same story with that
driver.
The terminal program I use crashes if you hot-unplug it.
The exception is Telix for DOS, that handles it (also COM3), but I've always been a big
fan of Telix.
(I hate the win version though)
About unplugging during COM, (don't quote me on this) AFAIK an UNPLUG event, and then a
PLUG/resume event, will need the whole enumeration process to restart (the end points are
reset)
and since WIN sees your COM process still running, it will not and can not give that
resource to
the LUN.
For example, with Mass Storage devices you can see that the driver (in device manager XP)
properties gives you the option to allow unplug while running, albeit reduced disk
performance
(caching is turned off).
I never tried whether that helps on XP.
I despise it myself too though, when you're forced to fire up the "safe HW removal"
_every_time
you want to unplug....
For my 802.11 I use Digimates, that have the ZD1201 chipset, and they too require safe HW
remove first, but that doesn't matter there, since they always stay connected. B rgds
Kris
>-----Original Message-----
>From: AT91SAM7@AT91... [mailto:AT91SAM7@AT91...] On Behalf Of
>vt_snapshot
>Sent: Sunday, 27 November 2005 3:24 PM
>To: AT91SAM7@AT91...
>Subject: [AT91SAM7] Re: USB - Reconnect process after disconnect/ halt
>
>Hi Scott,
>
>I am using a derivative of Atmel's Basic USB code.
>I agree that it was very limited in how it was set up.
>I found where I needed to add checking for USB power / connect events
>as well as some exit methods from some of their never ending loops.
>Pulsing the pullup resistor was the solution I found after posting
>that last message to help with reconnect.
>
>So I've solved half of my problem but as you said, I'm not sure there
>is a good solution for some of these Terminal programs to re-connect
>once they think that a COM port is no longer there.
>
>I will take a further look through your FreeRTOS and see if I can
>adapt to some of the USB routines. My first ARM application can't
>justify the full RTOS but I'm sure it will become handy at some point
>down the road on other projects.
>It looks like a great program and is well documented.
>
>My PC application will be running under the LabView programming
>language. It's a great language for graphs, data processing and
>control systems. >
>--- In AT91SAM7@AT91..., <scott@o...> wrote:
>>
>> Which CDC code are you using? I wrote the one that I think is
>included with
>> FreeRTOS now. I don't think there *is* a way to not have to
>disconnect from
>> the COM port, at least not with the standard CDC driver. You could
>probably
>> cause a disconnect event so that the terminal program automatically
>releases
>> the COM port. It's been awhile since I messed with it, though.
>>
>> As for reconnecting when the SAM7S restarts, I always set up my
>startup code
>> to force a disconnect for a few seconds (through the USB pull-up
>control)
>> before reconnecting. If the SAM7S never resets the bus, the host
>doesn't
>> know what's happened and it won't go through enumeration again.
>>
>> If you're using the FreeRTOS code, let me know and I'll find the
>reset code
>> I'm using. If you're using Atmel's, then you're on your own. I
>really
>> didn't like how that one was put together, and it wasn't well
>suited to a
>> multitasking environment if I remember right.
>>
>> Scott
> >Yahoo! Groups Links >
>
