Posts by hilamiranda

Thank you Simon, It seems like a very good starting point because "my" A35 is very much like this one, it's a Quad core but with only one cluster (this one has two).

Still I get the following error:

onnecting to target via JTAG
ConfigTargetSettings() start
ConfigTargetSettings() end - Took 26us
TotalIRLen = ?, IRPrint = 0x..FFFFFFFFFFFFFFFFFFFFFFF1
Failed to identify target. Resetting via Reset pin and trying again.
ConfigTargetSettings() start
ConfigTargetSettings() end - Took 10us
TotalIRLen = ?, IRPrint = 0x..FFFFFFFFFFFFFFFFFFFFFFF1
Error occurred: Could not connect to the target device.
For troubleshooting steps visit: https://wiki.segger.com/J-Link_Troubleshooting

Is it possible that my JLink Plus doesn't support A35?

Here is my script after modification:

__constant U32 _INDEX_AHB_AP_SYSTEM = 0; // AHB-AP connected to system bus with access to all peripherals etc.
__constant U32 _INDEX_APB_AP_CORTEX_A = 1; // Index of AP that identifies the APB-AP that is connected to the Cortex-A cores

__constant U32 _APB_ADDR_DBGREGS_A35_0 = 0x80090000;
__constant U32 _APB_ADDR_DBGREGS_A35_1 = 0x80092000;
__constant U32 _APB_ADDR_DBGREGS_A35_2 = 0x80094000;
__constant U32 _APB_ADDR_DBGREGS_A35_3 = 0x80096000;
//
// USER CONFIGURABLE
//
U32 _Index_APCore = _INDEX_APB_AP_CORTEX_A;
U32 _Addr_DBGREGS = _APB_ADDR_DBGREGS_A35_0;
const char* _sExecCTIBaseAddr = "CORESIGHT_SetCSCTICoreBaseAddr=0x80098000";

...

int ConfigTargetSettings(void) {
//
// Access Port map specfication
// Core type
// Access Port to use
// Specify core base address
// Specify CTI base address
//
JLINK_CORESIGHT_AddAP(0, CORESIGHT_AHB_AP);
JLINK_CORESIGHT_AddAP(1, CORESIGHT_APB_AP);
JLINK_CORESIGHT_AddAP(2, CORESIGHT_CUSTOM_AP);
JLINK_CPU = CORTEX_A35;
JLINK_CORESIGHT_IndexAPBAPToUse = _Index_APCore; // AP used as debug interface between J-Link and core to be debugged
JLINK_CORESIGHT_CoreBaseAddr = _Addr_DBGREGS; // Specify Coresight Core Debug Register address to use.
JLINK_ExecCommand(_sExecCTIBaseAddr); // Specify CoreSight CTI address to use.
return 0;
}

Hi,

I'm evaluation the use of JLink for ARM Cortex-A35 4CPU using JLink Plus.
Connection fails because it doesn't find CTI. I assume I need to manually set the addresses of the debug port, CTI, ETB, etc, but could not find any suitable command.

I could not find a useful example in the sample directory as well.

Is there a script file I can use as guidelines?

The next step is to test SDK based automation, so if you have any sample project it will be useful as well.

Thank you!
Hila

Hi Alex

Thank you for your response.

I understand that you recommend using AP, however the next solution is a spin-off, therefore the goal is to minimize the changes unless absolutely necessary.

In our current solution we have 2 Cortex-M4 chained. They can be used either in stand-alone debug or chained.
The Controller also has a Cortex-A35 (stand alone only)
The next solution has an additional core - RISC-V VeeR EL2

Therefore, we are still evaluating options to chain 3 processors (M4 x 2, RISC-V) - which actually means adding another CPU to the chain

Regarding SWD, We fully understand the benefits. Unfortunately our current implementation is based on “ARM Debug Interface v5 Architecture Specification (ADIv5)” and thus does not support multiple SWD in parallel.

We can say that chaining 2 M4 works very well, we are able to debug both cores, or a single core.

Do you see an issue with adding RISC-V Veer-EL2 to the chain in the next spin?
In other words, do you see any problem with chaining ARM V5 with RISC-V in the same chain, with separate TAPs

Another option was to chain the A35 with the RISC-V and keep the 2 M4.
It means that either A35 & RISC-V will be debugged stand-alone or both CPUs will be changed

If you can share any recommendation, please do,

Thank you and a happy new year
Hila

Thank you for your response

Unfortunately we don't have available IOs for more than two physical JTAG interfaces

The delay in TAP is predictable, I think we can live with it.
We are more concern with the effect of chained CPUs of the debug process.

On previous posts, there is a mention of CTI support.
Is it only for multicore in a single CPU or is it also a concern when chaining CPUs?

Thank you!

Hello Seggers

Is there any update on your plans to support CTI?

And another question:
We are designing a new Solution that has M4 cores, A35 and RISC-V.
We need to chain core and use up to JLink devices.
I already know that it is supported and I assume it is also supported by the SDK.

Do you have any recommendations, what would be a preferred distribution which allows us to debug cores simultaneously?

Thank you!

Please use the updated image of fail connection

Dear All

We are using a simulation of A9 core based on Cadence Palladium, its identical to working with an actual A9 core except for speed.

When connecting using 642d, the connection fails. See attached image for details.
However
When connecting using 500i, connection is successful . See attached image.

Can you think of a reason for the different behavior between the version.

Thanks
Hila, Nuvoton

There's a say in Hebrew: Always expect to repeat your mistakes

Many Thanks!

Hila

Hello

We ran into the following by chance:

We use JLINKARM_IsConnected in order to identify whether we have already established connection with the core (M4) or not.
However, I found out that calling this API immediately after a successful JLINKARM_Open command still reports false value.

Only after calling some other API functions, for example JLINKARM_ReadMemU32 or JLINKARM_SetSpeed(0) (set speed to '0'! Any other speed doesn't do the magic..) the call JLINKARM_IsConnected returns TRUE as it should.

We are using SDK version Setup_JLink_SDK_V502i_ARY4mOWs

attached is a sample code.

Thanks!
Hila

Hello

we are planning a PCB which has 4 M4 CPUs, all connected to one JTAG chain.
Is it possible to use one JLINK device to access all CPUs?

In addition, we use JLink SDK for automation. Can you explain how to use JLink SDK in order to communicate with all CPUs (assuming we close and open communication channel for each CPU)

For example, how to configure so that JLINKARM_Open communicates with a specific CPU.

Many Thanks!

Hila

Hello Niklas

Good news, I was not able to reproduce the failure using the new dll.

I tried a "synthetic" DLL open/close program and an exhaustive functional test and they both completed without the memory overflow.

Do you recommend that we move to the new DLL as production version? In any case, we are keeping one system alive with the new DLL and report if we encounter any problem.

Many thanks for all your efforts!

Hila

Hello Niklas,

Thank you for your update.

In that case we'll wait for the fixed SDK. Please let me know if we can be part of your beta-users to verify this fix.

Best Regards,
Hila

Hello once more,

Please let us know a target date for the release of the SDK?
Our support center assured us that Segger is currently working on a solution. This was about a month ago.
Please update on the target date for a release of an SDK with a fix.

Many Thanks!
Hila

Hello

Is there a target date for the release of the SDK with the fix?

Many Thanks!
Hila

Hello Alex,

I'm afraid we do not have support for SDK.
What do you suggest? What can be done for us to overcome this issue?

Thanks
Hila

Hello Roman,

Thank you very much for your efforts.

I'm afraid using only LoadLibrary and FreeLibrary only once is not an option. We use the JLink SDK as part of quite a large SW stack, which supports several cores, each may be accessed by several sources. We make sure all open/close tasks do not leave a trace so that other sources can access the same cores, etc.

However, we can do without the fix for a while longer, we made some ugly and creative workarounds to overcome this issue which allow us to complete a few hundreds of iterations before the crash.

I would like to know however an estimated time for next fixed release. Is it the SDK or the JLink DLL?

Will you notify me when the fix is available for download?

Many Thanks!

Hila

Thanks for your support,

As I wrote, we put this issue on hols for quiet a while by overcoming it is creative manners (reducing number of resets, partitioning of test package to sub-modules, and ugly solutions)

It's not urgent, we get-by, but I appreciate your support. We have quiet a few JLink based setups that suffer from it.

Please contact me if you need any more data.

Thanks!
Hila

Hello Eric,

we left this issue for quiet a while, but returned in an attempt to solve it once and for all. I'ts killing us!

I made some progress in isolating the problem, attached please find a zip containing a visual studio 2012 solution (ARM9_IFD.sln) which reproduces it.

The solution contains two projects:
*) ARM9_IFD - generates a ARM9_IFD.dll, a dll based on your SDK with two functions - core_open and core_close, which activate JLINKARM_Open() and JLINKARM_Close()
*) Jlink_test - a main program (executable) which loads the library ARM9_IFD, gets the processes for core_open and core_close that performs open and close using the DLL. The executable performs a loop of 0x300 calls to core_open and core_close.

After several iteration we get a windows error message (see win_error.jpeg) or access violation.

If I replace the call to ARM9_IFD.dll core_open and instead call JLINKARM_Open() from my executable (main.cpp line 56 which is commented out), there is no corruption.
This hints that perhaps the problem occurs only when using JLink SDK thru a DLL.

I executed the test with "Visual Leak Detector", which resulted in a terrible memory corruption (see vld_dump.jpg) and an endless dump of error messages.

Version in use:
JLinkArm.dll is taken from version 500i
JLink SDK is version 462

Please contact me about details on how to execute the test it it is not clear enough.

Many Thanks!
Hila

Dear All,

I encounter a memory allocation failure when using JLink SDK, I was wondering if you could shed some light on the source of it.

My program uses a DLL to communicate with ARM thru teh SDK. It opens/close connection to the core in an endless loop using (eventually) JLINKARM_Open() and JLINKARM_Close()

After ~450 iteration, I get a Windows error that it failed to allocate 0x00400000 bytes of memory, followed by the following JLINK 4.86a internal pop-up messages: TRACEBUF: could not alloc global buffer for trace data.

In an attempt to find the source of the problem I'm using visual leak detector which reports that the leak started at JLINKARM_PERIODIC _Control - which is a function I don't call at all.

Could you explain what is the source of the JLINK error message and how can I avoid it?

Many Thanks!
Hila Miranda-Kuzi

Hello Alex,

Thanks you for your response and for you explanation.

I moved to version 492, indeed the core is re-run after the read/write commands however I had quite a lot of problems when reading or modifying CSPR register thru the SDK.
.. I wonder if it's because of these fixes or perhaps I'm misusing it

To be on teh safe side, I added to our automatic system a Halt \ run command before read\write.

Thanks again,

Hila