Support for Silicon Labs MGM210P modules (EFR32MG21) cortex-m33

[lucagessi]

Hi. I started using black magic probe (stlink clone converted) some times ago. The main reason is because for every type of microntroller/manufacturer we have a different programmer/debugger and it is very annoyng.

We use in a recent project a module by Silicon Labs, MGM210P0, and MGM210PA. BMP recognises that the board has a cortex-m33 but it cannot flash, erase ecc. Below the output using blackmagic -t linked to a stlink-BMP:

BMP hosted (BMP Only) v1.7.1-335-g5c07d61
Using:
 Black Magic Probe (Unknown)  V2__v1.7
Running in Test Mode
Target voltage: 2.37V Volt
Speed set to  3.2727 MHz for SWD
Trying old JTAG to SWD sequence
TARGETID 01c016e7
DPIDR 0x6ba02477 (v2 rev6)
RESET_SEQ failed
AP   0: IDR=84770001 CFG=00000000 BASE=e00fe003 CSW=43800040 (AHB-AP var0 rev8
Halt via DHCSR: success 00130003 after 4ms
ROM: Table BASE=0xe00fe000 SYSMEM=0x00000001, designer 673 Partno c01
ROM: Table BASE=0xe00ff000 SYSMEM=0x00000001, designer 43b Partno 4c9
 0 0xe000e000: Debug component - Cortex-M33 (System Control Space) (PIDR = 0x04000bbd21  DEVTYPE = 0x00 ARCHID = 0x2a04) -> cortexm_probe
CPUID 0x410fd213 (M33 var 0 rev 3)
 1 0xe0001000: Debug component - Cortex-M33 (Data Watchpoint and Trace) (PIDR = 0x04000bbd21  DEVTYPE = 0x00 ARCHID = 0x1a02)
 2 0xe0002000: Debug component - Cortex-M33 (Breakpoint Unit) (PIDR = 0x04000bbd21  DEVTYPE = 0x00 ARCHID = 0x1a03)
 3 0xe0000000: Debug component - Cortex-M33 (Instrumentation Trace Macrocell) (PIDR = 0x04000bbd21  DEVTYPE = 0x43 ARCHID = 0x1a01)
 4 Entry 0xfff41002 -> Not present
 5 0xe0041000: Debug component - Cortex-M33 (Embedded Trace) (PIDR = 0x04002bbd21  DEVTYPE = 0x13 ARCHID = 0x4a13)
 6 0xe0042000: Debug component - Cortex-M33 (Cross Trigger) (PIDR = 0x04000bbd21  DEVTYPE = 0x14 ARCHID = 0x1a14)
 7 Entry 0xfff44002 -> Not present
 ROM: Table END
1 0xe0040000: Debug component - Cortex-M33 (Trace Port Interface Unit) (PIDR = 0x04000bbd21  DEVTYPE = 0x11 ARCHID = 0x0000)
remote_ap_mem_read returned REMOTE_RESP_ERR at apsel 0, addr: 0xe00fdff0
remote_ap_mem_read returned REMOTE_RESP_ERR at apsel 0, addr: 0xe00fdff4
remote_ap_mem_read returned REMOTE_RESP_ERR at apsel 0, addr: 0xe00fdff8
remote_ap_mem_read returned REMOTE_RESP_ERR at apsel 0, addr: 0xe00fdffc
CIDR read timeout on AP0, aborting.
ROM: Table END
AP   1: IDR=54770002 CFG=00000000 BASE=00000003 CSW=80000040 (AHB-AP var0 rev5
AP   2: IDR=84770001 CFG=00000000 BASE=f0000003 CSW=43800000 (AHB-AP var0 rev8
remote_ap_mem_read returned REMOTE_RESP_ERR at apsel 2, addr: 0xf0000ff0
remote_ap_mem_read returned REMOTE_RESP_ERR at apsel 2, addr: 0xf0000ff4
remote_ap_mem_read returned REMOTE_RESP_ERR at apsel 2, addr: 0xf0000ff8
remote_ap_mem_read returned REMOTE_RESP_ERR at apsel 2, addr: 0xf0000ffc
CIDR read timeout on AP2, aborting.
remote_ap_mem_write_sized returned REMOTE_RESP_ERR at apsel 0, addr: 0xe000ef54
remote_ap_mem_write_sized returned REMOTE_RESP_ERR at apsel 0, addr: 0xe000edf4
*** 1 Unknown ARM Cortex-M Designer 673 Partno c01 M33

Thank you

[UweBonnes]

EFR devices are handled in target/efm32.c. efm32_probe() is already called, but already the test for the core will fail. Compare the code with what the new device expects. Compare reference manual. If there are substantial similarities, change/add code in little steps and test. Running hosted for that will spare you constant firmware reflash. But maybe the similarities are very small, so perhaps a who new target file is the better approach. Do other open source debuggers already support the MGM or a similar EFR chip? Maybe get some inspriration there too.

But the CIDR read timeout is bad. It seems, some access restrictions are already implemented in your code. Try on an empty device or with minimal code with no protection, no M33 features. Here both STM32L5 and U5 read CIDR fine.

[lucagessi]

I use a development board by Silicon Labs with the programmer inside, so I don't know if a compatible probe exists. There is some documentation for developer? Maybe some docs that you may suggest in order to try to resolve this issue? Thank you

[UweBonnes]

Probably the Silicon Labs has a CMSIS DAP programmer. BMP Hosted onl Linux can easy talk to that dongle.On windows, libusb must be able to find the programmer, so the ZADIG https://zadig.akeo.ie/ is needed. The documents for developpers are the reference manuals, the code and the git history. Do you perhaps already have experience with a MCU already supported. Perhaps you even wrote some code to update the flash? Compare how that is implemented in BMP to the implementation in your old code.

[perigoso]

this is a slight mislabeling of the issue, the MGM210P is the module reference, the soc used internally is the EFR32MG21, which is indeed not supported