Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

Turbo J — Sat, 30 Jun 2018 10:44:03 GMT

You can automate the OTA process. No real need for manual work here.

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

godmode — Sat, 30 Jun 2018 09:45:17 GMT

I have built 48 port SWD multiplexer that runs on 250cm long cables at 4MHz clock programming and debugging.
Please check releated post (text and photos):
devzone.nordicsemi.com/.../what-is-the-swd-driver-impedance-of-swdio-line

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

thefool — Tue, 15 Aug 2017 09:10:20 GMT

why bother commenting without answering the question then? Of course board space is quite cheap, and like I said, the programming stub is a great idea, still I know that 5000x individual programming is going to cost so much more time than 100x automated gang programming of 50 devices at once... even adding the development time of a simple muxing gang programmer. BTW - I probably wouldn't put the muxing chips onto each panel, I'd make a seperate gang-programmer-pcb that I could optionally connect to a bed-of nails (for the entire panel) with jumper cables or a pcb-edge connecter that costs nothing on the pcb panel, and a euro or two on the gang-programmer. Oh and your comment on OTA: "That costs nothing"? have you calculated 5000x (OTA transfer time+ BLE searching, connecting, etc, for each device) * minimum wage? The whole point of gang programming is saving time, OTA does the opposite.

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

RK — Sat, 12 Aug 2017 02:37:08 GMT

why bother - compared to adding mux chips, board area is (relatively) cheap. Remember this is for an initial production run of 5000 so something easy cheap and inefficient may (their choice) be preferable over something which requires coding and chips and more setup Assuming the board is fully populated, the cost of having a couple in the middle you can't program because your mux system was too complicated likely outweighs the cost of extra board to give each instance a snapoff programming stub.

There is another option of course. If they quickly put together a blinky + bootload + softdevice + DFU package (which is pretty much available right out of the SDK), that could go to the factory NOW for gang programming. Then they get boards which have flashing lights to check them and they can OTA them with the final software. That costs nothing.

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

thefool — Thu, 10 Aug 2017 17:53:07 GMT

Hmm, OK... too bad, since the question was all about Muxing ;-) Yeah, I haven't seen anything that supports multidrop either... - Lets assume trace lengths of less than 10cm with adequate trace width on an inner layer, with a ground plane on top/bottom to shield them. What would be the problem with a couple of 8:1 Mux/demux chips that would switch between the 40-50 pairs of swd lines to the single pair coming from the J-link? It would essentially (theoretically) be the same as disconnecting the swd lines from one device and connecting it to the next... except you could do that programatically than physically, saving huge amounts of time (money) in production... The question remains whether it's enough to switch just one - either swdio OR swdclk, or if both have to be switched...

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

RK — Thu, 10 Aug 2017 14:17:38 GMT

you've misunderstood much of what I suggested. I'm not suggesting muxing anything, I don't think it will work to mux even swdclk over more than a few devices because you'll run into capacitance issues. I know what multidrop is and how it works, but even the spec for multidrop doesn't say how many devices can be connected (not that I've found) and anyway nothing supports it. The SWD v1 spec specifies one device per swdclk/swdio line pair.

I suggest having one single bed of nails per device on thin strips around the actual devices which can be broken off after use. You don't need 50 jlinks, you need one, or two, or three, you just go from bed to bed and program each device. It's slow but it works. The more jlinks you have, the faster you get it done. One guy does one panel, someone else does another.

No muxing at all.

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

thefool — Thu, 10 Aug 2017 13:44:18 GMT

Like I said in another comment: The jumper cables from any bed of nails setup to the JLINKs would be just as long as the traces... (and on the PCB, you could surround them with a ground plane...) But I like the idea of moving the "connector" (large enough testpads for bed of nails) to unused panel space, outside of the individual pcb area... nonetheless, whether bed of nails or another method, the question is still valid: to program 50 devices, you still need either 50 J-links or multiplex SWD lines somehow. Muxing any data-line should be no problem - multidrop on swd is not muxing, but rather having all devices connected to the same two swd lines, and the devices figure out which one is supposed to be programmed now... as far as I understood, the question is about whether muxing just one of the lines (swdio OR swdclk) is enough (and which is better), or if both have to be muxed...

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

thefool — Thu, 10 Aug 2017 13:34:09 GMT

You're funny... OTA Firmware update on 5000 devices "just" before shipping? :-D The jumper cables from any bed of nails setup to the JLINKs would be just as long as the traces... and the traces can be on unused areas of the panel, and on inner layers of the 4 layer PCB, whereas the pads have to be on the top or bottom of each device...

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

RK — Wed, 09 Aug 2017 21:45:59 GMT

Not sure it's going to work too well. Even if you have individual traces per board, you're going to have some fairly long lines. You'll have to route them to be about the same length and even then the stray capacitance on the longer ones is going to cause you at the least speed issues, at the worst, programming failures.

I don't think muxing the SWDCLK is going to work. SWD v1 wasn't designed for that, again I think you'll run into capacitance issues pretty quickly apart from problems with multiple devices trying to respond. ARM designed SWDv2 multi-drop for sort of that and I can't find quickly in the spec how many devices are allowed to attach to SWD even there. And the nRFs don't support multidrop (don't know if anyone does). If they supported JTAG mode that would be a cool way to program lots of them, you could really set the whole array up as a big boundary scan chain, but they don't support that either.

I've never come across anyone trying to do it this way, which makes me feel that .. there's always a better plan.

You said the board is too small for a bed of nails. Even the tag-connect size with 3 holes (they're a pain) and 6 pads? I'd recommend trying that again and see if you can find a creative way to get them in.

Last option I'd probably try if there really is no room is to panelize the boards with a strip of beds of nails between them, one per actual board (you should be able to pack those in), program the boards via their (personal) connector, then snap them off. You'll probably reduce your board count per panel that way because of the extra area, but you have the advantage that it will work, you don't need to make anything complicated to make it work and programming will be super quick. You'll have to work out the economies of getting fewer boards out of each panel and thus how much it'll cost per board to do this, I'd hope for a run of 5000 you'd be talking pennies per board, not insignificant for a kickstarter run, but if it gives you 100% programmability of every board on the panel using a simple method, it may be worth it to get it done.

I reckon by the time you've done 5000 you'll be quite good at it :)

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

Nguyen Hoan Hoang — Wed, 09 Aug 2017 15:37:18 GMT

A combination of both SWCLK & SWDIO sequence is required at initialization. Depending on the state of SWDIO and x clock pulses, it puts the DAP in certain state. It is not recommended to just switch SWDIO but you try it if you like.

PS you can also use the IDAP-Link or IDAP-M for parallel programming of your boards.

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

Andy — Wed, 09 Aug 2017 15:20:03 GMT

Is it possible to share SWCLK and just multiplex SWDIO? I read in the ARM CoreSight spec that if the SW-DP detects activity on the clock without any movement on the SWDIO line, the debug interface will try to reset. I'm not sure about this though. Why did you say that both are needed?

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

Nguyen Hoan Hoang — Wed, 09 Aug 2017 15:16:11 GMT

You can multiplex them, just make sure you switch both SWDIO & SWCLK.

RE: Multiplexing SWDIO/SWCLK to program panels in production - Why is it a bad idea?

Turbo J — Wed, 09 Aug 2017 14:13:53 GMT

Our panel will have 40 to 50 boards and the PCB has 4 layers. We are planning to use a single J-Link and multiplex the SWD lines to program one device at a time.

Calculating the required routing space in my head, this solution will be larger than having just some tiny pads or vias for the SWD lines somewhere on each board.

You will need some other test pads for any proper production testing anyway.

we would have to send the final binaries to the manufacturer now and the firmware is not ready yet.

Then just send them the Softdevice and OTA Bootloader. You can then update the firmware over thin air just before shipping off to the customer.