[SOLVED] Multiple Core debugging and Cross Trigger

hilamiranda · Dec 5th 2023, 8:02pm

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!

SEGGER - Alex · Dec 6th 2023, 8:28pm

Hi,

Assuming that all of the cores are part of one chip / SoC, the best would be to have
1) the RISC-V ones behind an APB-AP
2) the A35 ones behind another APB-AP
3) The M4 ones behind one AHB-AP each

This would allow a JTAG independent design (would also work with SWD or cJTAG),
while chaining would limit you to JTAG and make things slower because each TAP adds overhead to the total length of a single JTAG access.

hilamiranda · Dec 6th 2023, 9:50pm

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!

SEGGER - Alex · Dec 11th 2023, 8:26pm

You probably misunderstood me.
I am NOT talking about multiple JTAG interfaces.
I am talking about exposing 1 JTAG interface (so 4 pins) or even better only 1 SWD interface (so 2 pins).

All cores would be accessible via the same DAP, just different APs.
It is a very common implementation in the ARM world and can be mixed with RISC-V as well.

For example, many of the bigger NXP i.MX devices have multiple M-cores, some A-cores and even some Xtensa cores in them and all is accessible by a single 2-pin SWD interface.
No JTAG chaining, so completely independent from JTAG, no chain overhead, …

hilamiranda · Jan 3rd 2024, 4:23pm

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

SEGGER - Alex · Jan 3rd 2024, 9:28pm

Hi Hila,

While I still recommend the DAP / AP method as it allows scaling and adding a next to unlimited number of cores,
I can see that keeping the changes minimal may be a desire.

I do not see any problems with either of your proposals.
Either chaining all (Cortex-M, A, RISC-V) in 1 chain or having the M cores in a separate one.
Both should be fine.

BR
Alex

Share