Not able to read from Flash On EFM32PG22 Series 2 MCU

[kmeinhar]

I have a similar problem as issue #759 . But I was not able to resolve it with the suggested solution of running the BMP in hosted mode.

Below you can see that the ROM table is correctly read and efm32_probe is called. In there I tried to read the Device Information register and some Peripheral Register but all target_mem_read32 calls just return 0.

Calling target_halt_resume(t, 0) also did not change this behavior.

The second AP (AP 1: IDR=54770002 ) is a Debug Challenge Interface (DCI Documentation) and I verified that it does not have the Debug Lock set. For me it sounds like DCI is the successor of the EFM32 Authentication AP that is implemented in efm32_aap_probe.
I have some rough code for handling the DCI that I could upstream when I can confirm debugging works on PG22.

I am currently a bit lost what else to try to make reading the Flash work. Are there any hints on what could be preventing me from reading flash. Or better ways of testing what fails?

$ make PROBE_HOST=hosted BMP_HOSTED_ONLY=0 && sudo ./src/blackmagic -t
 GEN include/version.h
  CC      command.c
  CC      target/efm32.c
  CC      remote.c
  CC      platforms/hosted/cli.c
  CC      platforms/hosted/bmp_remote.c
  CC      platforms/hosted/bmp_libusb.c
  LD      blackmagic
Black Magic Debug App v1.8.0-709-g5092cd14-dirty
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, JLink and libftdi/MPSSE
Using 1d50:6018 98B6C98B Black Magic Debug
 Black Magic Probe  v1.8.2
Running in Test Mode
Target voltage: 3.3V Volt
Speed set to  3.2727 MHz for SWD
remote_target_clk_output_enable failed, error 1
scan_multidrop: true
DP DPIDR 0x6ba02477 (v2 rev0) designer 0x43b partno 0xba
26016e7
TARGETID 0x026016e7 designer 0x673 partno 0x2601
Please update BMP firmware for substantial speed increase!
DONE?
RESET_SEQ failed
AP   0: IDR=84770001 CFG=00000000 BASE=e00fe003 CSW=43800040 (AHB-AP var0 rev8)
Halt via DHCSR: success 05130003 after 213ms
ROM: Table BASE=0xe00fe000 SYSMEM=0x00000001, Manufacturer 673 Partno 601
ROM: Table BASE=0xe00ff000 SYSMEM=0x00000001, Manufacturer 43b Partno 4c9
 0 0xe000e000: Debug component - Cortex-M33 (System Control Space) (PIDR = 0x00000004000bbd21  DEVTYPE = 0x00 ARCHID = 0x2a04)
 -> cortexm_probe
CPUID 0x410fd214 (M33 var 0 rev 4)
Calling efm32_probe
fe08000: 0
fe08004: 0
fe081fc: 0
Reading CMU CLKEN1 0
Reading CMU IPVER 0
Reading EMU DECBOD 0
Reading EMU Status 0
Please report unknown device with Designer 0x673 Part ID 0x2601
 1 0xe0001000: Debug component - Cortex-M33 (Data Watchpoint and Trace) (PIDR = 0x00000004000bbd21  DEVTYPE = 0x00 ARCHID = 0x1a02)
 2 0xe0002000: Debug component - Cortex-M33 (Breakpoint Unit) (PIDR = 0x00000004000bbd21  DEVTYPE = 0x00 ARCHID = 0x1a03)
 3 0xe0000000: Debug component - Cortex-M33 (Instrumentation Trace Macrocell) (PIDR = 0x00000004000bbd21  DEVTYPE = 0x43 ARCHID = 0x1a01)
 4 Entry 0xfff41002 -> Not present
 5 0xe0041000: Debug component - Cortex-M33 (Embedded Trace) (PIDR = 0x00000004002bbd21  DEVTYPE = 0x13 ARCHID = 0x4a13)
 6 0xe0042000: Debug component - Cortex-M33 (Cross Trigger) (PIDR = 0x00000004000bbd21  DEVTYPE = 0x14 ARCHID = 0x1a14)
 7 Entry 0xfff44002 -> Not present
 ROM: Table END
1 0xe0040000: Debug component - Cortex-M33 (Trace Port Interface Unit) (PIDR = 0x00000004000bbd21  DEVTYPE = 0x11 ARCHID = 0x0000)
ROM: Table END
AP   1: IDR=54770002 CFG=00000000 BASE=00000003 CSW=80000040 (AHB-AP var0 rev5)
*** 1 Unknown ARM Cortex-M Designer 673 Part ID 2601 M33
remote_target_clk_output_enable failed, error 1
remote_target_clk_output_enable failed, error 1

[dragonmux]

Thank you for an excellently clear issue report! The current EFM32 support is for the Series 1 MCUs as best we can tell, making your part a new target.

This would explain why certain things are broken but not others. This gives us a couple of options for how to deal with these new parts - we can either try and extend the existing EFM32 support for the parts (this needs the Flash controllers to be virtually identical), or we can look at building new probe and Flash routines.

The debug trace provided is especially helpful as this is showing that the part is using a Silicon Labs/EFM32 specific JEP-106 manufacturer code which simplifies how detection would traverse cortexm_probe() and it appears like the part is fully working on an ADIv5 and Cortex-M layer level, meaning the work needed is "only" probe (detection) and Flash routines + any special considerations needed for that DCI AP

Contribution of DCI AP code would be most welcome, as would any of the components mentioned above

[kmeinhar]

Thank you @dragonmux for your quick and detailed response!
As far as I can tell extending existing EFM32 support should be possible. The DCI documentation in AN1303 is not clear but states:
Program the Series 2 flash memory by writing directly to the device's Memory System Controller (MSC) registers over the Serial Wire Debug (SWD) interface. This method is simple and easy to upgrade to support new Series 2 devices.
To me this implies that it is close enough to Series 1 devices.

Could you tell me code locations where I would investigate potential problems in the flash routines?

One other hint the DCI documentation provides is:
The program must set the MSC bit in the CMU CLKEN1 register (if available) to enable the clock source for the Memory System Controller (MSC).
The problem is that CMU (Clock management Unit) registers are also not accessible.
Do you know of any other peripherals or components that I might need to enable to access flash?

[dragonmux]

The 3 important locations to go checking are:

blackmagic/src/target/efm32.c

Line 598 in c69bf52

static bool efm32_flash_erase(target_flash_s *f, target_addr_t addr, size_t len)

blackmagic/src/target/efm32.c

Line 639 in c69bf52

static bool efm32_flash_write(target_flash_s *f, target_addr_t dest, const void *src, size_t len)

and

blackmagic/src/target/efm32.c

Line 666 in c69bf52

static bool efm32_mass_erase(target_s *t)

for the normal Flash controller, then

blackmagic/src/target/efm32.c

Line 933 in c69bf52

bool efm32_aap_probe(adiv5_access_port_s *ap)

for the AAP vs DCI controller differences

We would be checking if the MSC access patterns line up with the datasheet descriptions, if the bits written to control the MSC match up, and if the Flashing stub used (https://github.com/blackmagic-debug/blackmagic/blob/c69bf52da39e35589248a973d0b0f8ff561f4859/src/target/flashstub/efm32.c) is fit for purpose

[kmeinhar]

Thanks again, I will have a look at those locations! It might just take a while because I have to work on another project first.
I will update this issues when I know more.

[joaopedrovbs]

Hello everyone, I can confirm the same results as @kmeinhar, and have already started the development of a new target heavily based on the efm32 implementation, for the EFR32FG23Bxxx series 2 device.

For me, the use of target_mem_read32(t, 0xfe08000) for reading the DI (Device Information) fails as in @kmeinhar's log, outputing all zeros, meaning that there's some other thing that we have to do in order to access the Device Information and other registers correctly.

From my point of view the DCI is the main thing here, as it is "the new" aap for this devices that are "more secure". AN1303 has some information on how to proceed using DCI at least for programming, will report here if I find anything new.

[kmeinhar]

Thanks for the investigations @joaopedrovbs !
Sadly I was not again able to work on this project.
Currently our work around is to use EFM32PG22 Dev Kit from Silabs (~20€ in Europe) and removing the PG22 chip on it. The 10 Pin debug connector can than be used to connect to a PG22 on our custom PCB.
Might be worth a try to put a probe on the SWD interface and see what is send there during setup.

[maak184]

Hi guys! I've been working on this issue with @joaopedrovbs and we finally could make it work

It seems actually that the setup of the access port on the configuring of the CSW register is not right. We did just as you suggested @kmeinhar and probed the SWD interface from a programmer we have here. Looking carefully at the transactions, I could see a completely different CSW value from the one was being setting up. So we hard coded the same value 0x23000012 and give it a try and suddenly we were able to read and write on the flash. It seems to me that the main reason was the DeviceEn bit, that was not set for the value we were obtaining , but still need further investigation.

As we are working with the EFR32FG23, it was still necessary to remap all the registers once the addresses from the previous versions are completely different from this one. At the moment we are already able to access de device info, erase and flash our program on the device (we still need to test more the debug features but it seems to be working), however was necessary to make some changes to manage those features also.

The first thing was to code a direct stage for flashing code at flash without using the flashstub. We were not able to make it work with the stub so we coded a direct flash (As instructed on the AN1303 from Silabs). The second thing is that I needed to comment the reset section on the target_enter_flash_mode at target_flash.c cause after the reset I could not manage to read or write at the register anymore. We are still investigating this issue.

Of course, all of this is for flashing and accessing the device without any secure feature. At the moment we won't be working on those features, however it is a near future work.

As soon we clean the code, we make a pull request for the new target. @kmeinhar hope you find this new info helpful :)

[kmeinhar]

Thanks for the investigations @maak184 ! Could you create a merge request with your changes? Even as a draft I could try to evaluate that in a free minute and give you some feedback :)

[dragonmux]

The first thing was to code a direct stage for flashing code at flash without using the flashstub. We were not able to make it work with the stub so we coded a direct flash (As instructed on the AN1303 from Silabs). The second thing is that I needed to comment the reset section on the target_enter_flash_mode at target_flash.c cause after the reset I could not manage to read or write at the register anymore. We are still investigating this issue.

You have two choices here - the first is to set CORTEXM_TOPT_INHIBIT_NRST on the target_s member target_options, and the second is to provide your own target Flash mode entry/exit routines that do suitable target-specific steps. This is a good example of the exact design use case the target structure hooks exist for.

Depending on the exact way the target stops responding though will change which to try: for example giving remote protocol response E104 or E703 (depending on JTAG vs SWD) on DHCSR read immediately after the nRST sequence indicates that the physical nRST pin resets the test logic too and so must be inhibited.

[maak184]

Hi @kmeinhar!

The link for the draft pull request:
#1436

Hope it can be somehow helpful :)