USB OTG on ARM7 based MCU

Hello all.

I'm designing a system running on (ex Sharp) LH79520 NXP MCU with
ARM720T core. I'm currently adding USB OTG function but there is
something bothering me. By now, my system already has x32 SDRAM and
x16 FLASH memory. I've done a lot of research about OTG controllers
available on the market and picked NXP ISP1362 "Single-chip Universal
Serial Bus On-The-Go Controller". It's a memory mapped device (asks
for connection to x16 data bus already common to FLASH and SDRAM). In
the next few days I must add an additional Ethernet controller which
will probably also be a mapped device. All that has to go on double
layer PCB.

My question is: Is there any USB OTG controller IC (with transceiver)
but with SPI interface? I'm afraid I will not be able to route my PCB
with SDRAM, FLASH, USB and Ethernet all connected as memory mapped
devices.

Thank you !

On Dec 28, 2:42*pm, Mad I.D. <madi...@MOOOOVEyahoo.com> wrote:
> Hello all.
>
> I'm designing a system running on (ex Sharp) LH79520 NXP MCU with
> ARM720T core. I'm currently adding USB OTG function but there is
> something bothering me. By now, my system already has x32 SDRAM and
> x16 FLASH memory. I've done a lot of research about OTG controllers
> available on the market and picked NXP ISP1362 "Single-chip Universal
> Serial Bus On-The-Go Controller". It's a memory mapped device (asks
> for connection to x16 data bus already common to FLASH and SDRAM). In
> the next few days I must add an additional Ethernet controller which
> will probably also be a mapped device. All that has to go on double
> layer PCB.
>
> My question is: Is there any USB OTG controller IC (with transceiver)
> but with SPI interface? I'm afraid I will not be able to route my PCB
> with SDRAM, FLASH, USB and Ethernet all connected as memory mapped
> devices.

This may seem like a dumb idea, but I just read where NXP has a Cortex
M3 out with a USB OTG controller. You can use that chip as a
controller and have it communicate by any of several interfaces that
it supports. Although the binary may be different between the two
CPUs, you can use the same tools.

Rick

On Sun, 28 Dec 2008 14:25:19 -0800 (PST), rickman <> wrote:

>On Dec 28, 2:42*pm, Mad I.D. <madi...@MOOOOVEyahoo.com> wrote:
>> Hello all.
>>
>> I'm designing a system running on (ex Sharp) LH79520 NXP MCU with
>> ARM720T core. I'm currently adding USB OTG function but there is
>> something bothering me. By now, my system already has x32 SDRAM and
>> x16 FLASH memory. I've done a lot of research about OTG controllers
>> available on the market and picked NXP ISP1362 "Single-chip Universal
>> Serial Bus On-The-Go Controller". It's a memory mapped device (asks
>> for connection to x16 data bus already common to FLASH and SDRAM). In
>> the next few days I must add an additional Ethernet controller which
>> will probably also be a mapped device. All that has to go on double
>> layer PCB.
>>
>> My question is: Is there any USB OTG controller IC (with transceiver)
>> but with SPI interface? I'm afraid I will not be able to route my PCB
>> with SDRAM, FLASH, USB and Ethernet all connected as memory mapped
>> devices.
>
>This may seem like a dumb idea, but I just read where NXP has a Cortex
>M3 out with a USB OTG controller. You can use that chip as a
>controller and have it communicate by any of several interfaces that
>it supports. Although the binary may be different between the two
>CPUs, you can use the same tools.
>
>Rick

Why not use a CPU with onboard ethernet, USB etc.?

On Mon, 29 Dec 2008 09:50:57 +0000, Mike Harrison
>Why not use a CPU with onboard ethernet, USB etc.?

Because it should satisfy the following
- LCD Controller
- 32bit external BUS
- nonBGA package

LH79520 is the only chip on the market! There is NXP LPC2478 but it
has no cache so LCD doesn't work when CPU is executing from external
memory (picture disappears, not enough bandwidth). LH79520 runs on
ARM720T core with cache and MMU so cache eliminates that problem.

On Dec 29, 3:43*am, Mad I.D. <madi...@MOOOOVEyahoo.com> wrote:
> On Mon, 29 Dec 2008 09:50:57 +0000, Mike Harrison
>
> >Why not use a CPU with onboard ethernet, USB etc.?
>
> Because it should satisfy the following
> - LCD Controller
> - 32bit external BUS
> - nonBGA package
>
> LH79520 is the only chip on the market! There is NXP LPC2478 but it
> has no cache so LCD doesn't work when CPU is executing from external
> memory (picture disappears, not enough bandwidth). LH79520 runs on
> ARM720T core with cache and MMU so cache eliminates that problem.

I know both devices fairly well, the 2478 and the 79520. You are
correct that the 2478 does not have a cache, but it has a powerful
DMA. If you can't get the job done with the 2478, I can not imagine
you get it to work with the 79520, as the 2478 offers much better
overall bandwith to memories. The cache does NOT eliminate your
problem, unless you can execute ALL you code from cache and lock it
down, which seems difficult with 8KB cache size. The 2478 offers much
more SRAM, from which you execute same speed as directly from cache or
the flash which offers more than 90% execution speed compared to cache/
SRAM execution. On the 79520, the cache needs to be filled from
external memory as well, that can create strange effects to your
picture too.

I don't know whether you really tried it with a 2478, it seems by far
the best solution to your problem, unless you want to upgrade to an
ARM9

Der Schwob

On Mon, 29 Dec 2008 11:51:15 -0800 (PST), An Schwob in the USA
<> wrote:
>I don't know whether you really tried it with a 2478, it seems by far
>the best solution to your problem, unless you want to upgrade to an
>ARM9

Thank you very much for your answer. I've spent few days gathering
information about that particular controller and found this:
http://tech.groups.yahoo.com/group/l.../message/35811

It is the only reason I switched my design to LH79520. Cause of that,
right not I'm implementing Ethernet and USB OTG with external IC
controllers

On Mon, 29 Dec 2008 21:30:14 +0100, Mad I.D.
<> wrote:
/cut

Ohh, there are new replays there. Now I'm not sure could it work with
code executing only from external SDRAM ? LCD Frame buffer would be in
SDRAM to. Thank you.

If yes, I just spent 3 weeks with the wrong chip... (I'm a student
working alone on this)

On Mon, 29 Dec 2008 21:37:21 +0100, Mad I.D.
<> wrote:

>On Mon, 29 Dec 2008 21:30:14 +0100, Mad I.D.
><> wrote:
>/cut
>
>Ohh, there are new replays there. Now I'm not sure could it work with
>code executing only from external SDRAM ? LCD Frame buffer would be in
>SDRAM to. Thank you.
>
>If yes, I just spent 3 weeks with the wrong chip... (I'm a student
>working alone on this)

Sorry for 3 posts. Plus for LH79520 is a better core (720T with cache
+ MMU). With MMU present it is much easyer to drive a (better) RTOS.

Mad I.D. <> writes:

> On Mon, 29 Dec 2008 21:30:14 +0100, Mad I.D.
> <> wrote:
> /cut
>
> Ohh, there are new replays there. Now I'm not sure could it work with
> code executing only from external SDRAM ? LCD Frame buffer would be in
> SDRAM to. Thank you.

I was just about to suggest this (without knowing whether it actually
helps on that micro).

It is usual in systems with SDRAM to copy the program into it during
startup. SDRAM is usually faster than flash, with a wider bus, and is
very cheap.

So it could be that they can get away with poor performance when
executing from flash, since perhaps normally that would only be during
startup.

> If yes, I just spent 3 weeks with the wrong chip... (I'm a student
> working alone on this)

The 79520 is actually quite old now, for a chip of this type. I
started using it ~7 years ago. Its still a pretty useful device but I
would look very hard at the alternatives now becoming
available. Especially if they come with the other peripherals
built-in.

--

John Devereux

On Mon, 29 Dec 2008 20:51:35 +0000, John Devereux
<> wrote:
>It is usual in systems with SDRAM to copy the program into it during
>startup. SDRAM is usually faster than flash, with a wider bus, and is
>very cheap.
>So it could be that they can get away with poor performance when
>executing from flash, since perhaps normally that would only be during
>startup.

General idea with LH79520 is to use SD card as a "hard drive" for
program storage. Startup code would sit in FLASH and fill SDRAM with
program code and then remap controller to start executing from SDRAM.
My biggest concern right now is could LPC2478 drive a decant TFT
display with 60Hz refresh rate without flicker? I can't assume a thing
and lose time and money in the future.


>The 79520 is actually quite old now, for a chip of this type. I
>started using it ~7 years ago. Its still a pretty useful device but I
>would look very hard at the alternatives now becoming
>available. Especially if they come with the other peripherals
>built-in.

Believe me, LH79520 is THE ONLY AVAILABLE controller on the market
with needed features in nonBGA (double layer PCB limited) package. I
spent days doing research for suitable IC.