USB stops working at boot when S5PV210 warms up

Hi all,
I have three Tiny210 boards and all have the same problem with the USB
module not starting up when the S5PV210 IC is being warmed up to 40degC.
When in this condition I touch the S5PV210 IC directly with a finger the
USB starts up normally. If the IC is being cooled a little the USB starts
up normally too without any restarts or resets. 
I found out the heating is a problem, when I placed the board in the
equipment housing: at first it works fine, USB devices are being enumerated
normally, and after 10min of work restarting the power causes the USB
problem. Heating the ARM IC up directly using warm air rework station will
cause this problem too.  
I'm testing under WinCE7.0 and all other functions and peripherals are
working properly during these USB problems.

Has anyone encountered such a problem before?
Please, post any ideas for possible solutions, guys, thanks!

Darco

That sounds like an odd problem, I wonder if it's causing an issue with
board flexure when it heats up and exposing a poor solder joint on the
s5pv210 chip?  Have you checked the heat on other ICs?  What devices are
you plugging into the USB on the tiny210?

have you checked how the unit behaves using a different OS?  Other than
that, all I can really suggest is possibly thinking about reflowing the
s5pv210 chip with your rework station, if pressing on the s5p chip cures
the issue no matter how warm the IC is then this seems most likely fix.

Hi Reggie, 
Thanks for your prompt reply.
The problem occurs on two Friendly Arm DevKits too (we only have two here
in the lab), and the heating is really more like warming up, it's not a
high temperature,you can put your finger directly on the IC for a long
time. The devices I connect are of several kinds: AT43301 USB HUB IC, a
standard PC USB keyboard, USB mouse.
Never checked a different OS, I'm using the superboot flashed with
sdflasher supplied by FA.

About the reflowing, I'm only using the warm air (not HOT) to stream the
air flow on the IC, to isolate the problem. It's hardly resoldering
anything, and the problem ocurs on all 3 brand new boards. I guess it would
be a great coincidence if all three IC's have the same BGA pad unsoldered.
If so, then it's a mass production problem and other people should
experience it too.

About the "finger test", it's NOT pressing, but just touching the surface
very slightly. The effect is like the capacitive switch buttons, you don't
have to press in order to enable it.
I really feel it is a schematic HW problem, so I'm just asking what could
it be, since the kits have it too, not only our OEM board.  It seems I'm
enabling some level on some port that allows to USB to start up.

Darco

I forgot to tell, the USB stops starting up at boot only. If it manages to
start up normally at boot, no warming would stop it from working. In a
failed USB condition when resetting the ARM , the USB would start normally
too no matter how many resets being done. Our problem is restarting the
boards soon after being powered off, that's how I found out it is somewhat
temperature related. And it's not the power supply problem either (using
the dev kit power switch causes the same failure), we've done extensive
testing to focus on the source of the problem. 
So, the problem is not as simple as a cold junction.

How are all GPIO configured during boot-up?  Is there some port which is
"floating" rather than having a good "low" or "high" on it during boot?

Maybe, there are missing pull-ups or pull-downs to guarantee state during
this period.

> Our problem is restarting the
boards soon after being powered off

How long do you wait?

Thought I should look at the schematic for the Tiny210 and it appears that
there is a significant difference between it and the mini2440, as far as
establishing initial port conditions.  The mini2440 has many resistor packs
that ensure that a particular port is low or high.  I can't say if they
have missed any.

The Tiny210 board, or the specifically the S5PV210 chip must handle this
issue in a different manner.

Got a link to the full manual?

Good luck!

Hi davef,
It seems your guess is very close to the real source of the problem. We
never did add or remove anything from the tiny210, since we feel it should
be a complete solution and we're using the pins of the board connectors
only. Yesterday we tried enabling a PULLDOWN on the OC(overcurrent)
protection bit of the USB software driver, and the problem disappeared!
Even disabling the protection itself didn't work a few days ago. I'm still
not sure whether this OC exists on the IC pins or elsewhere on the tiny210,
but I'm sure it's not available at the board connectors, so it's a call the
the bootldr developer guys: please, keep ALL modules configured correctly
at boot, we don't have access to the boot loader source code. 
Anyway, davef , it's a really tough guess,you got it the closest, greetings
and thanks!
I used a 2440 in a previous project,NEVER had this problem, don't bother to
check!
Btw, restarting of power needed to be in the range of 10sec to make usb
fail. It's a matter of cooling down, I think.
 
One more thing: has anyone of you guys any idea how to get to the Superboot
source code? It's a fearsome experience to have no access to boot settings.

Darco

PS: link to the tiny sch is available on this website
too:http://www.friendlyarm.net/dl.php?file=tiny210_schematic.zip

Darco, Can you post the code you used to pulldown the OC bit? I don't have
this issue myself but someone else might need that information in the
future :)

Hi Reggie,
Here it is:  

{
    volatile PGPIO_REG pGPIO_regs = (volatile GPIO_REG
*)DrvLib_MapIoSpace(BASE_REG_PA_GPIO, sizeof(GPIO_REG), FALSE);
    if (pGPIO_regs == NULL)
    {
      RETAILMSG(TRUE, (TEXT("[EHCI] pGPIO_regs Register is *NOT*
mapped.\n")));
      return FALSE;
    }

   
pGPIO_regs->ETC2.ETC_PUD=(pGPIO_regs->ETC2.ETC_PUD&(~(3<<(2*7)))
)|(1<<(2*7));//Enable
PULL DOWN on USB overcurrent pin
    
    DrvLib_UnmapIoSpace((PVOID)pGPIO_regs);
  }


Btw, how about providing the source of the tiny210 bootloader and how do
you compile it? We would like to write a code which can flash the NK.bin
image from SD card directly in the tiny210 flash. It will ease image
updates very much, without using the menu keys each time!

> Btw, restarting of power needed to be in the range of 10sec to make usb
> fail. It's a matter of cooling down, I think.
 
More likely for some floating logic level to drop enough to place that port
in the opposite state.

Keep testing it though!

Hi davef,
The problem was solved the day before you posted the floating ports
suggestion. It's the OC bit which keeps the overcurrent protection ON for
some reason, and no code in the bsp pulls it down or up. We put it down and
it's ok now, tested well enough. I'm sure ANY tiny210 can proove this
experiment.
I have posted the source code in my previous post.

Darco

> It will ease image updates very much, without using the menu keys each
time!

If you want to update flash without pressing extra buttons, set
LCD-Mode = No
in FriendlyARM.ini

Hi Darco, which file should that code go into?

As for the bootloader, it's closed source, it's something I'd like to look
at too, then we could get something like uboot working with the nand.

I have had issues with the usb not resetting in the past but hadn't put it
down to a heat issue and on a mini210S not tiny210, they're the same chip,
so I wonder if they have a similar/same issue?

Hi Reggie,
It's here in the BSP tree: RC \ DRIVERS \ USB \ OHCI \ OHCIPDD \ OHCI.c 

static BOOL
InitializeOHCI(
        SOhcdPdd * pPddObject,        // IN - Pointer to PDD structure
        LPCWSTR szDriverRegKey)    // IN - Pointer to active registry key
string

The warming method is just a way to place the floating pin to some stable
state, touching a finger would do the same in the opposite direction, i.e.
pulling down the OC. I guess there are many other ways to drive the
floating level, f.e. strong EMI. I would suggest tidying up the drivers'
intialization AND pulling down the OC pin outside the CPU by a 4.7k for
instance.

Darco

Ahh yes, I forgot it was winCE you were doing this in, my issues were in
android/linux but the usb enumeration never made it on a reboot, so it
seems that this is potentially a hardware issue rather than an individual
OS issue.  Nice to see that it can be fixed with software either way.

This sounded a lot like latch up from delays in power supply between the
two chips. It looks like you solved it. I was going to suggest a pull-up in
a couple of places. It has solved similar problems for me before on
numerous devices that use CMOS.

Hi TheRegnirps,
Power supply delays was my first guess, but I found out there is no
relation in that, we did extensive testing with power-ups. USB module is a
part of the ARM IC, it's not outside, and no matter what USB device I
connect to outside the result is identical.
It is really a pull-x solution, it's just in software.

Darco

I've tried to add code into the mach-mini210.c code for linux/android
kernel but it doesn't appear to do anything, probably an issue in my code I
unashamedly lifted from a mango210 board linux source tree.

I have also looked at the mini210S schematic and the file shows a 15k
resistor to ground on the D+/D- lines but they are missing on both of my
boards, I've also looked for XuHostOVERCUR pin and it looks like it's NC,
however, I've read on the net that it should actually be tied to ground if
it's not used!!

Hi Reggie,
The 15k's are a must! But it doesn't help anyway :) I have them on the
D+-lines from the very beginning. 

Darco

Indeed, I don't have any 0603's here though :/  All I've got is 1206, I
guess I'll have to order some.

Hi Darco,

Thank you for your work on this.  
I have seen the exact issue you mention and had not sorted it out.

I've got one Tiny210 board here that exhibits this behaviour very
predictably so when I get some time in the next week or two I will try your
fix listed above and see if that solves it.

Hi BBBB,
Hope it works there too. Please, keep in touch and send your feedback about
the result.

Darco