Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Comments on recommendation for chip programming connection (pogo?)

Post

recommendation for chip programming connection (pogo?)

+2
−0

Background: I have several microcontroller based projects with custom PCB that have been in very-low-volume production, but the quantities are starting to go up. (batch sizes now ~100 and threatening to go to ~1000). The economics here are such that part cost is a secondary concern.

I don't feel ready to commit to having the chips pre-programmed, and while I have a bootloader, it is considerably slower than flashing the chip using it's in-system-programming feature.

So far I have put a dedicated picoblade programming header for simplicity, but even this is starting to be a nuisance, and a waste of footprint space.

Question: Looking for recommendations for alternatives, experiences, etc.

I have seen customized programming devices with pogo connectors (some very slick ones, in fact), with unmasked pads on the receiving end on the device to be programmed, and fancy alignment mechanisms.

In particular I was thinking of using something like a 1.27mm thru-hole footprint with smaller holes than the pogos to receive the connections, rather than flat pads. Then maybe ok for the person doing the programming to just hold it in place by hand for the 3-4 seconds it needs.

I was wondering if there are anyone here has recommendations for any off-the-shelf components they have used, or alternative methods that may be relevant.

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (4 comments)
General comments
Lundin‭ wrote about 3 years ago

"I don't feel ready to commit to having the chips pre-programmed" Why not? This is no effort at all, you just contact a company dealing with such parts, give the binary to them (NDA if necessary) and buy the pre-programmed MCUs from them instead of the silicon vendor. There's usually no big MOQ.

Lundin‭ wrote about 3 years ago

Also, justifying development costs of pogo pins, bootloaders etc means that you must have large volumes. Engineers cost money. How many 2x5 1.27mm SWD connectors can you buy for the engineer salary required to develop this? Almost certainly far more than a product life time of such connectors.

Pete W‭ wrote about 3 years ago

@Lundin , there's a lot of truth to that. At this scale, a streamlined programmer is a "nice-to-have". I'm trying to think ahead, get the technique down, etc. Having the ability to flash it in-house (even if pre-programmed) is valuable no matter what. We do lots of product variations and connecting to each device by serial-over-USB is a pain. The bootloader was a must-have for field upgrade, and to be honest was kindof trivial to develop.

Lundin‭ wrote about 3 years ago

The way I usually do this is to buy pre-programmed MCUs for high volume products ~1000pcs/year, keep the SWD connector footprint on the board but don't mount it. For products of lower volumes or products where you expect a lot of software releases, keep the connector and use an in-circuit programmer. As for bootloaders, they are indeed much easier to make nowadays since most chips support making them in some way. But they are for specialized use-cases only.