This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How can I connect a Udoo board to Dstream?

Hello Everyone,

Hello agostinelli

I have recently purchased a UDOO board & I'm developing a simple baremetal application (flashing led & button).. & I wanted to be able to debug the processor using the ARM DSTREAM since I have access to such a device.

The problem is that, there seems to be a problem that the DSTREAM cannot connec to my UDOO board (I connected the Udoo board using a custom cable on the JTAG pins available on the board).

Can anyone guide me how did they connect UDOO to Dstream & then uploading an .elf file via JTAG to debug their code? Is there any kind of scripts i need to load when connecting to the imx6Q processor on board? Or is it just providing the processor with the necessary power?

Thanks alot!

Parents
  • Exactly how did you connect it?

    Are you expecting that the NXP and Atmel SoC are in the chain together, or are you only concerned with one or the other?

    The solution in PCE is to not autodetect, but create some of the configuration manually. You're going to hit the following issues on the i.MX6Q which will really impact your ability to autodetect:

    • i.MX6Q has a security controller on the JTAG chain which is effectively pretending that there is a 3rd device, between itself and the ARM DAP. Unfortunately the 3rd device (which is emulating a 4-bit IR in BYPASS, to fill in the gap for a disabled SDMA OnCE controller) does not react well to the autodetection sequence. This is well documented in NXP's TRMs, unfortunately how it reacts to the autodetection sequence is not.
    • i.MX6Q boots with only core 0 powered up, the other cores (1,2,3) are powered down. Along with the cores, the PTM, PMU and CTI are also powered down for these components. When the autodetection sequence would read the CoreSight ROM Table, it will register that there are several devices at particular addresses but they will be powered down.

    And, at runtime the second item will affect the debugger as there is no way to "autodetect" the extra logic in the DSTREAM that prevents normal debugger operations from locking the SoC when they try and access a powered-down component.

    As such you essentially have to pick an "Advanced or Manual" creation method. For the i.MX6Q you can right click in the Devices list icon and select "Add Custom Device" -- you can add two TAPs here, "SJC" with IR Length "5" and "SDMA" with IR Length "4". Open the Devices panel and drag in an ARMCS-DP underneath it.

    From here you have two choices: right click "ARMCS-DP" and select "Enumerate APs" or just add the AHB-AP (0) and APB-AP (1) to the list manually from the list.

    imx6q.png

    The tricky part is then to power up the cores: you can use the "CSAT" tool to do this (open a DS-5 command prompt up and run "csat"). You can run commands like this:

    con USB:nnnnnnn

    chain dev=UNKNOWN_5,UNKNOWN_4,ARMCS-DP clk=1000000

    dvo 2

    dpe

    dmr 0 0x20d8000 0x1c000521

    dcn

    (that connects to USB DSTRAM, sets up the JTAG chain in the same way with a 1MHz clock, opens device 2 (ARMCS-DP), enumerates APs (not essential but good to check) and writes the core_enable bits in the i.MX6Q SRC_SCR).

    Once you've done that, the cores should be up and running and you could, in theory, right click "APB-AP" and "Read CoreSight ROM Tables," then go to the Component Connections tab and detect the links for the devices, or manually add them in.

    However, we know from experience that it doesn't fully detect the topology (see below).

    If you've added the Atmel SoC into the chain then it will need to be either add those components before the SJC or after the ARMCS-DP (it will probably just be another ARMCS-DP), and do the same thing as above -- enumerate the Access Ports, pick the one for the debug components (probably APB-AP), Read ROM Tables, Detect Links..

    Since we don't have a UDOO board, or your cable, it's difficult to tell exactly what the steps will be. The unfortunate reality is that "magical detection" of debug topology is more art than science, while there are procedures that can be followed, some (perfectly valid and reasonable) component selection and design can be an impediment to a completely reliable process.

    The upside: if you JUST have the i.MX6Q wired onto your JTAG cable, then it is simply a matter of not having to Autodetect the platform at all. DS-5 already ships with a configuration (just add a

    Debug Configuration per normal, and find "NXP / i.MX6 Quad (Generic)". You'll only have to do the above if you just want the Atmel SoC (because we don't ship a configuration for that) or if they are chained together (because it is then not a Generic configuration of the i.MX6Q).

    Let us know how it goes.

    Ta,

    Matt

Reply
  • Exactly how did you connect it?

    Are you expecting that the NXP and Atmel SoC are in the chain together, or are you only concerned with one or the other?

    The solution in PCE is to not autodetect, but create some of the configuration manually. You're going to hit the following issues on the i.MX6Q which will really impact your ability to autodetect:

    • i.MX6Q has a security controller on the JTAG chain which is effectively pretending that there is a 3rd device, between itself and the ARM DAP. Unfortunately the 3rd device (which is emulating a 4-bit IR in BYPASS, to fill in the gap for a disabled SDMA OnCE controller) does not react well to the autodetection sequence. This is well documented in NXP's TRMs, unfortunately how it reacts to the autodetection sequence is not.
    • i.MX6Q boots with only core 0 powered up, the other cores (1,2,3) are powered down. Along with the cores, the PTM, PMU and CTI are also powered down for these components. When the autodetection sequence would read the CoreSight ROM Table, it will register that there are several devices at particular addresses but they will be powered down.

    And, at runtime the second item will affect the debugger as there is no way to "autodetect" the extra logic in the DSTREAM that prevents normal debugger operations from locking the SoC when they try and access a powered-down component.

    As such you essentially have to pick an "Advanced or Manual" creation method. For the i.MX6Q you can right click in the Devices list icon and select "Add Custom Device" -- you can add two TAPs here, "SJC" with IR Length "5" and "SDMA" with IR Length "4". Open the Devices panel and drag in an ARMCS-DP underneath it.

    From here you have two choices: right click "ARMCS-DP" and select "Enumerate APs" or just add the AHB-AP (0) and APB-AP (1) to the list manually from the list.

    imx6q.png

    The tricky part is then to power up the cores: you can use the "CSAT" tool to do this (open a DS-5 command prompt up and run "csat"). You can run commands like this:

    con USB:nnnnnnn

    chain dev=UNKNOWN_5,UNKNOWN_4,ARMCS-DP clk=1000000

    dvo 2

    dpe

    dmr 0 0x20d8000 0x1c000521

    dcn

    (that connects to USB DSTRAM, sets up the JTAG chain in the same way with a 1MHz clock, opens device 2 (ARMCS-DP), enumerates APs (not essential but good to check) and writes the core_enable bits in the i.MX6Q SRC_SCR).

    Once you've done that, the cores should be up and running and you could, in theory, right click "APB-AP" and "Read CoreSight ROM Tables," then go to the Component Connections tab and detect the links for the devices, or manually add them in.

    However, we know from experience that it doesn't fully detect the topology (see below).

    If you've added the Atmel SoC into the chain then it will need to be either add those components before the SJC or after the ARMCS-DP (it will probably just be another ARMCS-DP), and do the same thing as above -- enumerate the Access Ports, pick the one for the debug components (probably APB-AP), Read ROM Tables, Detect Links..

    Since we don't have a UDOO board, or your cable, it's difficult to tell exactly what the steps will be. The unfortunate reality is that "magical detection" of debug topology is more art than science, while there are procedures that can be followed, some (perfectly valid and reasonable) component selection and design can be an impediment to a completely reliable process.

    The upside: if you JUST have the i.MX6Q wired onto your JTAG cable, then it is simply a matter of not having to Autodetect the platform at all. DS-5 already ships with a configuration (just add a

    Debug Configuration per normal, and find "NXP / i.MX6 Quad (Generic)". You'll only have to do the above if you just want the Atmel SoC (because we don't ship a configuration for that) or if they are chained together (because it is then not a Generic configuration of the i.MX6Q).

    Let us know how it goes.

    Ta,

    Matt

Children
No data