STM32L476 USB inconsistencies.

[shingadaddy]

Posted on March 29, 2017 at 00:21

I've been working with USB on my Nucleo board(S)  for some time now. Been comfortably successful at getting a few operational interfaces working with it. Including DFU. STM32L476. So time to make our own PCBS! We knocked out an order for 10 . Production needing 7 and having a few SPARES to help wear off the new. Ran into a little problem and I turned in an online help request. Waited all day and thought maybe someone there might notice I marked it Critical. Not sure of the turnaround time but everybody's critical  might be a little different. Hope I hear and in the mean time here's where I got too.

We have 10 Brand new (Identical) PCB's with STM32L476VG's on them.

They use the direct connected USB for communication. (PA11/PA12)

They are *all* loaded with the same binary, VIA DFU.

DFU works. Dependably.

The binary is the STM32CubleL4 HAL DEMO from EVAL board, with IO EXPANDER commented out. This runs the LEDS on EVAL and is the only thing needed to be removed for this to work. I figure it works good as a TEST LOAD.

Operationally :

  7 Enumerate/seem to work.  ------  3 DO NOT even enumerate correctly.

Do not meaning: 2 -  with DEVICE NOT RECOGNIZED responses.  1 -  PC IGNORING COMPLETELY

I use VBUS DETECT. USB 5VDC is getting to PA9 on the one the is completely ignored.  

We have matched lines on the USB traces about .7 inches between the type C USB connector and the MICRO. Connectivity is direct via usb line suppressors (TI_SN65220DBVR). No inline resistors. No Pull up on D+.I am going to gather these up personally and look into it. But this is being tested by very capable individuals with years of experience and there does not seem to be a difference in the PCBS PHYSICALLY or SIGNAL WISE. The code that is running on them is the STM32CubeL4 USB in DEVICE MODE -CDC DEMO from the EVAL project in TrueStudio.

My immediate questions would be.

1. Suggestions such as the 'Oh yeah' type, as to what might be wrong?.

2. Since DFU mode works, (and 7 others) shouldn't the enumeration at least be functional on the operational testing?

3. Does DFU USE a different SPEED that is not as critical as USB FS.

4. Does the MSI trimmed with LSE, really provide precision/stability good enough for USB FS?

Crystal = Abracon ABS25-32.768KHZ-T

This is our first 10 in a production run and we are now a little nervous on the 70% operational aspect.

Power = CLEAN

OSC/Clock CLEAN

FDMOD set so FORCED DEVICE MODE is true.

Ground plane internally.

I had one nucleo dev board (Out of 5 or 6) that I used for a while until it acted like it had a heat sensitivity problem after some operational time. Then DEVICE NOT RECOGNIZED. On more than one computer. Unless I left it unplugged for about 30 minutes. Then BACK IN BUSINESS !   THAT is flakiness at its finest. And now I think - maybe we have more?

Just thought I'd drop this here too and see if anyone had any ideas. I really didn't think I had to get the LED out and chase it though the code (again) But here I am. Not amused at all.

Any input appreciated.

Thanks folks.

[Jan Waclawek]

Posted on March 29, 2017 at 07:12

DFU works. Dependably.

Sounds like SW problem in the application then.

How is stack/heap set up?

JW

[Kraal]

Posted on March 29, 2017 at 12:12

Hi,

Why did you choose the type C connectors for the USB ? I've read here and there that there is still some issues with type C cables and/or connectors. Are you trying to connect on a Gen 3 USB port ? Could you hack one of the faulty PCB to use a type B connector and connect it to a USB 2 port ? Just to see if this is the issue.

[shingadaddy]

Posted on March 29, 2017 at 16:05

Thanks folks

+1 on suspecting code.

Heap 3000

Stack 1000

Both doubled from the demo settings. All I seemed to read seemed to indicate a problem with this on F devices

but I bumped it here for the 'L' of it anyway.

Why C.

1. Goof proof. Not IDIOT proof. We test with highly proficient idiots that push, pull AND twist really hard.

2. Power capabilities. Not welding but charging batteries.

3. Future friendly. Apparently - best guess. Making it certainly wrong for some reason that's well hidden from me.

4. Bought what I believe are good quality cables. Belkin cables to test with. I read about 'the resistor'....

http://www.bestbuy.com/site/belkin-3-usb-3-1-type-a-to-usb-type-c-cable-black/9511001.p?skuId=9511001

7 Work. 3 Don't.

Yes I could hack a B type on. I hacked one onto Nucleo. But this would be a bit more challenging to my fine motor skills on our new PCB.

I went though and found where some folks were apparently trying to kick off transmissions on USB before the USB stuff was allowed enough time to SET UP and that was causing issues. Mine isn't that case. I never transmit anything to the PC unless I get an OUT ENDPOINT packet with a command to send something back. And I understand about the PC VCP driver constantly sending requests for IN ENDPOINT DATA. I believe the micro just NAKS those until it has something to send. I've not touched ENUMERATION code. That's still in ST magic form.

Getting the Eval CDC demo to run on Nucleo was easy once I got a nudge indicating that was the case, FROM ST!

Just remove the LED inits and some calls regarding LED on off control and you're in business. And yet - I have NO REPLY from ST with a critically marked online support request.

Cable/Connector on the edge?

Code on the edge?

I appreciate you guys replying. Any clues greatly appreciated also. It's just not looking good here. 

Thank you.

[shingadaddy]

Posted on March 29, 2017 at 16:57

Just to clarify -  I have 2 binaries

1. AS_IS BINARY - The Raw DEMO CODE from ST with the LED stuff removed. Loaded by DFU and used by TEST to confirm basic USB operation. THAT is what IS (7) and IS NOT (3)  WORKING. The TEST - Type on the terminal screen and see it echoed back.

2. APPLICATION BINARY -  That fits this - 'I never transmit anything to the PC unless I get an OUT ENDPOINT packet with a command to send something back. And I understand about the PC VCP driver constantly sending requests for IN ENDPOINT DATA. I believe the micro just NAKS those until it has something to send'. The TEST - (for now) any character sent on USB by HOST triggers a set collection of STUFF back to the PC.

I've wrote,  loaded and tested that APPLICATION BINARY here at my desk on Nucleo. Seems to work !   AND I've now given it to the folks TESTING the 10. And now we have:

7 that work. (The same 7)

3 that DON'T. (The same 3)

BUT! - The one that WAS completely ignored by the PC now says DEVICE NOT RECOGNIZED. And RE-Loaded with the RAW binary, it returns to COMPLETELY IGNORED.

I'm not sure how to take that.

There is some sort of convoluted ritual I 'll need to go through to get these from PRODUCTION to my desk. That might happen later today or tomorrow but I have full faith in the folks testing this.

As it happens...

[shingadaddy]

Posted on March 29, 2017 at 17:53

Those who might be reading and LEANING to the botched assembly side might be interested to know that:

1. Under a MANTIS, they look perfectly fine to us.

2. We didn't make the bare PCBS

3. We COULD but didn't obtain the parts

4. We COULD but didn't assemble them.

We use a little outfit in Colorado for that. They are DEAD ON with MFG 99.99% of the time. Like they seem to be with MANY customers for PCB work.

So yeah THIS specific PCB is a first build for them and us too but, if its a MFG issue, it is HIDDEN well...

[shingadaddy]

Posted on March 29, 2017 at 18:23

One last little tidbit. Remember I said I had been 'working with USB on my Nucleo Boards'.

I have about 8 Nucleo boards laying around. All the ones I used while getting this running, I used the ST LINK USB connection and then transitioned over to ONE NUCLEO BOARD with DIRECT USB to PA11 and PA12

And THAT board is the ONE that acted FLAKEY. And I THOUGHT that it was HEAT SENSITIVE. I have ANOTHER one now configured to use the direct USB and it hasn't failed YET! (2-3 weeks)

So Actually - Out of 12 PCBs (2 Nucleo - 10 rolled our own NEW) using the SAME example code on ALL of them

50% failed on Nucleo - Unexplained but thought to be heat sensitive ( I figure the crystal drifted.... maybe) 

30% failed on the NEW PCB

Just being more clear.....

I'm going to have to step away from the keyboard for a bit. Then maybe I'll copy some of this over to the ST online support area.

[shingadaddy]

Posted on March 29, 2017 at 20:38

DFU worked. Every time. I wasted COUNTESS hour as I was making S/W changes on that board. All due to it flaking  out after about an hour or two while I was developing code. And of course - I blamed MY code. And then there is always the PC in the mix too. The Window side of USB is a lot easier to confuse that one might think, and it requires a reboot to clear it .

And NOW - I see it happening with the raw demo code - less the LEDS. I don't consider that as 'my' code. It is to an extent (0.5% maybe) but that extent stops beyond a couple of things commented out regarding LEDS. And it THAT makes it flakey, it should be reproducible or traceable to some RACE or timing oddity.

Seems the 95% ownership should be *more better* equipped to trace that out instead of the 0.5%

Grab 10 Nucleos. (Doesn't seem to matter. They seem to foul up more often (50%) than my PCB's (30%)

Comment out the I/O expander and LED calls in the STM32CubeL4 CDC demo.

Compile that up and run the hex through Clive1's auto aligning hex2dfu. ( Thanks clive1 )

Stick the B type USB connector on it. On flying wires about 1/2 inch long above connector CN10.

Boot0 to 3.3V

Power it up and DFU load it with the Truestudio compiled binary using DFUSE.

Boot0 = LOW

Cycle power - reboot

Plug 'em in.

?

In general our PCB is certainly not rocket science. It's a nucleo repined and less the debugger parts.

[waclawek.jan]

Posted on March 29, 2017 at 18:53

And DFU on that flaky Nucleo works or not?

JW

[shingadaddy]

Posted on March 29, 2017 at 21:13

Thanks Jan

Just as easy to recode a bit and use the existing 8MHZ MCO feed off the debugger. (HSE BYPASS)

I did that just to prove I could. Didn't leave it that way of course since I was targeting this MSI trimmed with LSE trick.

That puts me back to a Nucleo when I have muy PCB's to worry with but good suggestion.  It might prove a point but I hope I have a recoverable solution for what I have in copper.