Factory programming

[jrychter]

I'm designing a board that will host the RPi Compute Module and I'm wondering about how people go about factory programming the CMs. It seems the only way is to use USB, like the IO board. But that has drawbacks: on my board, instead of the cheaper&simpler LAN9500, I'd have to use a LAN9512 with the USB hub, and then also provide a USB connector.

Does everyone just build USB into their boards? Or is there a way to access the eMMC via JTAG or some other way?

How do you program your CMs in production?

Any hints much appreciated!

[6by9]

You can't use a downstream port of a LAN9512 for programming - the USB bus has to run with the Pi as a USB peripheral/slave, not the host/master, same as USB OTG (On The Go).

I don't have any direct experience, but as USB is half-duplex on a single pair, you can probably talk direct to the Pi as long as you can power down your LAN9500 chip and set the EMMC_DISABLE_N line low to prevent EMMC boot. 5 pogo pins (+V, D+, D-, GND, and EMMC_DISABLE) onto appropriate test points should allow you to do most of that.
The CMIO board does almost that, but has a proper USB switch between the host and slave USB connectors as they can't control the power state of the slave devices.

I think the guys behind the Slice media player did a blog post at one point on their test and programming rig - I can't find it at the moment though.

[gsh]

Actually that's not going to work with a 9512/4/5 either...

For USB boot it needs to be booting in device mode not host mode. Therefore the way to do this is to provide a USB analogue switch to switch the CM D+/D- from the 9514 to an external USB micro B connector. Then control that switch by the USB VBUS from the USB micro B connector...

That's the way we did it for the FiveNinjas.com Slice product

Gordon

[6by9]

And there's the response for how Slice did it - hi Gordon!
I've just found the blog post on it with video of the factory test jig https://www.raspberrypi.org/blog/creati ... ia-player/

Actually that's not going to work with a 9512/4/5 either...

For USB boot it needs to be booting in device mode not host mode. Therefore the way to do this is to provide a USB analogue switch to switch the CM D+/D- from the 9514 to an external USB micro B connector. Then control that switch by the USB VBUS from the USB micro B connector...

I'm not sure if you're responding to me or OP - I'm guessing OP based on timestamps.
Do you actually need to have a USB switch if you can power down any slave devices on your board? I'm thinking of cases where in-field updates are not required so exposing that USB port and adding the switch IC is a potentially significant cost/complexity. Perhaps I'm too used to RS485

[jrychter]

Thanks for the helpful info! I guess the switch is the way to go, then, just like on the CM IO board (a FSUSB42 DPDT switch is used there).

I wondered about the possibility of holding the LAN9500 in reset, which should prevent it from doing anything to the USB signals (I'd expect them to go HiZ). It's not ideal from a signal integrity point of view, but could potentially work.

I guess I'll go with the FSUSB42 and a USB connector for now, then. I asked because I thought people were building boards without these parts and using another way to program the eMMC.

[gsh]

I think holding the LAN95xx device in reset would work, but I would be worried about signal integrity if you insert the stub...

Analogue switch is definitely the recommended way to do it, but it may be worth a punt at holding in reset if you've got the time to respin the board...

Gordon

[6by9]

As long as you put the programming points at the LAN95xx device end of the traces, then it's little different from the arrangement on the original A/B where R28/29 0ohm resistors were added for the model A, leaving a little stub track off to the unpopulated LAN9512 pads. (I haven't got my 256MB model B to hand to see how long those stubs really are).

I'd agree that running the signals any significant distance to make a convenient USB programming point would be very risky, so some thinking about device updating and recovery in the field would be required if these test points are buried on the board somewhere.

The risk is with the board designer if they want to try things out without using the recommended switch - I've been doing software too long, so my electronics degree is very much theory now instead of practice.

[jrychter]

Thanks for all the advice. For now I will use a FSUSB42 and 3 MOSFETs like the IO board, as I can't risk delays. In the future, however, I will want to eliminate it, because of the cost, so I'll try a hacky solution with holding the LAN9500 in reset and attaching a programmer connection somewhere.