Open kmeinhar opened 1 year ago
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
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?
The 3 important locations to go checking are:
for the normal Flash controller, then https://github.com/blackmagic-debug/blackmagic/blob/c69bf52da39e35589248a973d0b0f8ff561f4859/src/target/efm32.c#L933
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
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.
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.
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.
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 :)
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 :)
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.
Hi @kmeinhar!
The link for the draft pull request: https://github.com/blackmagic-debug/blackmagic/pull/1436
Hope it can be somehow helpful :)
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 inefm32_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?