Hi experts,
my company is considering transitioning from uVision to Arm Development Studio.I'm currently evaluating this using the 30 day trial by recreating our current setup.
I'm now trying to download and debug code on the MCU using the built-in CMSIS-DAP and an ST-LINK.But when trying to debug, the process just fails without any apparent error after the autodetection. No error is present in the main log.
I originally noticed the behavior with a custom board using an STM32H745IIK6 and an ST-LINK V2 but have since than verified the issue is also present with the same setup and an ST-LINK V3, a second custom board using an STM32H745IIT6 and both ST-LINK V2 and V3 and the STM32H747I-DISCO (STM32H747XI6H) board using the internal ST-LINK V3.
The PCE Log looks okay but includes a warning and an error:
[19/05/21 10:57:12] WARNING - Multi-drop SWD is not supported, a single DAP on the scanchain has been assumed.[19/05/21 10:57:13] Failed to read registers to identify component: Failed to read 16 bytes from address 0xE00F0FF0 on CSMEMAP_2When I try "Target Configuration", the autodetect fails with an error
[19/05/21 10:57:12] WARNING - Multi-drop SWD is not supported, a single DAP on the scanchain has been assumed.
[19/05/21 10:57:13] Failed to read registers to identify component: Failed to read 16 bytes from address 0xE00F0FF0 on CSMEMAP_2
But that isn't helping much either... The PCE is showing the same output as it does when I try to debug.
At leats in this case, the main log includes a callstack:
!ENTRY com.arm.debug.cmsis 4 0 2021-05-19 11:03:42.538 !MESSAGE Failed to automatically detect what devices are present !STACK 0 com.arm.pce.exceptions.DSDetectException: Failed to automatically detect what devices are present at com.arm.debug.cmsis.launch.LaunchDelegate.autodetectWrapper(LaunchDelegate.java:486) at com.arm.debug.cmsis.launch.LaunchDelegate.setupConfigFiles(LaunchDelegate.java:401) at com.arm.debug.cmsis.launch.CMSISLaunchTab$3.widgetSelected(CMSISLaunchTab.java:240) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:252) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4105) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1037) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3922) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3524) at org.eclipse.jface.window.Window.runEventLoop(Window.java:823) at org.eclipse.jface.window.Window.open(Window.java:799) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.open(LaunchConfigurationsDialog.java:1240) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationPropertiesDialog.open(LaunchConfigurationPropertiesDialog.java:186) at org.eclipse.debug.ui.DebugUITools.openLaunchConfigurationDialog(DebugUITools.java:708) at com.arm.debug.launcher.DebugConfigurationLauncher.lambda$0(DebugConfigurationLauncher.java:23) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3897) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3527) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1160) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1049) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:658) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:557) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:154) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:150) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:657) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:594) at org.eclipse.equinox.launcher.Main.run(Main.java:1447)
What am I doing wrong? At least accoridng to the PCE Log everything relevant is detected and working correctly.
Debugging using the same setup works without issues in Keil's uVision.
Thanks in advance!Sven
Hi SvenThanks for trying out Arm Development Studio! Sorry to hear that you've hit this problem.The warning about Multi-drop SWD isn't the issue here, but the errorFailed to read registers to identify component: Failed to read 16 bytes from address 0xE00F0FF0 on CSMEMAP_2may be the cause of the problem.You don't say which type of processor/board you are trying to connect to, but this problem is best investigated as a Support Case with Arm, so that Arm support and engineering teams can properly investigate.Please open a Support Case using the "Support > Open a Support Case" option at the top of this page, including more details such as the processor/board you are trying to connect to, and the full failing PCE log.Hope this helps,Stephen
Hi Stephen.
Thanks for your quick response! I did as you suggested.
But to clarify: I originally noticed the behavior with a custom board using an STM32H745IIK6 and an ST-LINK V2 but have since than verified the issue is also present with the same setup and an ST-LINK V3, a second custom board using an STM32H745IIT6 and both ST-LINK V2 and V3 and the STM32H747I-DISCO (STM32H747XI6H) board using the internal ST-LINK V3.
I also added this information to the opening post.
Hi Sven,
while I'm using the Arm DSTREAM-ST for debugging various STM32 boards; I always used the pre-configuration which are part of the post install packages; theses packages also provide FLASH programming. Currently I don't have access to and ST-ULINK v2/v3 and therefore cannot test it. I've forwarded the information to the engineering team for analysis.
Thank you very much,
Robert
Hi Robert,
thank you for your quick response! What you describe is exactly what I tried to use.
I'm currently in homeoffice and don't have access to other debuggers here. I'll make sure to at least try a J-Link soon but don't have access to a DSTREAM-ST. In the meantime, I could properly connect to an STM32F4 and an NRF52840 so this issue seems to be specific to the H7 series of dual-core MCUs (maybe alsothe single core versions but I can not test this).
Do you have access to a STM32H74x/75x, i.e., a dual-core model to check if it works with the DSTREAM-ST?
Development Studio gives me two possible debug configurations:
The second works (altough I would need to provide my own programming algoriithm), the first fails to generate its "platform.sdf" and silently fails (at least that's what my findings show).
By having a close look at what Development Studio (and expecially the com.arm.debug.cmsis module that is causing the error) is doing different if it works,I have since found a workaround:
While this works, it is annoying that the auto detection does not seem to be able to automatically generate this file (when it is obviously supposed to do this and is failing without it).
I will leave this here for future reference but definitely hope that that this bug can be fixed.
Best Regards,
Sven