AM3354: Host Babble connecting to a full speed device

Hi,
I'm not aware of anything that has changed, but I've forwarded your lot codes to our production team for comment.

I'll let you know what I find.

Thanks DK.

S

Steve,
Which USB port are you using?

DK,

This is USB1 Host port. The device is Full speed only.

Thx - Steve

Please provide the value of 0x47401B38 on both "passing" and "failing" processors. This can be done with 'devmem2 0x47401B38' at your command line.

If your daughter card supports hot-plug (USB attach in this case), I'd like to see the values before and after insertion. If not, don't worry about it and just provide the one value for each processor.

DK,

Below are some numbers via ‘devmem2 0x47401B38’. These are on examples of 3 series of devices I can find in house. I read the same value whether powering up connected or before/after hot-plug.

A new device that exhibits babbles, package/lot id 74C7Z6W
Read at address 0x47401B38 (0x4009fb38): 0x3E9F5450

An ‘older’ device does not exhibit babbles, package/lot id 55A9EOW
Read at address 0x47401B38 (0x400a7b38): 0x3F9F3E50

I believe this is the oldest device I have, no babble (2016?), package/lot id 51AHZSW
Read at address 0x47401B38 (0x400f2b38): 0x409F3F50

Steve

Thanks.

On the new device from lot '74C7Z6W', please write '3E9FD450' into offset 0x47401B38 and re-test.

'devmem2 0x47401b38 w 0x3e9fd450'

 

Please see below

Sorry...ignore what I wrote above. Write '3E9FB650' instead and retest.

'devmem2 0x47401b38 w 0x3E9FB650'

Got it. That will take me a little while to test.

Thanks DK.

DK,

Initial hot-plug tests w/your new values look promising, but hot-plug isn't easy with Production h/w. Normally that port is hard connected always & a clean hot-plug is tricky. It's not clear how I would test this for the normal boot. Modding that address in U-boot then boot doesn't work. After boot reading that address with devmem2 hangs the system. I'll have to figure out how to write this somewhere in the driver on the Linux side. Let me know any tips, but this looks good so far. Of course, this brings up many more questions...;-)

Thx - Steve

Hi Steve,
Any updates on this from your side?

DK,

Yes, we've done quite a bit of testing an it all looks good, both hot-plug and hard connected. I'll update an entry with much more detail & results shortly.

More to follow...

Thanks for the response - Steve

DK,

We have been able to test a few parts with the package lot ID you mentioned, along with about 3 other lots. The values read from location 0x47401B38 vary slightly across parts, but in general pretty similar. Although we’ve been unable to write to that address within the BSP files, we can after boot w/devmem2 for hot plug testing. For hard-connect testing, we are able to write to that address in U-boot and the result stick through boot (with some idiosyncrasies). The testing shows no babble after writing to that location, both with the device hard connected on power-up or hot-plug. I might guess that we’re trimming the part’s phy pulldown on the D+ line with the 2^nd byte value (B6), as I see the higher reset level during the USB speed test from about 110mv to 125mv, which then matches the ‘old’ parts. With the reset low level there, no startup babbles! I can give you more data if you’d like to see #’s or traces. I can basically plot the USB reset level per that byte value across parts predictably.

Writing in U-boot, though [appearing] successful, is somewhat problematic. After boot, doing a couple devmem2’s to read that address will hang the system. Otherwise, the system boots and our app runs fine (I’ll can provide some debug port output). It’s also not clear why we cannot write that offset in the build board setup files & before the USB driver is loaded. We can hang the system even with reads, but we’ll continue to dig there. Some questions:

-          Is there a reason why this is different on new parts? For example, does the current BSP do more with the USB phy on startup?

-          Can we change that 2nd byte value (ex. writing the 0x3E9FB650 to 0x47401B38) across parts without ramifications once booted and running? Test here look good, but this brings up a pile of production issues.

-          Are there other values in that reg loc that are relevant, dangerous, mandatory? It sure would be nice to find that documented.

Anyway, your tip was right on. Let me know if you’d like more details (traces, lot id's tested), and appreciate any more insight!

Thx for the help!

Steve

Hi Steve,

steve s said:

Writing in U-boot, though [appearing] successful, is somewhat problematic. After boot, doing a couple devmem2’s to read that address will hang the system.

The AM335x Errata #1.0.34 states that the sequence of

1. access USB PHY registers
2. USB subsystem soft reset
3. access USB PHY registers again

will lock up the whole system. But I am not sure if it is the issue in your case, as I don't think either U-Boot or kernel does usb subsystem soft reset.

steve s said:

It’s also not clear why we cannot write that offset in the build board setup files & before the USB driver is loaded. We can hang the system even with reads,

Generally when the driver is not loaded, the hardware module is not clocked, then accessing its register would hang the system (or access abort for some peripherals).

I think that makes sense and agree, that's probably what we're seeing with our testing.

Thanks for the info - Steve