[ABANDONED] program Cortex-M4 processor with 2 Xilinx FPGAs in JTAG chain

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] program Cortex-M4 processor with 2 Xilinx FPGAs in JTAG chain

    Dear all
    I have a custom board that has on it a Tiva TM4C1290NCPDT MCU and two Xilinx FPGAs (Ultrascale+ devices.) These boards share a JTAG chain. Via jumpers I can select out one of the devices and program it on the test bench, but once the board is in a ATCA shelf this will not be practical and I would like to be able to program and debug the MCU while all devices are on the JTAG chain. For the debugging and loading of the TM4C firmware I have been using a SEGGER JLINK EDU in the Eclipse environment, which has been working really well for me when I just have the TM4C in the chain. The software version I am using is V6.46a on a CentOS7-based Linux box.

    The devices on the JTAG chain look like this:
    1. VU7P is device #0 ID=0x14B29093 IR_len=12
    2. KU15P is device #1 ID=0x14A56093, IR_len=6
    3. TM4C is device #2 ID=0x4BA00477 IR_len=4



    When I add the two other devices in the chain, I am unable to debug the device or load the firmware. However, I am able to connect to the TM4C using JLink using the connect command from the interactive prompt. Using a JLINK script file and setting the IRPre,DRPre I get a successful connection. I'm attaching the log file (jlink-connectsuccess.txt). It also uses a JLINK script which I've also attached.

    if I then move to using Eclipse it does not work, though I try to pass the same commands to the GDB server. I am attaching that log file here as well (jlink-gdbfail.txt). I notice that it does not print out the message from my J-Link script though, so it does not appear that that is being used.

    What am I doing wrong?
    Thanks
    Peter
    Files
  • Hi, so if no one has any suggestions, can anyone give me more generic advice or experience with the combination of a JTAG chain of ARM (non-Zynq) + FPGA using SEGGER tools? Any hints or comments would be appreciated.

    Even an appropriate eval board I could use to ‘practice’ would be useful.

    Thanks
    Peter
  • Hello Peter,

    Thank you for your inquiry.
    Your GDB-Server CL looks correct on first glance.
    To get Eclipse out of the equation could you give the GDB-Server Stand alone a try? You can find it in the J-Link software install folder.

    Could you also give Ozone a try? Is that working instead?
    segger.com/products/development-tools/ozone-j-link-debugger/

    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: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino
    Thanks for your response. I can start the command-line invocation of the gdb server command but then I don't know what to do next. It starts ok but then does not do anything if i just call it with the arguments listed above. Do you have a suggestion on what I should do to test it? The log file from previous seems to run into problems after the connect, when the system issues a reset to the processor (after line 42), and when I start gdb by hand it just waits at that point w/o doing anything, but also w/o any errors.

    Thanks
    Peter
  • Hello Peter,

    If I understand you correctly the general connect works. But if you connect your gdb-client/debugger to the gdb server the connection crashes.
    Is that correct so far?
    If yes is some kind of reset maybe issues? Some devices might require special reset handling. Maybe the reset line is pulled externally here. Is reset shared here between the three devices? If yes could you scope it and see if it behaves unexpected?

    Could you provide a J-Link log of a failing session?
    wiki.segger.com/Enable_J-Link_log_file

    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: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino
    Yes looking at the log file I posted on the original post (well, std out of the gdb session) it looks like it fails on reset. The reset pin is not connected to the devices, so something else is going on. I will have to try to capture the J-Link log file and see what it says, if it has additional information.
  • Hi Nino

    I am attaching a jlink log file. I stared at it for a bit but was unable to be wiser based on its output, but again it fails around here on the reset.

    02-00000000-00-00002141-0042: T89539700 002:148 JLINK_ResetPullsRESET(ON) (0000ms, 1298ms total)
    02-00000000-00-00002195-01D3: T89539700 002:148 JLINK_Reset() -- CPU is running -- CPU_WriteMem(4 bytes @ 0xE000EDF0) -- CPU is running -- CPU_WriteMem(4 bytes @ 0xE000EDFC)Reset: Halt core after reset via DEMCR.VC_CORERESET.Reset: Reset device via AIRCR.SYSRESETREQ. -- CPU is running -- CPU_WriteMem(4 bytes @ 0xE000ED0C) -- CPU_ReadMem(4 bytes @ 0xE000EDF0)Reset: SYSRESETREQ has confused core.AP map detection skipped. Manually configured AP map found.AP[0]: AHB-AP (IDR: Not set) >0x140 JTAG>
    02-00000000-00-00002195-000F: ***** Error:
    02-00000000-00-00002195-0070: Bad JTAG communication: Write to IR: Expected 0x1, got 0x0 (TAP Command : 10) @ Off 0x1C. (0054ms, 1352ms total)

    Thanks very much for your help.

    update: I also uploaded the file how the reset looks when only the Cortex-M4 TM4C is in the chain. (jlink_success.txt).

    Peter
    Files

    The post was edited 1 time, last by wittich ().

  • It is awkward to reply to my own thread so many times, but I discovered that I _can_ attach to a running process and seems to mostly work. So the big hold-up really appears to be limited to the reset. I have found I can load the binary with JLINK but when I try to restart the board (running 'r' in my JLINK script) the same error occurs as in the previous instances and I need to power-cycle. So I have a lot of work arounds but still no real solution.

    I see that there are different reset options described in the JLINK manual, but none of those appear to be relevant here.
  • Hello,

    Thank you for sharing the additional information.
    So as suspected reset is the issue. Are the reset lines shared between the devices or does each device have a separate reset? Is the M4 interconnected to the FPGAs in any other way?
    I assume that once reset is triggered for the TM4C either the FPGAs get reset which leads to follow up issues or the reset of the M4 triggers some behaviour in the FPGAs that is unexpected.
    Please understand that the reported issue most likely stems from your custom target setup and is no issue with SEGGER Hardware or Software, so please understand that we can't put more time into this issue.

    I suggest to probe the reset and debug signals with an oscilloscope and see if you get expected sequences.
    If you want to change the reset behaviour the easiest way is to use a JLinkScript and overwrite the default reset handling for the TM4C with your custom one in function TargetReset(). How to do that is explained in the J-Link user manual.

    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: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino
    thanks for your reply.

    As we discussed earlier in the thread and the JLINK debug file shows, the reset is not connected from the debug probe to either the FPGAs or the ARM processor. The processor is being reset by shifting a value into the DEMCR register.

    I looked at your manual again, I do not find a TargetReset() function defined.

    I only find
    JLINK_TIF_ActivateTargetReset()
    JLINK_TIF_ReleaseTargetReset()
    On pages 213 of the current manual (Section 7.12.2.54 and 55).
    Is this what you are referring to?
    (Edit: Never mind, for some reason my search function did not find it but now I did.)

    My suspicion is that somehow the FPGAs are not being put into bypass mode after the reset. I imagine the JLINK puts the FPGAs into bypass mode somehow, but I cannot find in documentation an obvious way to do this again after resetting the TM4C. Any guidance there? I presume I could use the reset entry point you describe above.

    Best
    Peter

    The post was edited 1 time, last by wittich ().