I have found following Microchips' reference design to work well for me. I have a custom carrier board for the CM3L and the LAN9514 now works well. I had some issues (all of which turned out to be my doing! see my posts for details)

The reason we have this different setup is due to undocumented changes to reduce power consumption of the 9514 device. I'm sorry but we can't release the documentation to you on this. I would suggest you just wire it up like the app note and ignore the way the Raspberry Pi is wired.

The reason we have this different setup is due to undocumented changes to reduce power consumption of the 9514 device. I'm sorry but we can't release the documentation to you on this.

That's fair enough but I do hate it when chip manufacturers provide selected customers with information which they don't or won't disclose publicly or to all customers. That gives those selected customers an unfair advantage over the others, creates an uneven playing field, and seems deliberately intended to do that

I would consider that to be an antitrust issue and anti-competitive behaviour which is probably why they put non-disclosure agreements on those they do tell because they know that as well.

I can't really blame the RPT for using information not documented, published or disclosed to others to their advantage but it is all rather unethical in my opinion. Once one sees getting an unfair advantage as acceptable the implication is that being given an unfair disadvantage is also acceptable as well.

That's what I was meaning. One needs to know what the test modes are and how they work to be able to put those to other uses. Those who have access to such information have an advantage over those who don't.

That's what I was meaning. One needs to know what the test modes are and how they work to be able to put those to other uses. Those who have access to such information have an advantage over those who don't.

Standard industry practice. Different customers get different levels of support. Some might get bells and whistles, others might have to use them as standard. Poeple who buy the chip get exactly what they paid for. It's described in the datasheet.

Want something better? Pay more.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

The great thing about a competitive landscape for components like this is that you get to vote with your feet. There are many other devices available to you. The idea we had was 'our idea' - we asked them whether it was possible - they gave us a method for implementing it

This isn't a case of them giving us a special handshake document that isn't available to you, it's a case of us having an idea and asking whether it would be possible. If you have the same idea I'm sure they'll give you the same information.

That's what I was meaning. One needs to know what the test modes are and how they work to be able to put those to other uses. Those who have access to such information have an advantage over those who don't.

and maybe have a different business case.
Those with access to special documentation are usally required to sign an NDA. Manufactures need to keep their IP secret, it's not everything public domain info (although many people think as such)

The “undocumented mode of operation” is related to reducing the total power consumption and heat dissipation of the LAN9514 – but at the potential expense of performance.

Essentially, the LAN9514 internal 3.3V to 1.8V LDO’s that power the USB PLL, LAN PLL circuits and Cores are externally powered from the Pi’s 1.8V switching regulator – thereby reducing the thermal dissipation of the LAN9514 (its internal linear LDO's are disabled) and therefor making for a more power efficient design.

There are two negatives to this mode of “external 1.8V” operation:-

1. The Clock Jitter performance of the LAN9514 PLL is effected by the external noise of the 1.8V switching regulator – this noise is heavily correlated by the Data being processed by the memory / CPU – if the jitter spectrum of your USB output is important (such as for Audio systems) then its better to power the LAN9514 PLL’s etc from either the internal LDO’s (and live with the resultant increased thermal dissipation of these internal LDO’s – the LAN 9514 does indeed run hot, so make sure you use correct PCB thermal design (Take care with the PCB vias around the LAN9514 Thermal Pad)) – and use a low Phase noise 25MHz clock (do not use the 25MHz Clock generated by the CM3).

2. You also have to be careful with the power sequencing of the now separated 1.8V and 3.3V supplies to the LAN9514 to prevent latch-up damage or unstable operation of the LAN9514..

The above two points are very design sensitive – most digital designers struggle with “Analogue” characteristics of a system, so as Microchip has only limited field support engineers it has to avoid introducing “Edge design cases” – its needs a design that works with little skill – hence not mentioning some of the more silent modes of operation (That requires in-depth understanding, and worst which by getting wrong would just introduce a whole bag of 'Random' hurt)… Microchip does not have the resources to handhold every design….

The other difference are related to the grounding of the JTAG connections and over-current protection pins – but none are really a show stopper, the Microchip App. note works well, but make sure to connect the LAN_Run (Reset) to a CM3 GPIO so the CM3 can Reset the LAN9514 upon any reboot event.

Do take some care with the USB HOST power over-current protection circuits, I’m guessing RPi faced issues with the over-current trip circuits (timing) as they introduced a lets say ‘funky’ delay circuit, which one can only presume is to keep the LAN9514 ‘Happy’ during continued overload events (rapid tripping)…. but that’s just conjecture on my behalf…

Last edited by John Westlake on Mon Oct 01, 2018 8:30 pm, edited 2 times in total.

Apart from the PCB layout need to be take care, does this “undocumented mode of operation” need any software changes to support it? Thanks.

The stock foundation supplied firmware with other open source software, including Raspbian, appears to work okay with Pi 3B boards which have the non-datasheet configuration so I would have expected it to work if replicating that same non-datasheet configuration LAN9514 hardware for a CM3.

It would seem unlikely that the firmware were coded to only allow the non-datasheet configuration on an actual Pi 3B board but it is possible. Given that pin naming and connections differ between the BCM2835 on a CM1 and a Pi B, and the camera seems to be handled differently depending on whether a CM or Pi board, you might have to reverse engineer a Pi 3B to fully determine what differs from a CM3 replicating a 3B board and a real Pi 3B board, at least to the extent of all connections to the SoC and LN9514.

Probably the best way to see if the non-datasheet configuration works with a CM3 is, as suggested earlier, try it; develop prototype boards which can be used either way, test and analyse the results.

Apart from the PCB layout need to be take care, does this “undocumented mode of operation” need any software changes to support it? Thanks.

I really cannot recommend using the LAN9514 in this way - its undocumented by Microchip for a reason as I went into some length to explain...

As others have already posted - just use as per the Microchip design application note which works well and is stable - we are nearing 10K units manufactured using the CM3 and I'm not aware of any issues with the LAN9514 following the manufacturers reference design.

Apart from the PCB layout need to be take care, does this “undocumented mode of operation” need any software changes to support it? Thanks.

I really cannot recommend using the LAN9514 in this way - its undocumented by Microchip for a reason as I went into some length to explain...

As others have already posted - just use as per the Microchip design application note which works well and is stable - we are nearing 10K units manufactured using the CM3 and I'm not aware of any issues with the LAN9514 following the manufacturers reference design.

#

I cannot upvote this post enough.

Use the reference design.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Thanks every body, I think I should build a board to find it out. Here is the board layout(4 layers), I will test it with deferent pin connections, and let you know once I have the testing results.
The crystal is Kyocera CX3225SB25000D0FFFCC (25MHz 10ppm 8pF 50R). Except the pin connection, I follow Microchip's reference design and layout guideline.
Anything do I miss?

1) when pin29, 30,32 are connected to +3.3V, USB and Ethernet doesn't work(pin40 to ground or +3.3V)
2) when pin29, 30,32 are connected to ground, USB and Ethernet doesn't work when pin40 to ground. current=90mA
3) when pin29, 30,32 are connected to ground, both USB and Ethernet work fine when pin40 to +3.3V. current=165mA

the current consumption are tested on the input terminals of my board(there is a 12V to 5V switch mode DC-DC convertor to provide 5V for the system , the OS is Raspbian (the SD card can is just pull out from a running Raspberry Pi 3 mode B V1.2 board with latest update on it), current readings are taken after boot at idle mode(no software is running).

as my device is running on battery, so power saving is very important, it would be great if 90mA can drive the board by connect pin40 to ground. anybody can help on it? thanks.