Detect CPU via SWD (segger)? - Page 1
Forum section: electronics / general

author: dav888
author_rank: Regular Contributor
timestamp: June 15, 2020, 10:20:20 pm
content: Trying to find (gooogle without luck) how to probe/detect what device that is on the SWD bus.I'm using a Segger/Jlink for now, but docs is not helping me.Pretty sure this is part of the swd protocol + hwid/deviceinfo so can't see why it wouldn't be implemented.tips!? thoughs?

author: ataradov
author_rank: Super Contributor
timestamp: June 16, 2020, 05:47:14 am
content: There is no universal way to do this. It depends on each manufacturer. The best you can do with 100% certainty is detect the core type (Cortex-Mx).To detect a specific device, you would basically have to try reading device IDs from various known locations specific to each vendor and see if they make sense.

author: josip
author_rank: Regular Contributor
timestamp: June 16, 2020, 09:17:00 am
content: Quote from: ataradov on June 16, 2020, 05:47:14 amIs there any open source example for this?

author: errorprone
author_rank: Contributor
timestamp: June 16, 2020, 11:28:04 am
content: ARM has an open source debuggerhttps://github.com/ARMmbed/DAPLink

author: ataradov
author_rank: Super Contributor
timestamp: June 16, 2020, 04:07:51 pm
content: Quote from: josip on June 16, 2020, 09:17:00 amThere is not a common database of all the parts and location of the ID registers that I know of. Various projects would have this information to some extent, but it would be spread over the various device drivers.The most complete set of devices would probably be in OpenOCD project. My programmer (https://github.com/ataradov/edbg) has some of the IDs mostly for Atmel parts.What is your actual goal?

author: ataradov
author_rank: Super Contributor
timestamp: June 16, 2020, 04:09:52 pm
content: Quote from: errorprone on June 16, 2020, 11:28:04 amThis is just an interface. It does nothing for identifying specific parts.

author: GromBeestje
author_rank: Frequent Contributor
timestamp: June 16, 2020, 06:35:16 pm
content: I'm aware the Black Magic Probe is capable of detecting the target chip.How a debugger could detect the connected chip over SWD:When we speak SWD, we know we're dealing with an ARM chip, thus it should comply with the ADI Specification.This specification specified a ROMTABLE, which should identify the part.Using OpenOCD the following script could do the trickCode:script interface/jlink.cfgtransport select swdadapter_khz 100swd newdap chip cpu -enabledap create chip.dap -chain-position chip.cputarget create chip.cpu cortex_m -dap chip.dapinitdap infoThe output should contain with something likeFor an STM32F103CBT6 we getCode:Valid ROM table presentComponent base address 0xe00ff000Peripheral ID 0x00000a0410Designer is 0x0a0, STMicroelectronicsPart is 0x410, UnrecognizedComponent class is 0x1, ROM tableMEMTYPE system memory present on busFor a CY8C4247AZI-M485 we getCode:Valid ROM table presentComponent base address 0xf0000000Peripheral ID 0x00301b40a1Designer is 0x0b4, CypressPart is 0xa1, UnrecognizedComponent class is 0x1, ROM tableMEMTYPE system memory present on busAn nRF52832 gives usCode:Valid ROM table presentComponent base address 0xe00ff000Peripheral ID 0x02005c4006Designer is 0x2c4, Nordic VLSI ASAPart is 0x6, UnrecognizedComponent class is 0x1, ROM tableMEMTYPE system memory present on busUnfortunately, not all parts allow themselves to be identified this way. Some parts may only identify their coresFor example, a SWM050 gives usCode:Valid ROM table presentComponent base address 0xe00ff000Peripheral ID 0x04000bb471Designer is 0x4bb, ARM Ltd.Part is 0x471, Cortex-M0 ROM (ROM Table)Component class is 0x1, ROM tableMEMTYPE system memory present on busI am not sure whether such is possible with JLink CommanderUpon connecting to a target set to "Cortex-M3" it givesCode:Connecting to target via SWDFound SW-DP with ID 0x1BA01477DPIDR: 0x1BA01477Scanning AP map to find all available APsAP: Stopped AP scan as end of AP map has been reachedAP: AHB-AP (IDR: 0x14770011)Iterating through AP map to find AHB-AP to useAP: Core foundAP: AHB-AP ROM base: 0xE00FF000CPUID register: 0x411FC231. Implementer code: 0x41 (ARM)Found Cortex-M3 r1p1, Little endian.FPUnit: 6 code (BP) slots and 2 literal slotsCoreSight components:ROMTbl @ E00FF000ROMTbl: E000E000, CID: B105E00D, PID: 001BB000 SCSROMTbl: E0001000, CID: B105E00D, PID: 001BB002 DWTROMTbl: E0002000, CID: B105E00D, PID: 000BB003 FPBROMTbl: E0000000, CID: B105E00D, PID: 001BB001 ITMROMTbl: E0040000, CID: B105900D, PID: 001BB923 TPIU-LiteIt does parse the ROM TABLE, but it only shows the addresses and the components. However, I don't know if and how to get more details about it.Since OpenOCD can communicate with a JLink adapter it can be used to identify the chips.Please be aware on Windows, it might require swapping the driver to WinUSB using Zadig (and back when you wish to use SEGGER's tools again)Sources for script :https://stackoverflow.com/questions/56951820/how-to-ping-a-chip-detect-if-a-chip-is-connected-with-openocdNotes: I have removed the shutdown at the end as it prevents the output being printed. Close openocd with CTRL+CEdit: Replaced CC2630 with SWM050, as the CC2630 does not support SWD.

author: ataradov
author_rank: Super Contributor
timestamp: June 16, 2020, 06:48:42 pm
content: ROM Tables are more empty than not from what I see.And they still don't really identify the part.Here are ROM Tables from Atmel SAM D10:Code:ROM Table:0: 0xfff0f003: address = 0xe000e000CID = 0xb105e00d, PID = 0x00000004000bb008DEVID0 = 0x00000000, DEVID1 = 0x00000000, DEVID2 = 0x00000000DEVARCH = 0x00000000, DEVTYPE = 0x00000000DEVAFF0 = 0x00000000, DEVAFF1 = 0x00000000AUTHSTATUS = 0x000000001: 0xfff02003: address = 0xe0001000CID = 0xb105e00d, PID = 0x00000004000bb00aDEVID0 = 0x00000000, DEVID1 = 0x00000000, DEVID2 = 0x00000000DEVARCH = 0x00000000, DEVTYPE = 0x00000000DEVAFF0 = 0x00000000, DEVAFF1 = 0x00000000AUTHSTATUS = 0x000000002: 0xfff03003: address = 0xe0002000CID = 0xb105e00d, PID = 0x00000004000bb00bDEVID0 = 0x00000000, DEVID1 = 0x00000000, DEVID2 = 0x00000000DEVARCH = 0x00000000, DEVTYPE = 0x00000000DEVAFF0 = 0x00000000, DEVAFF1 = 0x00000000AUTHSTATUS = 0x00000000This is basically the default Cortex-M0+ table with everything being designed by ARM (0x4bb).All Atmel chips are like this.It would be nice to have an entry in the ROM table that is in some universal format that clearly identifies the part. But my understanding is that there is some resistance from vendors to implement that.

author: josip
author_rank: Regular Contributor
timestamp: June 16, 2020, 09:20:07 pm
content: Quote from: ataradov on June 16, 2020, 04:07:51 pmI want to extend my MSP-GANG like flasher from MSP430 to ARM world (because hardware is already there). Not today, but I guess not in far future too, with support limited set of ARM target devices. I started from zero with my device guessing code because I didn't found anything else. When I back to it, I will check OpenOCD.C:\msp>flash -r 0 40Found master device at COM27Get Device# Cortex Var Rev SWDP APID Vendor Part3 M0+ 0 1 0BC11477 04770031 SL EFM32HG3224 M3 1 1 1BA01477 14770011 TI LM3S57495 M3 1 1 1BA01477 14770011 ST STM32F1xxRead#30000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ;0010: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ;0020: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ;0030: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ;#40000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ;0010: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ;0020: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ;0030: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ;#50000: 20000400 08000145 080002E7 080002DF ; ... E...š...-...0010: 080002E3 0800018D 0800045D 00000000 ; Ń...Ź...].......0020: 00000000 00000000 00000000 0800030D ; ................0030: 08000191 00000000 080002E9 080003F9 ; Ĺ.......Ú...¨...Release DeviceC:\msp>

author: ataradov
author_rank: Super Contributor
timestamp: June 16, 2020, 09:29:09 pm
content: The most reliable way is to have user specify the part number or at least a series. And I really see no situations where you are programming an unknown device that has to be detected automatically.But of course you can just look up the locations of device ID registers for common device vendors and series.Parsing ROM tables may give some initial idea, but again, it is not very reliable. You are still guessing.

author: dav888
author_rank: Regular Contributor
timestamp: June 26, 2020, 08:15:45 pm
content: the use case is when you have two different cpu's on one board and dont want to depend on hard coding segger serials in your build tools

author: ataradov
author_rank: Super Contributor
timestamp: June 26, 2020, 08:22:12 pm
content: Do you also have two programmers? This is strange. I can see this happening in production, but what is the problem with supplying a specific serial number? Usually production setup is fixed.Would not it be easier than implementing a logic of accessing a random debugger, reading the device type, and selecting an appropriate firmware image?If you at least know target devices, you can probe for predefined device-specific ID registers. If you know absolutely nothing about the target devices, it does not look like a realistic scenario.

author: dav888
author_rank: Regular Contributor
timestamp: June 27, 2020, 07:29:37 am
content: yes, I know which two or three device-types there is.problem with hardcodin the segger serials is that things break and get replaced, moved around, so it's nice not having to change the code everytime that happens.

author: ataradov
author_rank: Super Contributor
timestamp: June 27, 2020, 07:35:14 am
content: What tool do you use for programming though? You would still need to script connecting to two different programmers.In any case, for the devices you have, just looks up ID registers, or if there are no ID registers (pretty rare), some unique reset values for any register from any of the peripherals. That should be enough to reliably differentiate between a few target devices.Still, this is some pretty heavy scripting logic versus having someone edit the script with a fixed serial number when debuggers are moved.

author: dav888
author_rank: Regular Contributor
timestamp: June 27, 2020, 10:29:29 am
content: python and the segger libshavent seen any ways to do raw swd there without firing up gdb.. or am i missing something?

author: ataradov
author_rank: Super Contributor
timestamp: June 27, 2020, 07:30:01 pm
content: I have not worked with Segger and their libraries, but reading a memory location is a basic operation any debugger would support. And that's enough to do what you need.