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!
Hi oray,
For the UDOO QUAD/DUAL versions the JTAG header on the board is wired rather oddly - can you detail exactly how you're wiring your custom cable (to which pins)?
You can, in theory, connect up the Atmel and NXP chips on the board in a chain and have them both active at once in a debug configuration, if you've wired it this way then there is significant work ahead to create a debug configuration that will suit this JTAG chain.
However if you've wired the i.MX6Q up alone, properly, then we're not sure why an i.MX6Quad (Generic) connection wouldn't work out of the box. Is your DSTREAM VTREFA light on (along with the green LED on the board)?
Ta,
Matt
Hello Matt,
I have revised the jtag connection pins & confirmed that my custom cable is
correctly wired to my distress unit.
And yes, when I power up the udoo board after hooking the jtag cable to the
dstream, the vref led lights up.
My issue raises when I attempt to autodetect the hardware connected to the
dstreAm using the ds5 software. Nothing is detected ( I also Trieste
hardware configuration utility software, no luck there as well)
My question is, is there any preconfiguration script/code that should be
written to the udoo boss before establishing the jtag connection?
Thanks Matt for your help in advance.
Sincerely,
O.Ray
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:
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.
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.