Is there a reason to avoid putting programming interface pins close?

[daqq]

So, I'm designing a PCB with a PSoC ARM with an SWD interface. The XRES pin is on another side of the package, some 16 pins away from the SWDIO and SWCLK pins, though close to the power pins, though there's the output of the internal 1.8V LDO in the way. Not cool.

Then there's STM32 devices. I've worked with several and they always manage to fudge things up. The STM32F303VCTx has the NRST pin on the other side of the package as the SWD interface. The SWD interface, which is literally just two wires, is on two sides of a 4 sided package package and there are 3 signals between the two signals! What?

I mean, what? Is there some reason that I'm not getting that makes it prohibitively expensive to put THREE PINS that will almost universally have one use case close to one another? I can understand that some large 40 pin interface interface will be all over the place since it needs to work on all kinds of packages and so forth, fair enough.

But three pins. Come on! Really? Splitting three pins over three sides of the package (ignoring the need of the programmer to include +VCC and GND)? Really?

I mean, I can work with that, sure, but it's a pain in the ass routing reset under half the package. I guess it's OK for mass produced devices that'll just have test points all over the place, but damn, for development and low volume stuff, really?

Sorry, just pissed at finding out that this curse extends to yet another architecture.

/rant

[spudboy488]

I don't have an answer but the CPLDs I use have the JTAG pins scattered all of the device as well.

[Berni]

The STM32 pinouts are made by a braindead monkey in general.

They often do things like putting 3 pins of a SPI bus next to each other and then stick a clock pin like 20 or 30 pins away. Or give you a UART with RX and TX next to each other, yet the corresponding RTS and CTS are on the other side, yet the RTS and CTS lines of a different UART are right next by. I'm guessing some of those make sense on a BGA package, but then they just randomly distribute it into a TQFP in whatever order is easiest for the wire bonding machine. Or the chip designer doesn't even make consideration about it, placing bonding pads on the die wherever convenient, then the guy responsible for wirebonding it into a package just takes the easiest route. This becomes even more aparant when you try to connect very wide bus peripherals, like 24bit RGB video output or RAM with 16 data lines and 20 address lines. The lines are just scattered all the way around the chip, making PCB layout a living hell.

You also get things like one pin having the TX pins of UART1, TX pins of UART2, RTS pins of UART3, SDA for I2C and MOSI for SPI all on one pin. But then there are things like GPIO pins where the only alternate function is a timer. Tho there is some reasoning behind that, they use the same silicon die to pack more peripherals into a smaller pin count package, even if you can't really make use of all of them since they overlap. Making it very infuriating that you want to add a feature to a product yet the peripheral you need for it is already barricaded in under other functions that you also need.

[ataradov]

Reset is not totally necessary for programming. If it really gets in a way, you can always just drop it from the connector.

[Siwastaja]

Similarly, the high-speed DCMI bus interface tends to be all over place, one of the bits or the clock on the opposite side of the package.

I think ST scrambles the pinout on purpose. Why? No idea! Maybe a consultant thought it gives more weight to their design tools?

Like, they design a good, normal pinout first, then randomize some 20% of it, leaving some level of sanity behind.

[tooki]

Not restricting to any particular category of ICs, it seems to me that more often than not, pins are in nearly random order.

At least some types of ICs (like opamps and 74 series logic) generally stick to some standardized layouts.

For sure, it seems to me that analog ICs tend to be less random. But that’s just casual observation, not representative study.

[cavac]

At least some types of ICs (like opamps and 74 series logic) generally stick to some standardized layouts.

"Generally" is the word for the 74 series. But there are nice quirks that can get a bit annoying, especially when hand-soldering on a prototype board. Take for example the venerable 74HC165 shifter. The pins you need to connect to your controller (like an Arduino) are spread nicely to all four corners, with the input pins between them. So, no matter what layout you choose, your serial lines have to cross your parallel lines.

Not to mention the biggest problem of the 74 series seems to be naming of the pins. When i got started with the 74HC165, i look at 10+ different data sheets and tutorials, and not two of them had the exact same pin names.

(Of course, pretty much nothing on the market beats the idiotic confusion that is the Raspberry Pi GPIO pins, where you have to mentally switch between pin numberings, depending on which program/library you are using and which version of Raspberry Pi it is...)

[radar_macgyver]

So, I'm designing a PCB with a PSoC ARM with an SWD interface. The XRES pin is on another side of the package, some 16 pins away from the SWDIO and SWCLK pins, though close to the power pins, though there's the output of the internal 1.8V LDO in the way. Not cool.

What device/package are you using? PSOC5 in QFN68 and TQFP100 have XRES, SWDIO and SWDCLK on pins 10,11,12 and 15,20,21 respectively. The ability to reassign pins for peripherals on these devices has made them a favorite of mine. Make sure to have a cap to ground on the XRES input, it tends to pick up EMI and reset the device without it. With the programming cable plugged in, a static zap from my hand to any metal object in the room several feet away would reliably reset the PSOC.

Xilinx had TDI and TDO on opposite edges of TQFP parts, probably with the idea that it makes it easy to chain JTAG from one device to the next.

[bson]

Reset is not totally necessary for programming. If it really gets in a way, you can always just drop it from the connector.

This!  The programmer should use the soft reset sequence, not pull reset.  The SWD-based reset permits the CPU to come up halted before a single instruction has been executed, while with the hard reset by the time the programmer asserts control and halts it a whole bunch of code will have been executed, making debugging startup code require all sorts of hacks (any and all of which invariably change its footprint and behavior).

[radar_macgyver]

PSOC data sheet says that SWD requires the hardware reset. This is because PSOC has two sets of SWD pins that are chosen based on activity immediately after reset. When using JTAG, only one set of pins is available, so asserting reset is not required when programming the device using JTAG.

https://www.cypress.com/file/119651/download

[S. Petrukhin]

Reset is not totally necessary for programming. If it really gets in a way, you can always just drop it from the connector.

You can't do without a hardware reset if you use processor sleep modes or have eaten SWD pins for your needs. 

[ataradov]

Reset does not help if device goes to sleep immediately anyway. Unless there is some way for the debugger to intercept the boot process, like in Atmel MCUs. But that is not very common.

[S. Petrukhin]

Reset does not help if device goes to sleep immediately anyway. Unless there is some way for the debugger to intercept the boot process, like in Atmel MCUs. But that is not very common.

With the help of a hardware reset, the processor is possible wakeup and immediately stop the processor, so as not to give the code the opportunity to go to sleep again. I suffered a lot when I studied sleep modes, believe me, life becomes easier when it is there.

[Berni]

I bring all the associated pins to the programming header regardless if they are used or not. Its not like having a 3 pin or 6 pin connector is that big of a difference. If space is too tight to have one then the only option is likely test points anyway.