Search Results
Search results 1-20 of 35.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
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…
-
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 :D 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 sh…
-
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 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…
-
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 pro…
-
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 …
-
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
-
Hi Is it mandatory for the A9 core to be aborted before writing to an address or a core register? we noticed that if we attempt to write to a register or any address while the core is running the writing is performed successfully however the core state is halted. We also see that if interrupts were enabled in the CPSR register, after the write the CPSR interrupt state is now disabled. We are using jlink SDK for Core\Host communication. The workaround we found is to add Abort before each operatio…