failed to scan S32k14

[mm-mm-bb]

Hello,
im using a BMP 2.1 updated to latest release, 1.10.2 native.
I can scan stm32 without issue, but not the S32K144. I tested with a segger j-link (as SWD) and works but only if i set swd speed to 2000khz.
seems the chip is fully supported from the support page, so can anyone else please confirm it is working?
Is there a way to force the SWD speed from the gdb client?
I have connected SWO, SCL, IO, reset and GND (power is external)

[dragonmux]

👋🏼 Hi, so to answer a few of those things in turn and ask for some more information:

First, for SWD speed setting, you're after the monitor command monitor frequency - this allows you to both request and set the interface drive frequency. For example, for 2MHz which is what you're using with the SEGGER tools, it'd be monitor frequency 2M. You can check what it's actually set to with running just monitor frequency - it may not be 100% the same as what you've requested as the firmware will set it to the next nearest actually possible value and is honest about this.

Second, regarding your pinout - we presume by "SCL" and "IO", you are actually referring to the SWCLK and SWDIO pins? (rather than something like an I²C clock which is what SCL usually refers to)

Finally, while as far as we know the S32K14x parts are properly supported, we only get to know about breakages when users report them for those particular parts. If you could please, grab the latest BMDA from CI for your platform and then run blackmagic -tv 5 to get a detailed log of trying to scan for your part via SWD. This will tell us if it is broken in the latest main or indeed if something that has been changed since that release has fixed support for that part if it is in fact broken in v1.10.2.

To use BMDA, you will need to be using the latest version of the project's udev rules if you are on Linux so it can properly establish communications with the probe. The other platforms should just work given the latest BMDA and the v1.10.2 firmware running on the probe. BMDA understands how to communicate with probes using older versions of the remote protocol to the latest, so unless you're being impacted by a low-level detail like a bitbanging bug, this will be sufficient to get some diagnostics on what's going on with that part.

[mm-mm-bb]

thanks,
you are correct about the terminology.

I did a sanity check, as i realised i never tested the probe after upgrade to 1.10.2;
unfortunately now it cant connect to the chip it used to connect, STM32f4.
I am using the same identical cable with a jlink in SWD mode and works without issue

from the debugger, in widnows, i get

Black Magic Debug App 6cc8286
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 7BB089B4 Black Magic Debug
 Black Magic Probe v1.10.2
Found AUX Serial at COM22
prefix: 6&269270bb&0
Using BMP at COM23
Running in Test Mode
Target voltage: 3.3V
Speed set to 1.951MHz for SWD
Switching from JTAG do dormant
Switching out of dormant state into SWD
Deprecated JTAG to SWD sequence
No usable DP found
No target found

should i maybe try to downgrade, i think I was on 1.9.x or something. It is a BMP 2.1, I see latest hw is 2.3, is the newest firmware compatible?

[dragonmux]

We suspect you might be getting punked by one of the SWD turnarounds/timings bugs that have been fixed on main, so please grab the firmware .zip (same nightly.link link) and use blackmagic_native_firmware.elf (or .bin) to upgrade your probe onto the latest main and re-test. We know for certain that the STM32F4 works on latest main.

All released native hardware is supported by the latest firmware, and we test with a v2.1e unit semi-regularly to check that, especially when issues with bitbanging and low-level protocol stuff come about.

[mm-mm-bb]

no luck, both with S32K144 and STM32F412
edit: is there any issue in downgrading? even just to check if the stm32 works again

[mm-mm-bb]

ok, downgraded to 1.9.3, st work in GDB, and got suspicius as the DMDA failed to recognize anything!
so i tested with gdb and the stm32 works!

(gdb) monitor swdp_scan
Target voltage: 3.3V
Available Targets:
No. Att Driver
1 STM32F412 M4

but the BMDA does not:

./blackmagic-bmda.exe -tv 5
Black Magic Debug App 6cc8286
for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 7BB089B4 Black Magic Debug
Black Magic Probe v1.9.3
Found AUX Serial at COM22
prefix: 6&269270bb&0
Using BMP at COM23
Running in Test Mode
Target voltage: 3.3V
Speed set to 3.272MHz for SWD
Switching from JTAG do dormant
Switching out of dormant state into SWD
Deprecated JTAG to SWD sequence
No usable DP found
No target found

the s32k144 does not work.

edit:
updated to nightly, tested with GDB the stm32 actually give an error on scan!

(gdb) monitor swdp_scan
Target voltage: 3.3V
Exception: SWD invalid ACK
SWD scan failed!
Failed

[dragonmux]

That is extremely odd as, using the exact same version of the firmware and BMDA as you, here are our results from doing a scan against a STM32F415 via a BMP v2.1e:

❯ ./blackmagic -s BFC590F5 -tpv 5
Black Magic Debug App v1.10.0-1426-g6cc8286e-dirty
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 BFC590F5 Black Magic Debug
 Black Magic Probe v1.10.0-1426-g6cc8286e-dirty
Running in Test Mode
Target voltage: 3.3V
Speed set to 1.951MHz for SWD
Switching from JTAG do dormant
Switching out of dormant state into SWD
Deprecated JTAG to SWD sequence
DP DPIDR 0x2ba01477 (v1 rev2) designer 0x43b partno 0xba
adiv5: power-down failed
AP   0: IDR=24770011 CFG=00000000 BASE=e00ff000 CSW=e3000040 (AHB3-AP var1 rev2)
Halt via DHCSR(00030003): success after 28ms
ROM Table: BASE=0xe00ff000 SYSMEM=1, Manufacturer 020 Partno 411 (PIDR = 0x00000a0411)
0 0x0e000e000: Generic IP component - Cortex-M4 SCS (System Control Space) (PIDR = 0x04000bb00c DEVTYPE = 0x00 ARCHID = 0x0000)
-> cortexm_probe
CPUID 0x410fc241 (M4 var 0 rev 1)
cortexm_probe: Examining Part ID 0x0411, AP Part ID: 0x0411
Calling stm32f1_probe
Calling stm32f4_probe
1 0x0e0001000: Generic IP component - Cortex-M3 DWT (Data Watchpoint and Trace) (PIDR = 0x04003bb002 DEVTYPE = 0x00 ARCHID = 0x0000)
2 0x0e0002000: Generic IP component - Cortex-M3 FBP (Flash Patch and Breakpoint) (PIDR = 0x04002bb003 DEVTYPE = 0x00 ARCHID = 0x0000)
3 0x0e0000000: Generic IP component - Cortex-M3 ITM (Instrumentation Trace Module) (PIDR = 0x04003bb001 DEVTYPE = 0x00 ARCHID = 0x0000)
4 0x0e0040000: Debug component - Cortex-M4 TPIU (Trace Port Interface Unit) (PIDR = 0x04000bb9a1 DEVTYPE = 0x11 ARCHID = 0x0000)
5 0x0e0041000: Debug component - Cortex-M4 ETM (Embedded Trace) (PIDR = 0x04000bb925 DEVTYPE = 0x13 ARCHID = 0x0000)
ROM Table: END
***  1   STM32F40x M4
RAM   Start: 0x10000000 length = 0x10000
RAM   Start: 0x20000000 length = 0x50000
Flash Start: 0x08000000 length = 0x10000 blocksize 0x4000
Flash Start: 0x08010000 length = 0x10000 blocksize 0x10000
Flash Start: 0x08020000 length = 0xe0000 blocksize 0x20000

v1.9 should have a much worse time due to some old bugs that v1.10 addressed - specifically Fixed a regression in the JTAG→SWD sequence code caused by generating one too few cycles [dragonmux], and Fixed a regression which caused SWD to hang if configured for max speed [dragonmux]. main should do much better after #1714 among other SWD-related improvements. Hence our concern that you're not managing to get valid scans from your targets..

Please try using both the latest main firmware + BMDA on your probe at the same time and let us know the results.

[mm-mm-bb]

ok,
my probe seems to be 2.1c (hard to read) from 1 bit squared.
set up all to nightly, i notice for stm32 i get few extra lines you dont get (also seems you are on a dirty commit?), including

platform_target_set_power failed, error 0

full output:

 ./blackmagic-bmda.exe -tpv 5
Black Magic Debug App 6cc8286
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 7BB089B4 Black Magic Debug
 Black Magic Probe 6cc8286
Found AUX Serial at COM22
prefix: 6&269270bb&0
Using BMP at COM23
platform_target_set_power failed, error 0
Running in Test Mode
Target voltage: 3.3V
Speed set to 1.951MHz for SWD
Switching from JTAG do dormant
Switching out of dormant state into SWD
Deprecated JTAG to SWD sequence
No usable DP found
No target found

also gdb does not give me anymore the ACK error

(gdb) target extended-remote \.\COM23
Remote debugging using \.\COM23
(gdb) monitor swdp_scan
Target voltage: 3.3V
SWD scan failed!
Failed
(gdb)

not sure how to proceed, i dont have access to a logic analyzer/oscilloscope at the moment

[dragonmux]

The -dirty comes from an unrelated change to stm32l4.c so can be entirely and safely ignored - we were poking at a bug to do with a device in that family earlier.

Given what you're seeing from SWD scans (note you only need to give -p if you need to power up the target from BMP, that option is not necessary otherwise), please could we get the output of blackmagic-bmda -tv 45, as this will give a raw read-out of the remote protocol conversation with your probe, and may shed some light on what exactly is going on here.

For reference, this is what a v2.1e board looks like:

Hopefully that helps you compare to check what your hardware is exactly - it would be surprising (but not improbable) for it to be a v2.1c, but more likely it's the font on the e making it look like a c through dust and such. Not that that should matter at all for the purposes of your issue.

[mm-mm-bb]

hi,
full output:

./blackmagic-bmda -tv 45
Black Magic Debug App 6cc8286
for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 7BB089B4 Black Magic Debug
Black Magic Probe 6cc8286
Found AUX Serial at COM22
prefix: 6&269270bb&0
Using BMP at COM23
+#!GA#
KBlack Magic Probe 6cc8286
!HC#
K4
!HA#
K9
!GP0#
K0
!GZ0#
K0
Running in Test Mode
!GV#
K3.3V
Target voltage: 3.3V
!GF003d0900#
K0
!Gf#
KD9C81D00
Speed set to 1.951MHz for SWD
!SS#
K0
!GE1#
K0
!So20ffffffff#
K0
!So1cfffffff#
K0
Switching from JTAG do dormant
!So051f#
K0
!So1f33bbbbba#
K0
!So08ff#
K0
Switching out of dormant state into SWD
!So206209f392#
K0
!So2086852d95#
K0
!So20e3ddafe9#
K0
!So2019bc0ea2#
K0
!So0c1a0#
K0
!So20ffffffff#
K0
!So20fffffff#
K0
!So08a5#
K0
!Si03#
K7
!SI20#
PFFFFFFFF
!So080#
K0
Read DPIDR: 0x00000000
Deprecated JTAG to SWD sequence
!So20ffffffff#
K0
!So1cfffffff#
K0
!So10e79e#
K0
!So20ffffffff#
K0
!So20fffffff#
K0
!So08a5#
K0
!Si03#
K7
!SI20#
PFFFFFFFF
!So080#
K0
Read DPIDR: 0x00000000
No usable DP found
No target found

the board seems pretty much the same:

[dragonmux]

Thank you for the logs, they are much appreciated in figuring out what's going on. Your target is in fact not responding to requests which is why BMD isn't finding it:

!So08a5# ; Request the DPIDR
K0
!Si03# ; Read back the ACK bits (7 -> no-response)
K7
!SI20# ; Run the 32 data cycles anyway (0xffffffff w/ parity error)
PFFFFFFFF
!So080# ; Run 8 idle cycles
K0

(Annotations our own)

That is in fact a BMP v2.1c, so you read that correctly. We are about to try testing this setup with a BMP v2.0f (HW2) in the hopes that older hardware will reproduce your issue where our v2.1e cannot. This will be against the same STM32F415 target as before which should be the most comparable to your STM32F412. This looks to be either a bitbanging bug or an older hardware control bug that's slipped in.

It would be useful to know how you're connecting your BMP up to your target - eg, are you using fly wires, or are you using a 10-pin IDC connection? Are there any adaptors in play?

Edit: Update, tested with both HW2 and HW1, and everything works perfectly on both of those, however we're struggling to find a board that is HW3 which is what we suspect the v2.0c is - so this could still be a hardware-firmware issue, that's specific to the HW3 generation. Any information you can give us though on setup between the BMP and your targets will be immensely helpful in tracking down what's going on here.

[mm-mm-bb]

im using a custom cable, 10 pin standard IDC on one side and flat jst on the other, but this same cable work flawlessy with the Jlink + adapter (https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-20-10/)

[dragonmux]

A quick check of that adaptor shows standard 10-pin ARM pinout on the 1.27mm IDC side and pre-Cortex ARM JTAG on the 2.54mm 20-pin side, so that all checks out, and it's wired through properly.

[dragonmux]

So, a further update on trying to reproduce the circumstances of your issue: Having double-checked further, we can confirm that your board is HW3 and that is unfortunately the only revision of the hardware-firmware interface we do not appear to have on our desk. Consequently, trying to reproduce the issue, which appears to be unique to that hardware revision (board revision v2.1a through v2.1c) is not going well.

We're happy to say that this looks like a regression between the v1.9 and v1.10 releases at least, given that's the threshold for working and broken for you, and we think that probably rules a wiring issue out especially given you're not dealing with fly wires and your adaptors all seem reasonably designed.

We'll have a discussion with Esden about how to progress with this and get back to you once we have some answers.

[dragonmux]

Apologies that it's taken so long to get back to you. In the intervening time, we've been poking at a v2.1c (HW3) unit that Esden's kindly made available to us and despite giving it a really good shake, we've not been successful in recreating the circumstances of your issue - we're able to get it to scan for and find the test target (a 1bitsy, the STM32F415 based board we used locally) with total reliability.

We do note that this isn't over a large amount of adaptors or cabling though so if there is some sort of reflections issue or so in play, we won't likely find that. We're also not going to give up because you've very clearly demonstrated there is a problem and we want to find it and see if we can fix it.

[mm-mm-bb]

thanks, im not in a hurry as i got a working alternative.. actually i may ship my unit to you if you want. just let me know how contact in private