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

henry10210 · Oct 16th 2017, 4:57pm

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:

Source Code

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.

Display All

When connecting from OpenOCD

Source Code

$ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f ~/rpi/openocd/rpi3.cfg
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
adapter_nsrst_delay: 400
none separate
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 9224
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 3.306 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : JTAG tap: rspi.arm tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Warn : JTAG tap: rspi.arm UNEXPECTED: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Error: JTAG tap: rspi.arm expected 1 of 1: 0x07b7617f (mfg: 0x0bf, part: 0x7b76, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Error: 'arm11 target' JTAG error SCREG OUT 0x00
Error: unexpected ARM11 ID code

Display All

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:

Source 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?

SEGGER - Niklas · Oct 17th 2017, 11:51am

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 wiki.segger.com/Software_and_Hardware_Features_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

henry10210 · Oct 17th 2017, 5:03pm

Thank you Niklas, I should have read through the whole manual...
How can I check if what the distributor is selling is Ultra+ v1 or v4?

SEGGER - Niklas · Oct 17th 2017, 5:15pm

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:

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

Best regards,
Niklas

henry10210 · Oct 17th 2017, 7:33pm

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.

SEGGER - Niklas · Oct 18th 2017, 10:02am

Hi,

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).

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

henry10210 · Oct 20th 2017, 2:41am

I ordered J-Link Ultra+ v4 yesterday.
Meanwhile, I'll try to connect my J-Link+ v9 to Raspberry Pi (original).

henry10210 · Oct 27th 2017, 7:33am

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.

SEGGER - Nino · Oct 27th 2017, 5:11pm

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: 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: 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

henry10210 · Oct 28th 2017, 4:50pm

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.

SEGGER - Nino · Oct 30th 2017, 9:41am

Hello Henry,

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.

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.

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.

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

henry10210 · Oct 30th 2017, 5:04pm

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.

SEGGER - Nino · Oct 30th 2017, 5:32pm

Hello Henry,

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.

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.

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

henry10210 · Nov 5th 2017, 9:31pm

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

SEGGER - Nino · Nov 7th 2017, 1:16pm

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

henry10210 · Nov 7th 2017, 7:37pm

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?

SEGGER - Nino · Nov 8th 2017, 9:31am

Hi Henry,

Strangely, the Reset proc is not called at all.

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

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

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.

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

henry10210 · Nov 13th 2017, 4:13am

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...

SEGGER - Niklas · Nov 13th 2017, 9:16am

Hi,

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+.

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:

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

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

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

Source Code

Source Code

Source Code

Are the J-Link Ultra+ being sold on Mouser electronics the v4?

What does Cortex-A7 mean to JLinkExe?

Please put me on an alert list for A53 support

J-Link+ v9.3 against RPi2 does not work

Are RPi 2,3 really not supported?

NXP_iMX7D_Connect_CortexA7_0.JLinkScript example

pointer to APB-AP decoder?

More detailed documentation than UM08001 (something like the OpenOCD manual)?

Waste of $700...

Share