[ABANDONED] J-Link+ problem connecting to Raspberry Pi 3

    Hello, I have been following a help page on sysprog s website to try JTAGging into my RPi3 (B+) for the last week. I am trying to find whether J-Link+ even supports cortex-a7 (a53 would be even better, but I'll settle for working). I documented my steps and the problem on my blog entry , but here's where I am stuck (recap).

    When using JLinkGDBServer (on Ubuntu 16.04 running in Parallels Desktop): just connection failure.
    When using JLinkExe, and choosing CORTEX-A7, JTAG, 4000 KHz:


    When connecting from OpenOCD

    As you can see in the screenshot of the logic analyzer, TDI and TDO are moving, so I am guessing that the RPi GPIO pin mapping worked. I am attaching the Saleae Logic capture of the session (please unzip), which will have the full JLinkExe connection failure record. I am running the beta version of the SEGGER JLink tools, as you can see below:

    Code
    parallels@ubuntu:~/rpi/linux$ JLinkExe -v
SEGGER J-Link Commander V6.21a (Compiled Sep 29 2017 16:47:39)
DLL version V6.21a, compiled Sep 29 2017 16:47:34

    I've never had a problem with my J-Link+, but this is the first time I've tried JTAG (always SWD before). I also tried SWD against my RPi3, but no reply from the ARM core to the SWD reset. At least with JTAG, the target is responding to reset.

    Any hints please?

    Hi,


    Cortex-A53 is currently not supported by J-Link. Support for ARMv8 64-bit is planned for end of the year-Q1/2018, but only for J-Link ULTRA+ v4 or higher.
    Cortex-A7 is not supported by J-Link V8, see https://wiki.segger.com/Software_and_H…atures_Overview .

    I am not sure how debugging is supposed to work when selecting Cortex-A7 as the core. Is their some kind of compatibility ?

    Best regards,
    Niklas

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

    Hi,

    It seems very unlikely to me that they are still selling v1.
    In case of doubt, I would ask them via mail / phone if they can tell you the hardware version or the first 4 digits of a serial number.

    As an alternative, it is possible to order directly from SEGGER:

    http://shop.segger.com/J_Link_ULTRA_p/8.16.28.htm [EU]
    http://shop-us.segger.com/J_Link_ULTRA_p/8.16.28.htm [US]

    Best regards,
    Niklas

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

    Have not found an information so far what would happen if I tried to specify Cortex-A7 to JLinkExe against Cortex-A53 chip (like the BCM2837 on RPi3) using JLink+ v9. Do I have to know the internals of J-Link to figure this out, or is there some ARM document that will answer this question?

    Thanks for reading.

    Hi,

    Quote

    if I tried to specify Cortex-A7 to JLinkExe against Cortex-A53 chip (like the BCM2837 on RPi3)


    As I said before, and do not see how this is supposed to work.
    Cortex-A53 has different and more registers, and is most likely different in many other ways (I myself have not yet worked with Cortex-A53).

    Quote

    What does Cortex-A7 mean to JLinkExe?


    Specifying a core to the J-Link software allows the J-Link to make assumptions necessary to connect to the target and allow basic debugging (like halt, go, read / write memory), based on information like register count/length, addresses of generic debug registers etc....

    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?

    Best regards,
    Niklas

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

    The RPi2 I had ordered arrived, and I got a J-Link+ v9.3. Still doesn't work. I also attached the Saleae logic capture data. TDO and TDI are hopping, and you can apparently talk to the chip. But still no connection.

    Can you please suggest what I should try? Thank you.

    $ JLinkExe
    SEGGER J-Link Commander V6.21a (Compiled Sep 29 2017 16:47:39)
    DLL version V6.21a, compiled Sep 29 2017 16:47:34

    Connecting to J-Link via USB...O.K.
    Firmware: J-Link V9 compiled Sep 26 2017 17:01:02
    Hardware version: V9.30
    S/N: 609302643
    License(s): RDI, FlashBP, FlashDL, JFlash, GDB
    VTref = 3.285V
    ...

    Device "CORTEX-A7" selected.

    Connecting to target via JTAG
    TotalIRLen = 4, IRPrint = 0x01
    JTAG chain detection found 1 devices:
    #0 Id: 0x4BA00477, IRLen: 04, CoreSight JTAG-DP
    ARM AP[0]: 0x24770002, APB-AP
    ROMTbl[0][0]: CompAddr: 80010000 CID: B105900D, PID:04-004BBD03
    ROMTbl[0][1]: CompAddr: 80011000 CID: B105900D, PID:04-004BB9D3
    ROMTbl[0][2]: CompAddr: 80012000 CID: B105900D, PID:04-004BBD03
    ROMTbl[0][3]: CompAddr: 80013000 CID: B105900D, PID:04-004BB9D3
    ROMTbl[0][4]: CompAddr: 80014000 CID: B105900D, PID:04-004BBD03
    ROMTbl[0][5]: CompAddr: 80015000 CID: B105900D, PID:04-004BB9D3
    ROMTbl[0][6]: CompAddr: 80016000 CID: B105900D, PID:04-004BBD03
    ROMTbl[0][7]: CompAddr: 80017000 CID: B105900D, PID:04-004BB9D3
    TotalIRLen = 4, IRPrint = 0x01
    JTAG chain detection found 1 devices:
    #0 Id: 0x4BA00477, IRLen: 04, CoreSight JTAG-DP

    ****** Error: Cortex-A/R-JTAG (connect): Could not determine address of core debug registers. Incorrect CoreSight ROM table in device?
    TotalIRLen = 4, IRPrint = 0x01
    JTAG chain detection found 1 devices:
    #0 Id: 0x4BA00477, IRLen: 04, CoreSight JTAG-DP
    TotalIRLen = 4, IRPrint = 0x01
    JTAG chain detection found 1 devices:
    #0 Id: 0x4BA00477, IRLen: 04, CoreSight JTAG-DP
    Cannot connect to target.

    Hello Henry,

    The chip used by the Raspberry PI 2 is currently not supported by J-Link.
    All supported devices by J-Link are listed here: https://www.segger.com/downloads/supported-devices.php

    Passing a generic A7-Core to J-Link for a quad core device is optimistic at best.
    For nearly all multi-core device the J-Link supports special connect handling is necessary.
    Unfortunately there have been barely any inquires for supporting that specific devices so it is unlikely that support will be added by us.

    There are two options for users here:
    1. You can add support yourself, more information can be found here: https://wiki.segger.com/Adding_Support_for_New_Devices
    2. You pay us NREs to implement support

    Examples for Connect Scripts can be found in the J-Link Software package install directory under /Devices.

    Best regards,
    Nino

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

    Thanks for the tip, Nino. Can you please help me with my confusion. Naklas and you both say you don't support the BCM2835,2836,2837 SoCs for the RPi. I thought I understood that, but then I found forum posts (just search for "raspberry") where people report success, and Niklas says it worked for him just last month. It seems that JLinkExe was used to connect to the target. Given that I am trying to do the same thing (connect to the target with JLinkExe or JLinkGDBServer) why would Niklas say it's not supported? Maybe you just mean that it may works but you just don't support it?

    And to add to my confusion, I don't understand why you are referring me to the page that discusses flashloader. On RPi, the SD card is the non-volatile memory, so there is no flash to download to. Besides, you don't even need that to do basic source code debugging, right? You just need to issue debug control commands to the ARM debug core through JTAG?

    I found posts where people are (trying?) to use Open-OCD against RPi2/3. I LOVE JLink debug interface (including Ozone) so I am willing to do some work to get JLink based tools to work against RPi 2/3. If you can please point me to a more relevant user guide/doc, perhaps I can understand better what you guys are saying.

    Hello Henry,

    Quote

    Naklas and you both say you don't support the BCM2835,2836,2837 SoCs for the RPi. I thought I understood that, but then I found forum posts (just search for "raspberry") where people report success, and Niklas says it worked for him just last month.

    Can you point me to the post you are referring to? I was not able to find it. Alternatively i will ask Niklas, but he is out of office will Thursday.

    Quote

    Maybe you just mean that it may works but you just don't support it?

    It will definitely work with the correct connect steps through a script file. But it is not supported to work natively with our J-Link. Currently the user has to take care about the correct connect sequence.

    Quote

    And to add to my confusion, I don't understand why you are referring me to the page that discusses flashloader. On RPi, the SD card is the non-volatile memory, so there is no flash to download to. Besides, you don't even need that to do basic source code debugging, right? You just need to issue debug control commands to the ARM debug core through JTAG?

    Sorry if i was not exactly clear with my last post. Naturally the Cortex-A core does not have internal flash. But in the wiki article it is described how support for new devices can be added.
    Basically what you need to do is edit the JLinkDevices.xml in the J-Link install folder. Then create a JLinkScriptfile and define the function InitTarget();
    Populate it with the device specific connect steps and set it in the JLinkDevices.xml.

    More information can be found int he J-Link user manual.

    Quote

    I found posts where people are (trying?) to use Open-OCD against RPi2/3. I LOVE JLink debug interface (including Ozone) so I am willing to do some work to get JLink based tools to work against RPi 2/3. If you can please point me to a more relevant user guide/doc, perhaps I can understand better what you guys are saying.

    Can you link me the posts you are talking about? The ones i found are talking about running J-Link software or OCD on the Raspberry itself. Not through a J-Link debug probe.

    Best regards,
    Nino

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

    Thanks for the clarification Nino, I now think that my confusion was caused by people using RPi as a debug probe or debug host--which is not what I want to do. I think the closes JLinkScript example for initializing a Cortex-A7 target(s) is the NXP_iMX7D_Connect_CortexA7_0.JLinkScript shipped with J-Link SW. But in it, I see SetupTarget() in addition to ResetTarget() and InitTarget(). The latter 2 are described briefly in the J-Link user manual section 5.11.1, but not SetupTarget(). Can you please elaborate the call order of these 3 functions during JLinkGDBServer or ozone startup?

    Thank you in advance. I am willing to share my final JLinkScript that comes out of this effort with the J-Link / Raspberry Pi community.

    Hello Henry,

    Quote

    Can you please elaborate the call order of these 3 functions during JLinkGDBServer or ozone startup?

    Sure. First InitTarget gets executed. Here you set the generic connect sequence. Then SetupTarget can be called for higher level setup after the initial connection is working (e.g. initialize memory controllers, PLL inits etc.). ResetTarget will replace the generic reset behaviour for target devices. So whenever a reset gets triggered through the user (e.g. with Ozone or GDB) the J-Link will execute what is in the Scriptfile instead.

    Quote

    The latter 2 are described briefly in the J-Link user manual section 5.11.1, but not SetupTarget().


    All three functions should be described in more detail in chapter 5.12 "J-Link script files" in the current user manual. Make sure to have the latest J-Link software package downloaded. There in the install folder under /Doc you will find the latest manual.

    Quote


    Thank you in advance. I am willing to share my final JLinkScript that comes out of this effort with the J-Link / Raspberry Pi community.

    This would be much appreciated. After a final revision we would be happy to ship the Scriptfile through our release versions so all users can debug a Raspberry out of the box.

    Best regards,
    Nino

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

    Hi Nino/Niklas, I have written a JLinkScript for Raspberry Pi 2, but it doesn't quite work yet. Here is the latest output fro JLinkGDBServer using this custom device I created:

    ------Target related settings------
    Target device: BCM2836_A7_0
    ...
    Firmware: J-Link V9 compiled Sep 26 2017 17:01:02
    Hardware: V9.30
    S/N: 609302643
    Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
    Checking target voltage...
    Target voltage: 3.30 V
    Listening on TCP/IP port 2331
    Connecting to target...

    *** J-Link V6.21a Internal Error ***
    CPU_ReadReg() called for CPU without delayed register read. (RegIndex = 1)
    *** J-Link V6.21a Internal Error ***

    ERROR: Could not write CP15 register.
    Reading register 8 failed: Unspecified error
    Reading register 9 failed: Unspecified error
    Reading register 0 failed: Unspecified error
    ERROR: Could not connect to target.
    Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...
    Shutting down...

    As you can see in the attached script, I write to the ARMv7 debug DSCR to enablethe monitor debug, halting debug, and the ITR (instruction transfer). With this, I got past "DBGEN" problem. But now, to understand why J-Link is trying to write to CP15 registers and read CP15 8, 9, and 0, I need to decode the JTAG-DAP messages I see in the logic analyzer. Can you tell me roughly where in the J-Link initialization process I seem to be failing in?

    w/ regards,
    Henry

    Hi Henry,

    The GDBClient you are using seems to request register reads that might not be supported with that target device.
    Can you try to connect with the J-Link Commander so only your Scriptfile gets executed and nothing else?

    Best regards,
    Nino

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

    Hi Nino, I get exactly the same output when I use JLinkExe. Strangely, the Reset proc is not called at all. I didn't realize that initializing a Cortex A's debug would be so complicated. I am struggling to understand why some of your examples even use the internal DAP ADDR write followed by DAP DATA write (which makes sense at a low level) vs. memory mapped write. At this point it's hard to see which one I can get working first--OpenOCD + J-Link route, or JLinkExe + J-Link route. At least OpenOCD gives you (somewhat dated) thick manual of the initialization architecture (not to mention it's open source).

    I wouldn't even ask for the JLinkGDBServer source, but do you have any document that is more detailed than the few sections in UM08001?

    Hi Henry,

    Quote

    Strangely, the Reset proc is not called at all.

    Is reset triggered by hardware/software? If not then no reset will be executed.

    Quote

    I didn't realize that initializing a Cortex A's debug would be so complicated.


    If it would be easy it would not be a business for us ;)

    Quote

    I am struggling to understand why some of your examples even use the internal DAP ADDR write followed by DAP DATA write (which makes sense at a low level) vs. memory mapped write.


    This is not easy to answer as it really depends on the MCU. But generally it is a speed question. For example sometimes the device has some bootloader that locks the DAP or something similar to this, then we have to be faster than the bootloader to access the core.
    In some other cases this information is not even documented so you have to contact the silicon vendor for information.

    Quote

    I wouldn't even ask for the JLinkGDBServer source, but do you have any document that is more detailed than the few sections in UM08001?


    There is no more detailed document as we have to keep the GDBServer as generic as possible to be compatible to as many GDBclients as we can.

    Unfortunately i am not allowed to spend more time on this case as this is starting to stretch the boundaries of forum support.
    I hope you understand.

    Best regards,
    Nino

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

    I do Nino; supporting a hobby platform like RPi will be a low priority for any company.
    It would have been nicer if Niklas had told me up front that SEGGER will not support Raspberry Pi even on J-Link Ultra+; could have saved $700...

    Hi,

    Quote

    Unfortunately i am not allowed to spend more time on this case as this is starting to stretch the boundaries of forum support.


    What Nino said does not contradict the fact that you are entitled for two years of mail support, starting with the date of purchase of the J-Link ULTRA+.

    Quote

    It would have been nicer if Niklas had told me up front that SEGGER will not support Raspberry Pi even on J-Link Ultra+

    I said:

    Quote

    Cortex-A53 is currently not supported by J-Link. Support for ARMv8 64-bit is planned for end of the year-Q1/2018, but only for J-Link ULTRA+ v4 or higher.

    Best regards,
    Niklas

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login