Not reliable for SWD

[jans23]

I use the PortMux to switch channels for programming STM32 via SWD. When using PortMux programming isn't stable, depending on the used port and the exact version of the STM32 chip. It seems to be edge cases and even analysing it I couldn't nail it down exactly. The summary is, that as soon as the PortMux is involved, programming isn't reliable. The measured electrical and power characteristics seem to be fine.

Are you aware of any voltage level and signal integrity issues in conjunction with STM32 programming? Any other ideas?

The board is rev 01b.

@NKelias

[bleckers]

Hi jans,

There shouldn't be any voltage level issues and no signal integrity issues associated with the STM32 that I'm aware of.

Which STM32 chipset are you using and how are you powering the STM board for programming (is it through the PortMuxR, or its own supply)? What programmer are you using too?

Also, can you double check that the ground connection is connected through all the boards you have connected up (you can buzz it out from any of the pins marked GND on the PortMuxR or the USB port shield, to all other connected boards, even when not powered).

Do you have a picture of your setup by any chance (if you don't want to post it here, you can send it through to support@sensordots.org)?

[NKelias]

Hi @bleckers,

the issues only occur with an STM32L4 (and only for one of two devices attached to the MuxR), while the same setup works fine for STM32F1 MCUs. Programmer used is a Chinese knock-off ST-Link v2, however the same problem occurs with a genuine ST-Link v2.

Power supply to the board being programmed is separate and all devices share the same ground plane.

I'm afraid I do not have pictures at the moment, however I have attached pictures of the breakout board to which the programmer and the devices are connectd. Config 1 and Config 3 are used to switch between STM devices.

[bleckers]

I notice you have connections between different output ports. I'm guessing you are creating a combined output depending on how you switch the ports. There shouldn't be a problem with the way you're doing things here. Remember that each port has two different channels (A and B), so you can either switch the whole port at once, or one of the channels.

Could it be that in this sort of setup, that there is a programming pin that is being crossed with another pin? Are you able to look at the resulting output on a scope and see if the signal looks OK (check the signal voltage first to see it's not being pulled lower than it should, and check the signal integrity when running)? Compare this to what you get without the Port MuxR in between.

If you aren't able to measure this, are you able to do a continuity/resistance test between the input and output pints while powered up and the problematic config/port is enabled (i.e. the same setup you'd use to program, but without the programmer and microcontroller connected). For each primary pin, check all of the output pins to make sure there isn't continuity between them if they shouldn't be connected.

[bleckers]

How'd you go with this? Any updates?

[NKelias]

Hi @bleckers,
thanks for getting back and sorry for the late reply!

You're right in that the MuxR is actually used as a crossbar between two programmer outputs as well as for two different programmers. We are switching on both channels at the same time and resistance through the MuxR did not seem suspicious. We are resetting all ports to off before switching any single port one, so in theory only one port should be active at any time, but might be worth double-checking!

I did check the output signals on a logic analyzer where I couldn't see any difference in terms of timing or glitches, though checking with a scope could be worth a try! Checking the resistance without anything connected is also a very good suggestion. I haven't done that yet and will try it as soon as I get a chance, though I don't have physical access to the equipment at the moment.