UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
271 Views
Registered: ‎04-08-2015

SDK fails to automatically detect MDM in 2018.1 in Partial Reconfiguration design

Jump to solution

Hi everyone,
I'm writing to ask for help accessing a Microblaze Debug Module in a tandem field update project in Vivado2018.1.

--------------------------- Our Vivado setup is: ---------------------------
1) In Programmable Region:
  - A debug_bridge from_BSCAN_to_DebugHub (ver 2.0), its S_BSCAN interface ports connected to PR top level ports with the same name, so that debug Hub in Static portion will be automatically inferred.
  - A Microblaze Debug Module with BSCAN location set to EXTERNAL and jtag USER2, its BSCAN interface connected to a second MDM_S_BSCAN interface ports in top level of PR.
2) In top level (static a BSCANE2 with .JTAG_CHAIN(2) connected to PR MDM_S_BSCAN ports.

See attach files top_static and pr_app templates files.
--------------------------------------------------------------------------------------------------------

 

In vivado/sdk2017.2 we're able to both use debug probes and access Microbalzes through the MDM.

Unfortunately we're not able to setup a System Debugger/GDB configuration in sdk2018.1.


Here's the output of SDK.log when trying to setup a debug configuration, with some comments.

####        Before trying to launch system debugger       ####
  xsct% jtag targets
    1* Digilent JTAG-SMT2 210251A1EB1D
       2  xcku060 (idcode 13919093 irlen 6 fpga)
          3  bscan-switch (idcode 04900101 irlen 1 fpga)
             4  unknown (idcode 04900220 irlen 1 fpga)
             
    ### In vhdl I see that mdm BSCAN_ID defaults to 76547328 (0x04900500). Is it normal that it doesm't show up in jtag targets? ###
             
  xsct% targets
    1  xcku060
       5  Legacy Debug Hub
       2  MicroBlaze Debug Module at USER2
          3* MicroBlaze #0 (Running)
          4  MicroBlaze #1 (Running)


### Log of what's happening during Debug Configuration setup ###

  ...
  14:29:52 INFO    : 'targets -set -filter {jtag_cable_name =~ "Digilent JTAG-SMT2 210251A1EB1D" && level==0} -index 0' command is executed.
  14:29:52 INFO    : 'fpga -state' command is executed.
  14:29:52 INFO    : Connected to target on host '127.0.0.1' and port '3121'.

  ### This exception is probably caousing errors, later on ###
  14:29:52 ERROR    : An unexpected exception occurred while trying to update bsan info for mb
  java.lang.NumberFormatException: For input string: "2.1"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Integer.valueOf(Integer.java:766)
    at com.xilinx.sdk.tcf.debug.BaseXsdbOperations.checkAndEnableMdms(BaseXsdbOperations.java:697)
    at com.xilinx.sdk.tcf.debug.launch.ZynqAndMbXsdbOperations.runTargetSetupNonZynq(ZynqAndMbXsdbOperations.java:110)
    at com.xilinx.sdk.tcf.debug.launch.ZynqAndMbXsdbOperations.runTargetSetup(ZynqAndMbXsdbOperations.java:69)
    at com.xilinx.sdk.tcf.debug.BaseTcfLaunchDelegate.runXsbCommands(BaseTcfLaunchDelegate.java:286)
    at com.xilinx.sdk.tcf.debug.BaseTcfLaunchDelegate.launch(BaseTcfLaunchDelegate.java:197)
    at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
    
  14:29:52 INFO    : Jtag cable 'Digilent JTAG-SMT2 210251A1EB1D' is selected.
  14:29:52 INFO    : 'jtag frequency' command is executed.
 
  ## I suppose configparams mdm-detect-bscan-mask 0 prevent system from detecting jtag bscan anymore ##
  14:29:52 INFO    : 'configparams mdm-detect-bscan-mask 0' command is executed.
 
  ################################ This causes a termination of the debug configuration ############################
  14:29:55 ERROR    : no targets found with "name =~ "microblaze*#0" && bscan=="USER2.1"  && jtag_cable_name =~ "Digilent JTAG-SMT2 210251A1EB1D"". available targets:
    1* xcku060
       5  Legacy Debug Hub
  14:29:55 INFO    : ----------------XSDB Script----------------
  connect -url tcp:127.0.0.1:3121
  configparams mdm-detect-bscan-mask 0
  # microblaze*#0,1" are actually located at bscan=="USER2" ###
  targets -set -nocase -filter {name =~ "microblaze*#0" && bscan=="USER2.1"  && jtag_cable_name =~ "Digilent JTAG-SMT2 210251A1EB1D"} -index 0
  ----------------End of Script----------------
  ...

 

####        After failed to launch system debugger        ####
  xsct% jtag targets
    1* Digilent JTAG-SMT2 210251A1EB1D
       2  xcku060 (idcode 13919093 irlen 6 fpga)
          3  bscan-switch (idcode 04900101 irlen 1 fpga)
             4  unknown (idcode 04900220 irlen 1 fpga)
  xsct% targets
    1* xcku060
       5  Legacy Debug Hub
    ###Everything else has disappeared due to 'configparams mdm-detect-bscan-mask 0' command




Some observations:

- If I run from xsct 'configparams mdm-detect-bscan-mask 2' after debug_configuration failed, I'm able to see the whole jtag chain again.
- I'm pretty sure the hw setup is correct, because if I issue xsct commands manually instead of relying on debug_configuration execution, I'm able to accesst mdm jtag terminal, program mblazes inside the design, and debug the code.
- What's happening is (it seems) is that sdk failing in the command 'targets -set -nocase -filter {name =~ "microblaze*#0" && bscan=="USER2.1"  && jtag_cable_name =~ "Digilent JTAG-SMT2 210251A1EB1D"} -index 0' is preventing debug_configuration to succeed.
  The two problems here are that:
    1) 'configparams mdm-detect-bscan-mask 0' disables bscan completely.
    2) probably {name =~ "microblaze*#0" && bscan=="USER2.1"  && jtag_cable_name =~ "Digilent JTAG-SMT2 210251A1EB1D"} wouldn't return anything even if 'configparams mdm-detect-bscan-mask 2' would be run instead of 'configparams mdm-detect-bscan-mask 0', since mb are at BSCAN USER2, not USER2.1
- If I run sdk to debug a mdm with internal BSCAN (of course not a PR design), sdk debug_configuration succeedes.



Some questions:

- Could this behavior be caused by something going wrong in *.hdf generation?
- what could be the cause of sdk looking for mdm @wrong bscan USER? Why sdk is looking at BSCAN USR 2.1 instead of USER2?
- what could be the cause of sdk configuring bscan mask to 0?
- Is there a way to edit/overwrite BSCAN config when running debug_configuration?
- What else should I look for, to understand better the problem?

 

Thanks in advance for the help,
regards,
have a nice day.

 

Fabrizio

0 Kudos
1 Solution

Accepted Solutions
198 Views
Registered: ‎04-08-2015

Re: SDK fails to automatically detect MDM in 2018.1 in Partial Reconfiguration design

Jump to solution

Ibai,

Thanks for your suggestions!


1. Use the target connection wizard to create you own custom JTAG chain configuration rather than relaying on the default one. You can specify the IDCODEs but I don't see options for BSCAN so not sure if that would work.


I had tried this before posting to the forums, but I wasn't able to create a JTAG chain configuration that works. But to be honest I did not put a lot of effort in investigating this route.

 


2. Use the "Connect to running target" connection type on your debug configuration and create a TCL script based on the default one just modifying the MDM values. This at least would help your to avoid manual entries each time you want to debug an application.

This was the solution for me.
Up until now I was able to access the mdm and download new elf files on the microblazes and log output on jtag uart  by means of xsct scripting, but had no easy way of inserting breakpoints and backtracing the code.
By first programming the microblazes via xsct script and then "Attaching to running target" in SDK, I'm then able to Add symbol files to the Microblazes. Once I've done that, I'm able to also insert breakpoints and backtrace.
I'm still not able to add Symbol files directly on the xsct script that I use to program the Microblazes, but doing it from the GUI works ok, so it is a minor issue.

 

Thank you very much, Ibai.

 

P.s. Just in case it's useful, I put a summary of the actions required to debug the mblazes.

1)program the Microblaze(s) via xsct script

 

connect -url tcp:127.0.0.1:3121
#Perform these steps for every processor connected to the mdm. 
#set bscan USER accordingly to mdm bscan user, that can be detected by running "targets" command.
targets -set -nocase -filter {name =~ "microblaze*#0" && bscan=="USER2"} -index 0
rst -processor
dow <mb_program_file>.elf
#In theory next commands shoud enable backtracing automatically, actually I must do it from SDK later on
memmap -file <mb_program_file>.elf

2) From SDK: Createa  Debug configuration by selectign "Attach to running target", then follow these steps. Select the Debug/*.elf file of each microblaze, as symbol file.

0 Kudos
2 Replies
Moderator
Moderator
215 Views
Registered: ‎10-06-2016

Re: SDK fails to automatically detect MDM in 2018.1 in Partial Reconfiguration design

Jump to solution

Hi @fabrizio.marchese,

I don't think the issue is in the HDF file per se, I mean, I would say is more an SDK issue that is not inferring properly the JTAG chain for this particular use case. I never used this kind of configuration with BSCAN and PR so I don't have the answer for your questions but I'm just figuring out some possible alternatives/workaround.

1. Use the target connection wizard to create you own custom JTAG chain configuration rather than relaying on the default one. You can specify the IDCODEs but I don't see options for BSCAN so not sure if that would work.

image.png

2. Use the "Connect to running target" connection type on your debug configuration and create a TCL script based on the default one just modifying the MDM values. This at least would help your to avoid manual entries each time you want to debug an application.

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
199 Views
Registered: ‎04-08-2015

Re: SDK fails to automatically detect MDM in 2018.1 in Partial Reconfiguration design

Jump to solution

Ibai,

Thanks for your suggestions!


1. Use the target connection wizard to create you own custom JTAG chain configuration rather than relaying on the default one. You can specify the IDCODEs but I don't see options for BSCAN so not sure if that would work.


I had tried this before posting to the forums, but I wasn't able to create a JTAG chain configuration that works. But to be honest I did not put a lot of effort in investigating this route.

 


2. Use the "Connect to running target" connection type on your debug configuration and create a TCL script based on the default one just modifying the MDM values. This at least would help your to avoid manual entries each time you want to debug an application.

This was the solution for me.
Up until now I was able to access the mdm and download new elf files on the microblazes and log output on jtag uart  by means of xsct scripting, but had no easy way of inserting breakpoints and backtracing the code.
By first programming the microblazes via xsct script and then "Attaching to running target" in SDK, I'm then able to Add symbol files to the Microblazes. Once I've done that, I'm able to also insert breakpoints and backtrace.
I'm still not able to add Symbol files directly on the xsct script that I use to program the Microblazes, but doing it from the GUI works ok, so it is a minor issue.

 

Thank you very much, Ibai.

 

P.s. Just in case it's useful, I put a summary of the actions required to debug the mblazes.

1)program the Microblaze(s) via xsct script

 

connect -url tcp:127.0.0.1:3121
#Perform these steps for every processor connected to the mdm. 
#set bscan USER accordingly to mdm bscan user, that can be detected by running "targets" command.
targets -set -nocase -filter {name =~ "microblaze*#0" && bscan=="USER2"} -index 0
rst -processor
dow <mb_program_file>.elf
#In theory next commands shoud enable backtracing automatically, actually I must do it from SDK later on
memmap -file <mb_program_file>.elf

2) From SDK: Createa  Debug configuration by selectign "Attach to running target", then follow these steps. Select the Debug/*.elf file of each microblaze, as symbol file.

0 Kudos