Debug Connection Error in ARM development studio

The error message:

Unable to connect to device ARMCS-DP

Is rather fundamental... this means that the tool is unable to successfully connect to the debug access port on the device.

Without knowing more about your design it is difficult to suggest a solution. Lowering the JTAG clock frequency is certainly something to try.

I suggest raising an official support request from the Support menu above if you wish Arm to investigate properly.

The error message:

Unable to connect to device ARMCS-DP

Is rather fundamental... this means that the tool is unable to successfully connect to the debug access port on the device.

Without knowing more about your design it is difficult to suggest a solution. Lowering the JTAG clock frequency is certainly something to try.

I suggest raising an official support request from the Support menu above if you wish Arm to investigate properly.

Hi Ronan
Thank you for the suggestion, finally it works with the lower frequency!
The problem that I have now is that I am trying to read/write the memory.
I have this error all the time.
I can easily work with the registers, but not the memory!

Glad to hear that you have made progress.

For the above, you are using the wrong command. It should be (something like):

memory set <verify=0>:0x20000000 0 0x12341234

See https://developer.arm.com/documentation/101471/6-4-0armds/Arm-Debugger-commands/Arm-Debugger-commands-listed-in-alphabetical-order/memory-set

For all the commands associated with memory access see https://developer.arm.com/documentation/101471/6-4-0armds/Arm-Debugger-commands/Arm-Debugger-commands-listed-in-groups/Memory-group

Thank you for the reply!

The command works but the memory seems to be not changing!

I tried it in my STM board and it works perfectly, but it is not the case for the bare-metal M7.

I suspect that it is maybe for the reason that CPU is held in reset (Handler).

You can see the result in the attached photo.

Setting the memory does not seem working, even if when the CPU is in stopped mode.
Is there any other way that I can check?
(You can see the picture below)

If you remove the verification qualifier, do you get an error? If so, what error do you see?

Thanks Ronan,
This is already fixed!

I have another question.
I am writing a simple C code and run it through ARM DS.
Although I can change the memory (Ex. memory set <verify=1>:0x2000ffff 0 0x0000BBBB) I cannot see any changes after the program runs.
I tried it in Reset, Running and Privileged modes when the JTAG is connected.

Here is my code:

#include <stdint.h>
#include <stdio.h>

int main(void) {

*((volatile uint32_t *)0x2000FFFF) = 0x0000BBBB;

return 0;
}

Worth mentioning that the base address is set 0x0 and the Cortex M7 that I have is a bare-metal and has no ROM.

Hi

My name is Stephen and I work at Arm.

Are you sure that your program starts and completes correctly?  To check, I suggest you place breakpoints at __main, main() and on the final "return 0", then run to each breakpoint in turn.  When compiling/debugging, use a low optimization level (e.g. -O0) as a starting point.

On reset, Arm processors in general need to execute some startup code to setup the Stack Pointer, vector table, MPU, etc.  Do you have any startup code?

Please take a look at the ready-made Examples that are provided in Arm DS.  There is an example for Cortex-M7 named "startup_Cortex-M7_AC6".  This starts a timer by writing to a volatile memory-mapped register, in a similar way to what you are trying now.

You can import the examples into your workspace as follows:

1. Select File > Import... to open the Import Selection dialog
2. Expand the Arm Development Studio group and select Examples and Programming Libraries [Next]
3. Expand the Examples group to view the example categories
4. Either select one (or more) of the example categories to import, or expand the example categories to view/select individual examples in each category.  You can also search for e.g. "startup_Cortex-M7_AC6".
5. Click Finish to import the selected examples into your workspace.

Hope this helps

Stephen

Hi Stephen 
We are working on a custom built bare-metal ARM Cortex M7 processor.
These examples are beneficial but they are not tailored to our design specifications.
Can you tell us what is the difference between SMM-M7 and SMM-M7CS in Arm/Cortex-M Prototyping System (MPS2)/ ?

To repeat my colleagues comments... are you sure that your code is reaching main()?

A common issue is if you compile your code with FP support, but you have not enabled the FP hardware (which you must do manually in your initialization code).

This results in a fault in the _fp_init() function (part of the C library init code). Try compiling your code explicitly without FP.

Apologies, I should correct my earlier reply.

CS refers to the presence of CoreSight SoC-400 in that design.

https://developer.arm.com/Processors/CoreSight%20SoC-400

See section 8 of AN399:

https://developer.arm.com/documentation/dai0399

Thank you Ronan for all good information provided!

I followed the steps and I can read/write to ITCM and DTCM.
There is only one issue left I assume, which is the shared memory between the CPU and other IPs with the address 0x60000000.
When I want to read/write to this memory, I get this error:

Here is memory information;

Hi again

There are various reasons why the debugger might be unable to read the memory/peripheral at that addresses, for example:

* the peripheral might be powered-down

* the peripheral might need to be explicitly enabled before use

* the MPU might be blocking access to that address

* the memory/peripheral might be inaccessible/disabled for the current processor mode or security state (e.g. some memory/peripherals are only accessible in secure state)

* the memory/peripheral might require a certain access width, e.g. 8-, 16- or 32-bit access.
For example, to read a word with a 16-bit (LDRH) access, you can use:
x /w <width=16>:0x60000000

You'll need to check the specification for your target to investigate what might be preventing the access.

Stephen

Hi Stephen

We realized it was the problem that you mentioned (peripheral might need to be explicitly enabled before use), and the issue is solved now.
Thank you and Ronan for your kind cooperation.

Thanks for letting us know.
If you could mark this thread as Answer Accepted, that'd be appreciated.
Hope your product development now continues smoothly.

Stephen