CrossWorks and USB Mass Storage problem

Hello Everyone,

I'm woking on the USB Mass Storage device for the AT91SAM7XC256. I use
the CrossWorks compiler and wanted to see if anyone else here has
already converted demo aplication from the Atmel GCC USB Framework (and/or similar) for CrossWorks or if someone has their own and will share it?
I lost one month of my life on it and it still isn'tworkning :-( .

Thanks,
Martin.

Ps: I have found the FreeRTOS CDC demo applicatin too, but it's only CDC
app. and i need Mass Storage.

Start a New Thread

Is it enumerating properly ?
I converted the original Atmel Mass Storage project to CrossWorks ages ago
and I recall I had to assign quite a bit of attributes (packed and/or
aligned) to the struct definitions for the Chapter 9 stuff.
I'm currently working on the uip/lwip project examples on CrossWorks,
converted from SAM9260-EK to Olimex SAM9-L9260 and it's the same story here
:
The ethernet header structs need to be attributed "packed" & "aligned", else
the "type" member points wrong. The strange thing is that Atmel claims
they're "GCC" projects : I don't think so !
I could try and set it up here to help you out but I don't use SAM7XC256.

Best Regards,
Kris

-----Original Message-----
From: A... [mailto:A...] On Behalf Of
x...@seznam.cz
Sent: Monday, 19 January 2009 7:55 PM
To: A...
Subject: [AT91SAM] CrossWorks and USB Mass Storage problem

Hello Everyone,

I'm woking on the USB Mass Storage device for the AT91SAM7XC256. I use
the CrossWorks compiler and wanted to see if anyone else here has
already converted demo aplication from the Atmel GCC USB Framework (and/or
similar) for CrossWorks or if someone has their own and will share it?
I lost one month of my life on it and it still isn'tworkning :-( .

Thanks,
Martin.

Ps: I have found the FreeRTOS CDC demo applicatin too, but it's only CDC
app. and i need Mass Storage.

Start a New Thread

Hi Kris,
thank You, for Your prompt reply.

> Is it enumerating properly ? <

I used the source file from Michael Wolf [1]. This example implements an USB mass storage based on Atmels USB MSD framework (enumerating method).
I modified the source to CrossWork IDE and changed AT91SAM7S128 to SAM7XC256 mcu [2]. I modified AT91SAM7_Startup.s file too, but it isn't working yet. What I'm doing wrong ? I guess that main problem is in AT91SAM7_Startup.s

>
I converted the original Atmel Mass Storage project to CrossWorks ages ago
and I recall I had to assign quite a bit of attributes (packed and/or
aligned) to the struct definitions for the Chapter 9 stuff.
<

Can You share it ? Especially how did You convert the Startup.s file ?

>
I'm currently working on the uip/lwip project examples on CrossWorks,
converted from SAM9260-EK to Olimex SAM9-L9260 and it's the same story here
:
The ethernet header structs need to be attributed "packed" & "aligned", else
the "type" member points wrong.
<

This could be a nightmare for mee :-).

>
The strange thing is that Atmel claims
they're "GCC" projects : I don't think so !
<

Yes, You are right !! The "GCC" AT91USBFramework-Core1.01, 1.02 and 1.4 is not GCC projects. (

>
I could try and set it up here to help you out but I don't use SAM7XC256.
<

Thanks a lot.

Regards Martin.

[1] Original source can be found here : http://www.mictronics.de/?page=arm_examples

[2] Copy of my modified source for the CrossWorks IDE : http://rapidshare.com/files/185954362/usb.zip.html

Start a New Thread

Kris
On a side note, I worked on getting ethernet running on the SAM9260
under FreeRTOS & CrossWorks a year or so ago. After banging my head
against a wall for over a week I realized that the shared memory used
for the ethernet buffers was cached so the CPU was not seeing NEW data
read into it by the ethernet controller. Turning off the data cache
cleared the problem. The project was abandoned by the client so was
never finished but I believe Richard might have the work-in-progress
available at FreeRTOS.org.

Regards
-Bill Knight
R O SoftWare
Microbit_P43000 wrote:
> Is it enumerating properly ?
> I converted the original Atmel Mass Storage project to CrossWorks ages ago
> and I recall I had to assign quite a bit of attributes (packed and/or
> aligned) to the struct definitions for the Chapter 9 stuff.
> I'm currently working on the uip/lwip project examples on CrossWorks,
> converted from SAM9260-EK to Olimex SAM9-L9260 and it's the same story here
> :
> The ethernet header structs need to be attributed "packed" & "aligned", else
> the "type" member points wrong. The strange thing is that Atmel claims
> they're "GCC" projects : I don't think so !
> I could try and set it up here to help you out but I don't use SAM7XC256.
>
> Best Regards,
> Kris
>
> -----Original Message-----
> From: A... [mailto:A...] On Behalf Of
> x...@seznam.cz
> Sent: Monday, 19 January 2009 7:55 PM
> To: A...
> Subject: [AT91SAM] CrossWorks and USB Mass Storage problem
>
> Hello Everyone,
>
> I'm woking on the USB Mass Storage device for the AT91SAM7XC256. I use
> the CrossWorks compiler and wanted to see if anyone else here has
> already converted demo aplication from the Atmel GCC USB Framework (and/or
> similar) for CrossWorks or if someone has their own and will share it?
> I lost one month of my life on it and it still isn'tworkning :-( .
>
> Thanks,
> Martin.
>
> Ps: I have found the FreeRTOS CDC demo applicatin too, but it's only CDC
> app. and i need Mass Storage.
>

Start a New Thread

Hi Bill,

In the interim I figured out the problem...
I had the AIC registers displayed in CrossWorks while debugging on a RAM
target, and as soon as these AIC regs are 'watched' the Interrupts stop
working !
I eventually reduced the whole saga into a simple "set a timer and roll the
INTs" micro project. After tearing my hear out for a day I pinned it down.
No wonder the EMAC/PHY stuff was going stupid.... Initially I would RX 1 or
2 (ARP) packets and that's it, needs a reset !! I knew something shifty was
going on with the INTs, but didn't see the trees through the forest...
I had changed the project to use KS8721 (Olimex) instead of DM9161 (Atmel
9260-EK) as PHY - so since one always defaults to self doubt, I thought
that's where I introduced problems. But nah, it's working a treat now.

Oh, and the code seems to quite happily chug away with caches enabled, I
don't seem to have that problem. Must be a FreeRTOS-specific snag ?
Certainly a pearl of wisdom to keep an eye on in the future. The 2.6.26.3
linux kernel
seems to quite happily use the caches as well. When I slapped thttpd on top
of Linux, I got a throughput of 1.7 MB/s, not bad considering it's all done
with high level socket signals and handlers thru the ABI.

I'm not sure now whether this is a silicon errata with 9260 or a JTAG/debug
issue on the GUI side. I suspect the first, not the latter.

Best Regards,
Kris

-----Original Message-----
From: A... [mailto:A...] On Behalf Of
Bill Knight
Sent: Tuesday, 20 January 2009 1:41 AM
To: A...
Subject: Re: [AT91SAM] CrossWorks and USB Mass Storage problem

Kris
On a side note, I worked on getting ethernet running on the SAM9260
under FreeRTOS & CrossWorks a year or so ago. After banging my head
against a wall for over a week I realized that the shared memory used
for the ethernet buffers was cached so the CPU was not seeing NEW data
read into it by the ethernet controller. Turning off the data cache
cleared the problem. The project was abandoned by the client so was
never finished but I believe Richard might have the work-in-progress
available at FreeRTOS.org.

Regards
-Bill Knight
R O SoftWare
Microbit_P43000 wrote:
> Is it enumerating properly ?
> I converted the original Atmel Mass Storage project to CrossWorks ages ago
> and I recall I had to assign quite a bit of attributes (packed and/or
> aligned) to the struct definitions for the Chapter 9 stuff.
> I'm currently working on the uip/lwip project examples on CrossWorks,
> converted from SAM9260-EK to Olimex SAM9-L9260 and it's the same story
here
> :
> The ethernet header structs need to be attributed "packed" & "aligned",
else
> the "type" member points wrong. The strange thing is that Atmel claims
> they're "GCC" projects : I don't think so !
> I could try and set it up here to help you out but I don't use SAM7XC256.
>
> Best Regards,
> Kris
>
> -----Original Message-----
> From: A... [mailto:A...] On Behalf
Of
> x...@seznam.cz
> Sent: Monday, 19 January 2009 7:55 PM
> To: A...
> Subject: [AT91SAM] CrossWorks and USB Mass Storage problem
>
> Hello Everyone,
>
> I'm woking on the USB Mass Storage device for the AT91SAM7XC256. I use
> the CrossWorks compiler and wanted to see if anyone else here has
> already converted demo aplication from the Atmel GCC USB Framework (and/or
> similar) for CrossWorks or if someone has their own and will share it?
> I lost one month of my life on it and it still isn'tworkning :-( .
>
> Thanks,
> Martin.
>
> Ps: I have found the FreeRTOS CDC demo applicatin too, but it's only CDC
> app. and i need Mass Storage.
>

Start a New Thread

Hi,

this is normal operation. You can switch the AIC to protected mode to
get rid of this problem. Check its documentation ;)

Foltos

Microbit_P43000 wrote:
>
> Hi Bill,
>
> In the interim I figured out the problem...
> I had the AIC registers displayed in CrossWorks while debugging on a RAM
> target, and as soon as these AIC regs are 'watched' the Interrupts stop
> working !
> I eventually reduced the whole saga into a simple "set a timer and
> roll the
> INTs" micro project. After tearing my hear out for a day I pinned it down.
> No wonder the EMAC/PHY stuff was going stupid.... Initially I would RX
> 1 or
> 2 (ARP) packets and that's it, needs a reset !! I knew something
> shifty was
> going on with the INTs, but didn't see the trees through the forest...
> I had changed the project to use KS8721 (Olimex) instead of DM9161 (Atmel
> 9260-EK) as PHY - so since one always defaults to self doubt, I thought
> that's where I introduced problems. But nah, it's working a treat now.
>
> Oh, and the code seems to quite happily chug away with caches enabled, I
> don't seem to have that problem. Must be a FreeRTOS-specific snag ?
> Certainly a pearl of wisdom to keep an eye on in the future. The 2.6.26.3
> linux kernel
> seems to quite happily use the caches as well. When I slapped thttpd
> on top
> of Linux, I got a throughput of 1.7 MB/s, not bad considering it's all
> done
> with high level socket signals and handlers thru the ABI.
>
> I'm not sure now whether this is a silicon errata with 9260 or a
> JTAG/debug
> issue on the GUI side. I suspect the first, not the latter.
>
> Best Regards,
> Kris
>
> -----Original Message-----
> From: AT91SAM@yahoogroups .com
> [mailto:AT91SAM@yahoogroups .com ]
> On Behalf Of
> Bill Knight
> Sent: Tuesday, 20 January 2009 1:41 AM
> To: AT91SAM@yahoogroups .com
> Subject: Re: [AT91SAM] CrossWorks and USB Mass Storage problem
>
> Kris
> On a side note, I worked on getting ethernet running on the SAM9260
> under FreeRTOS & CrossWorks a year or so ago. After banging my head
> against a wall for over a week I realized that the shared memory used
> for the ethernet buffers was cached so the CPU was not seeing NEW data
> read into it by the ethernet controller. Turning off the data cache
> cleared the problem. The project was abandoned by the client so was
> never finished but I believe Richard might have the work-in-progress
> available at FreeRTOS.org.
>
> Regards
> -Bill Knight
> R O SoftWare
>
> Microbit_P43000 wrote:
> > Is it enumerating properly ?
> > I converted the original Atmel Mass Storage project to CrossWorks
> ages ago
> > and I recall I had to assign quite a bit of attributes (packed and/or
> > aligned) to the struct definitions for the Chapter 9 stuff.
> > I'm currently working on the uip/lwip project examples on CrossWorks,
> > converted from SAM9260-EK to Olimex SAM9-L9260 and it's the same story
> here
> > :
> > The ethernet header structs need to be attributed "packed" & "aligned",
> else
> > the "type" member points wrong. The strange thing is that Atmel claims
> > they're "GCC" projects : I don't think so !
> > I could try and set it up here to help you out but I don't use
> SAM7XC256.
> >
> > Best Regards,
> > Kris
> >
> > -----Original Message-----
> > From: AT91SAM@yahoogroups .com
> [mailto:AT91SAM@yahoogroups .com ]
> On Behalf
> Of
> > xtyca@seznam. cz
> > Sent: Monday, 19 January 2009 7:55 PM
> > To: AT91SAM@yahoogroups .com
> > Subject: [AT91SAM] CrossWorks and USB Mass Storage problem
> >
> > Hello Everyone,
> >
> > I'm woking on the USB Mass Storage device for the AT91SAM7XC256. I use
> > the CrossWorks compiler and wanted to see if anyone else here has
> > already converted demo aplication from the Atmel GCC USB Framework
> (and/or
> > similar) for CrossWorks or if someone has their own and will share it?
> > I lost one month of my life on it and it still isn'tworkning :-( .
> >
> > Thanks,
> > Martin.
> >
> > Ps: I have found the FreeRTOS CDC demo applicatin too, but it's only CDC
> > app. and i need Mass Storage.
> > ------------ --------- --------- ------
>
> Yahoo! Groups Links
>
> Start a New Thread

Hi Bill/list,

I still had a follow up on this, languishing in the queue...

You were absolutely right, when I looked a bit deeper into the D cache
issue, indeed the frame traffic doesn''t run properly with data cache
enabled....

As part of a test in that project I had defined NO_CACHE_ENABLE within the
startup code itself (which in CrossWorks disables caching all together) at
some earlier stage and hadn't put it back to its default yet (which is an
enabled I & Dcache).
I normally do this externally in pre-processor, so I got punished there for
not defining it in the proper place .. :-)
After I had been looking into CP15, initially I had muddled up the A
(Alignment fault) and C (DCache enable/disable) bits in register c1. That
also caused me to believe my data cache was enabled when it wasn't.

I came to the conclusion that - for some reason I haven't figured out yet -
the problem is caused by the Receive Buffer Queue Pointer Register's frame
operation.
Moving buffers any 'ol way is fine with the cache, but *somehow* data dumped
by EMAC_RBQP doesn't constitute a dirty cache. That in turn causes failure
of new eth frames to be recognised.
Is this what you had too ? IOW not even a simple ARP query would get
through.

One of these days I'll have to dig around in the Linux source to see how
that is handled there (it should be using the EMAC fully AFAIK), because the
kernel config I use has D cache enabled, yet inet, all socket bizzo & the
likes works fine....

I haven't got this figured out 100% yet, but this is where I was at not too
long ago.

Best Regards,
Kris

-----Original Message-----
From: A... [mailto:A...] On Behalf Of
Bill Knight
Sent: Tuesday, 20 January 2009 1:41 AM
To: A...
Subject: Re: [AT91SAM] CrossWorks and USB Mass Storage problem

Kris
On a side note, I worked on getting ethernet running on the SAM9260
under FreeRTOS & CrossWorks a year or so ago. After banging my head
against a wall for over a week I realized that the shared memory used
for the ethernet buffers was cached so the CPU was not seeing NEW data
read into it by the ethernet controller. Turning off the data cache
cleared the problem. The project was abandoned by the client so was
never finished but I believe Richard might have the work-in-progress
available at FreeRTOS.org.

Regards
-Bill Knight
R O SoftWare

Start a New Thread

Kris
I got about as far along as you before the client canceled the
project. It is not uncommon for the cache not to be marked dirty when
updated by any peripheral - only CPU writes can do that. If/when you do
come up with the code to disable caching the region of memory used for
the ethernet buffers, I would definitely like to see how you did it. I
know it is documented somewhere but even after a few readings, I was
hoping to find how someone else did it before having to push through the
code myself. Guess I'm getting lazy in my old age.

-Bill Knight
R O SoftWare

Microbit_P43000 wrote:
> Hi Bill/list,
>
> I still had a follow up on this, languishing in the queue...
>
> You were absolutely right, when I looked a bit deeper into the D cache
> issue, indeed the frame traffic doesn''t run properly with data cache
> enabled....
>
> As part of a test in that project I had defined NO_CACHE_ENABLE within the
> startup code itself (which in CrossWorks disables caching all together) at
> some earlier stage and hadn't put it back to its default yet (which is an
> enabled I & Dcache).
> I normally do this externally in pre-processor, so I got punished there for
> not defining it in the proper place .. :-)
> After I had been looking into CP15, initially I had muddled up the A
> (Alignment fault) and C (DCache enable/disable) bits in register c1. That
> also caused me to believe my data cache was enabled when it wasn't.
>
> I came to the conclusion that - for some reason I haven't figured out yet -
> the problem is caused by the Receive Buffer Queue Pointer Register's frame
> operation.
> Moving buffers any 'ol way is fine with the cache, but *somehow* data dumped
> by EMAC_RBQP doesn't constitute a dirty cache. That in turn causes failure
> of new eth frames to be recognised.
> Is this what you had too ? IOW not even a simple ARP query would get
> through.
>
> One of these days I'll have to dig around in the Linux source to see how
> that is handled there (it should be using the EMAC fully AFAIK), because the
> kernel config I use has D cache enabled, yet inet, all socket bizzo & the
> likes works fine....
>
> I haven't got this figured out 100% yet, but this is where I was at not too
> long ago.
>
> Best Regards,
> Kris
>
> -----Original Message-----
> From: A... [mailto:A...] On Behalf Of
> Bill Knight
> Sent: Tuesday, 20 January 2009 1:41 AM
> To: A...
> Subject: Re: [AT91SAM] CrossWorks and USB Mass Storage problem
>
> Kris
> On a side note, I worked on getting ethernet running on the SAM9260
> under FreeRTOS & CrossWorks a year or so ago. After banging my head
> against a wall for over a week I realized that the shared memory used
> for the ethernet buffers was cached so the CPU was not seeing NEW data
> read into it by the ethernet controller. Turning off the data cache
> cleared the problem. The project was abandoned by the client so was
> never finished but I believe Richard might have the work-in-progress
> available at FreeRTOS.org.
>
> Regards
> -Bill Knight
> R O SoftWare

Start a New Thread