HI Kris,

I'll study over this info, and see what I can apply! I'm not up on all the
enumeration steps yet. But clearing the bank flag sounds a little familiar.
...Like it was a fix of some sort that I remember seeing.

Thanks!

Alan KM6VV

>
> Hi Alan,
>
> The 2 main bugs are/were these :
>
> 1. One of the endpoints was incorrectly initialised to ISO.
>
> 2. When a setup or ZLP packet is received, the EP0 (enumeration) handler
> simply returns.
> This is incorrect. A windows host during standard enum requests 0xFF
> config bytes, and then
> aborts this request. (Data IN stage has been stopped by a status OUT)
> After return, the BK0 flag is still set, thus resulting in continuous
> calls to the handler.
> With the polling code this is not so bad, but when you use INTs you get
> constant vectoring...
>
> handler. The simple solution is to always clear the BK0 & BK1 flag
> after RX of SETUP
> within the enumeration (EP0) handler :
>
> // Received a SETUP packet ?
> if (! (USB_CSR0 & USB_CSR0_RXSETUP) )
> {
> USB_CSR0 &= ~(USB_CSR0_RX_DATA_BK0+USB_CSR0_RX_DATA_BK1);
> return;
> }
>
> HTH
> Best Regards,
> Kris
>

Hi Alan,

The 2 main bugs are/were these :

1. One of the endpoints was incorrectly initialised to ISO.

2. When a setup or ZLP packet is received, the EP0 (enumeration) handler simply returns.
This is incorrect. A windows host during standard enum requests 0xFF config bytes, and then
aborts this request. (Data IN stage has been stopped by a status OUT)
After return, the BK0 flag is still set, thus resulting in continuous calls to the handler.
With the polling code this is not so bad, but when you use INTs you get constant vectoring...

handler. The simple solution is to always clear the BK0 & BK1 flag after RX of SETUP
within the enumeration (EP0) handler :

// Received a SETUP packet ?
if (! (USB_CSR0 & USB_CSR0_RXSETUP) )
{
USB_CSR0 &= ~(USB_CSR0_RX_DATA_BK0+USB_CSR0_RX_DATA_BK1);
return;
}

HTH
Best Regards,
Kris

________________________________________
From: A... [mailto:A...] On Behalf Of Alan KM6VV
Sent: Saturday, 16 June 2007 1:12 AM
To: A...
Subject: RE: [AT91SAM] GCC and AT91SAM7 USB CDC Core Example

Hi Kris,

Oh! "basic USB" project? If that's the same one I'm trying to get working,
then I'd be interested in knowing what was wrong with it!

Is this the "Endpoint Descriptor" you're talking about?

/* Endpoint 1 descriptor */
0x07, // bLength
0x05, // bDescriptorType
0x83, // bEndpointAddress, Endpoint 03 - IN
0x03, // bmAttributes INT
0x08, // wMaxPacketSize
0x00,
0xFF, // bInterval

>From the CDC_enumerate.c file (IAR compiler vers.).

I've yet to figure out the coding. I'm still downloading
usb_20_05122006.zip !

I'd certainly like to know what it takes to get it working.

Best Regards,

Alan KM6VV
P.S. Please keep it ON-LIST! I'd like to learn too!

>
> Judging from the dumb bugs (like having one of the EPs set for ISO among
> others) that were in the "basic USB" project, I'd expect anything.
> My reference "your code" wasn't meant literal of course, if it's CORE
> problem "your code" is > Atmel's of course.
> I haven't tried this frame work yet. I might consider poking around with
> it too. I haven't played with HID yet, must do this at some stage.
> Perhaps we could take this off list in the very near future, and I'd see
> if I can help / learn
> some more myself.
>
> Best Regards,
> Kris

Hi Kris,

Oh! "basic USB" project? If that's the same one I'm trying to get working,
then I'd be interested in knowing what was wrong with it!

Is this the "Endpoint Descriptor" you're talking about?

/* Endpoint 1 descriptor */
0x07, // bLength
0x05, // bDescriptorType
0x83, // bEndpointAddress, Endpoint 03 - IN
0x03, // bmAttributes INT
0x08, // wMaxPacketSize
0x00,
0xFF, // bInterval

>From the CDC_enumerate.c file (IAR compiler vers.).

I've yet to figure out the coding. I'm still downloading
usb_20_05122006.zip !

I'd certainly like to know what it takes to get it working.

Best Regards,

Alan KM6VV
P.S. Please keep it ON-LIST! I'd like to learn too!
>
> Judging from the dumb bugs (like having one of the EPs set for ISO among
> others) that were in the "basic USB" project, I'd expect anything.
> My reference "your code" wasn't meant literal of course, if it's CORE
> problem "your code" is > Atmel's of course.
> I haven't tried this frame work yet. I might consider poking around with
> it too. I haven't played with HID yet, must do this at some stage.
> Perhaps we could take this off list in the very near future, and I'd see
> if I can help / learn
> some more myself.
>
> Best Regards,
> Kris

Microbit wrote:

> CWARM (Rowley) uses GCC as compiler, but it has a rich custom library
> with things like super fast floats, built in RTOS, and all sorts of
> INT and other intrinsics. I'll dig up the project and send it to you,
> but if you dont have CrossWorks for ARM, you might be stuck on ISR
> functions that Rowley include (like re-enable/re-disable INT inside
> from ISRs etc)... You might be able to create your own in ASM ? Which
> toolchain do you use ?

I'm using a GCC toolchain too, but I'd still like to see
what hoops you had to go through to make a working CORE.

I don't care if it uses the Framework or if it's the old
sample code reworked for interrupts, I just want to make
my USB comms reliable...

I haven't tried
> this frame work yet. I might consider poking around with it too. I
> haven't played with HID yet, must do this at some stage. Perhaps we
> could take this off list in the very near future, and I'd see if I
> can help / learn some more myself.

Sure. I happen to like the structure of the framework. It makes itself
clear once you realize that the guts are exactly the same source for
three examples, CDC, MSD, and HID.

There's just something goofy with the BK0/1 clearing and BULK OUT
endpoint handling code...

Cheers, Ralph

Microbit schrieb:

> I first had similar problems to yours, but found that it was all to do with how you handle :
> 1. Switching between BK0 and BK1, and when/how.
> 2. Keeping track of which BK to service in the foreground and when.
> 3. Timing the disable/enable interrupt (and doing it properly on ARM7 !) for the EP, since
> re-enabling the INT when the proper BKx has been serviced but NOT cleared, you will get a new
>
> interrupt, clobbering things with the BK switching sequence. Conversely, if you clear the BKx
> too early there is a chance that the Hub will just fill it up again with more data, as the SAM7
>
> will start responding with ACKs instead of NAKs. (I certainly came across this problem to
> account for).

Last night I got HID working with 2 interrupt EPs. The reason were the
debug printf in the code, esp. in the EP handler.
Now it works (at least for 1 byte reports).
--
42Bastian

No probs Ralph. I know what it's like to be there but not really just there :-)
You would have read that I spent like 3 days flat trying to figure out why interrupt pipes
didnt work properly.
Unfortunately I'm not a PC guy, wouldn't know the first thing about writing drivers, and I dont
want to know. The consensus seemed to be that usbser.sys is broken, and to use a commercial driver
toolkit or some such. Bit too much of a learning curve for me.

CWARM (Rowley) uses GCC as compiler, but it has a rich custom library with things like super fast
floats, built in RTOS, and all sorts of INT and other intrinsics.
I'll dig up the project and send it to you, but if you dont have CrossWorks for ARM, you might be
stuck on ISR functions that Rowley include (like re-enable/re-disable INT inside from ISRs etc)...
You might be able to create your own in ASM ? Which toolchain do you use ?

> I agree. And you'd think that the folks at ATMEL would have got
> this part of it right in the firmware for the CORE, yes?

Judging from the dumb bugs (like having one of the EPs set for ISO among others) that were in the
"basic USB" project, I'd expect anything.
My reference "your code" wasn't meant literal of course, if it's CORE problem "your code" is
Atmel's of course.
I haven't tried this frame work yet. I might consider poking around with it too. I haven't played
with HID yet, must do this at some stage.
Perhaps we could take this off list in the very near future, and I'd see if I can help / learn
some more myself.

Best Regards,
Kris

-----Original Message-----
From: A... [mailto:A...] On Behalf Of Ralph Hempel
Sent: Thursday, 14 June 2007 3:59 AM
To: A...
Subject: Re: [AT91SAM] GCC and AT91SAM7 USB CDC Core Example

Microbit wrote:
> Hi Ralph,
>
>> The Framework works quite well, except for the BULK-OUT endpoint
>> losing data. I can't seem to figure out if the problem is to do
>> with usbser.sys on Windows sending more data than the endpoint can
>> accept,
>
> I doubt that very much. I know that usbser.sys doesnt work properly
> for interrupt pipes, but it definitely would not send more than the
> specified EP size from the enum.

I was hoping you would see this post and answer as I've been following
your discussions on the at91.com site...

>> or if there is an issue with the receive FIFO or the interrupt
>> handler.
>
> It's not silicon - it does work properly.. I think you will find it's
> your code somewhere.

I'm afraid that that's true too. I do occasionally make mistakes :-)

But still, the CORE code does appear to have a bug because even
if I strip out my app completely and just echo out what I get in
from the USB OUT endpoint, the data gets messed up...

> If I have time, I'll dig up my own interrupt driven version of CDC I
> wrote quite some time ago, a project on CrossWorks for ARM. If I find
> it I'll send you if you want for testing. I basically set it up for
> the SAM7-EK (changed S64 to S256) to work as a "UART bridge". RXd
> data from USB is sent out the serial, and Rxd data from the serial is
> sent out the USB. To test, I had 2 sessions of Hyperterminal running,
> one on COM2 and the other COMX (say COM5). I transferred 2-50 MB
> files via Z-modem in both directions numerous times, and not _once_
> did Z modem ever report a CRC32 error. Admittedly, the serial was
> only running at 115,200 but data flow worked perfectly.

I've read about this and was hoping I could get some sample code
from you..

> I first had similar problems to yours, but found that it was all to
> do with how you handle : 1. Switching between BK0 and BK1, and
> when/how. 2. Keeping track of which BK to service in the foreground
> and when. 3. Timing the disable/enable interrupt (and doing it
> properly on ARM7 !) for the EP, since re-enabling the INT when the
> proper BKx has been serviced but NOT cleared, you will get a new
>
> interrupt, clobbering things with the BK switching sequence.

Oooh. This last part looks/sounds interesting...

> Conversely, if you clear the BKx too early there is a chance that the
> Hub will just fill it up again with more data, as the SAM7
> will start responding with ACKs instead of NAKs. (I certainly came
> across this problem to account for).

I agree. And you'd think that the folks at ATMEL would have got
this part of it right in the firmware for the CORE, yes?

> I have a feeling you will find your solution will be somewhere around
> (3) above. Have a good look at INT & foreground interaction vis-vis
> BKx processing and _what_ should be in the foreground and what in the
> ISR...

Cheers, and thanks for the well-thought out reply...

Ralph

Yahoo! Groups Links

Microbit schrieb:
> I first had similar problems to yours, but found that it was all to do with how you handle :
> 1. Switching between BK0 and BK1, and when/how.
> 2. Keeping track of which BK to service in the foreground and when.
> 3. Timing the disable/enable interrupt (and doing it properly on ARM7 !) for the EP, since
> re-enabling the INT when the proper BKx has been serviced but NOT cleared, you will get a new
>
> interrupt, clobbering things with the BK switching sequence. Conversely, if you clear the BKx
> too early there is a chance that the Hub will just fill it up again with more data, as the SAM7
>
> will start responding with ACKs instead of NAKs. (I certainly came across this problem to
> account for).

It is not the CDC example only. I try to make custom HID (using
kadtronics library) using OUT interrupt EP and there I notice
similiar things. The first OUT packet works fine, but with the
second the interrupt does not get cleared and fires constantly even
though the PC is not sending anymore.

So it seems realy this is related to BK0/BK1 handling.

BTW: I use it on SAM9.

--
42Bastian

--- In A..., Ralph Hempel wrote:
>
> I've got the basic Framework ported to GCC 4.1.1 and would be
> willing to share the updated portions with the guy at winarm.com
> that posts updated projects..

I would be happy to host it at gnuarm.com as well if you are interested.

Hi Ralph,

Thanks, both for the promise to post the updated CDC, and for the subtitles!
(a link to translating Ham shorthand)

If/when I get my version of BASIC_USB (CDC) working, I'll post it as well.

Cheers!

Alan KM6VV

>
> I promise to post the updated CDC in a public place if I
> can get it to work with Kris's changes!
>
> Some of you that are having trouble with Alan's shorthand
> might benefit from this:
>
> :-)
>
> Cheers, Ralph
>

Hi Kris,

Yes, whatever is best. Ralph seems to be ahead of me! I didn't see the INF
in the files, but maybe I have one that I could edit. I recall one of the
BASIC_USB INF files thought it was a MODEM too!

Best regards,

Alan KM6VV
P.S. Sorry about the Ham-speak! I saw a call... (Ham call letters) But I
don't think even Hams REALLY know what 73 means (long ago lost it's origins.
Something like "Regards")!

>
> When I have a gap, I'll dig it up and post it "as is".
> I'm not on the right machine right now, it's at office.
> It needs cleaning up a bit - it's by no means a finished clean API doc'd
> project - but it's sound.
> It proves the silicon _and_ usbser.sys work properly wrt. EP OUT et al.
> Else we could do what Ralph suggests - I'll send it to him, see if it
> helps his problem and then
> post the possibly revised project.... ?
>
> I posted the INF I used on here a while ago. The main change was that I
> changed the GUIID so it
> comes up as an _actual_ Virtual COM port, instead of a bloody Modem in
> Device Manager :-)
>
> Best Regards,
> Kris