Debugger with trace capability

Go To Last Post
28 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am confused. I have been using JTAGICE mkII, the Dragon, JTAGICE3, ATMEL-ICE and last week I unpacked a for me new AVR ONE! although it is one ot the older tools. So I should now most about the tools but I do not.

 

So far I have only been using theese tools for debugging mega AVR MCU's but I plan to go for ARM D20 soon. Interface has been both debugWire and JTAG. Mostly JTAG. All tools has been working fine although I had three dead Dragons for a time during the release of Studio 5-6.0 but later I could wake them all up by programming them in 4.18 and use them in later versions of Atmel Studio. JTAGICE ICE have almost not used but I couldn't notice any difference between that and  JTAGICE3.

 

Now I decided that I really needed a debugger with back trace capability. I didn't spend much time on it, I just thought that I remebered that there was one tool that supperted that, did a quick check and found out that it must be AVR ONE! So I bought it, not giving it a thought that it is 5 years old. I unpacked it and tried it but I couldn't make the trace to work. (This tools actually looks very professional but it is also much more expensive. A stupid thing is that I had to make a row switch adapter to make it work with the new smal squid cables). Checked the manual but it is not updated for later versions of Studio so nothing is right.

 

So please could someone help me figure out how all this fits together?

1. First telling the difference between all my tools (if any).

2. Tell me if there is any tool, or which ones, that support back trace and how to enable that function.

 

Many thanks to anyone who nows about this!

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think the chip itself would have to support "trace." (there's an ARM hardware module, for example.)

I guess a microprocessor-like system could do it by applying "deep knowledge" to all the bus signals that a logic-analyzer gets to see, but a self-contained microcontroller would need to make the equivalent signals available to the debug interface, and that's assuming you're willing to put up with the performance hit to get the info out of the chip (ditto for continually single-stepping, which might work, if implemented.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I forgot to tell what hardware I want to debug. At the moment it is an mega32 although as I mentioned it can be something else, like ARM D20, in near future.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From a discussion with "a well-informed source" I seem to recall that the lack of support for trace is not in the AVR ONE! itself, but in Studio. And that it probably not will be implemented again (some older Studio presumably supported trace?.

 

 Given the cost for that behemoth, I'd try to return and get a refund based on "marketing specs" not being true.

 

(I got one at a ridiculously low price, so it was kept for debugging w/o trace. Sturdy, apart from the target board connector. Atmel has a special department that every new programmer/debugger and evaluation board has to pass before RTM. They make sure there is at least one design flaw that will frustrate users. Odd and hard to get headers. Mounting holes missing on PCBs. Debug connectors that break easily. I assume they get well paid for a job well done.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the Tiny/Mega/XMega devices, the problem is that there is no history cache in the chip. As a result everything would have to be sent out the JTAG or other debug port. Neither the MCU nor USB nor the desktop application can keep up with that in real time. Thus, doing that would result in very slow execution. That is the trade-off - realistic execution time between breakpoints or slow execution time with trace function. Given the hardware (chip) constraints, those are the tradeoffs.

 

Wish it were otherwise. I had, in ages past, an 8051 emulator with gobs and gobs of trace memory (and a bundle of wires to get the data to the control box where it was stored). 'Twas an expensive bugger, even then, but that trace feature was a winner.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the tools of the 80's was expensive, just the pod was $2k. But isn't it amazing that even if I buy the best and most expensive tools for one of the most modern+mature MCU's I can not get the same feature as in 1985?

 

For a trace, the chip only needs to send program flow breakers, like all executed branch or call instructions so it does not need to send the PC for every step.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For a trace, the chip only needs to send program flow breakers, like all executed branch or call instructions so it does not need to send the PC for every step.

And if the link between the AVR and the ONE! is fast, then the ONE! might very well cope with fast execution. AFAICR it is based on an FPGA, and with a suitable RAM behind that such a solution will be FAST! (I have always thought that Atmel chose an FPGA-based solution exactly in order to cope with large/fast flows of debug/trace data from the uC.)

 

Just speculating now, but say an FPGA needs 50 clocks to grab a datum from the AVR and store it in a fast RAM and that it runs at ...uuuhhhhmmm.... half a GHz or so. That should be good for coping with a uC running at 10 MHz where every step is a "flow breaker".

 

Remember that FPGAs can implement true parallel stuff (rather than quasi-parallel as in a single-core CPU). Thus it can shift in data from a fast serial line, while at the same time incrementing an address counter for the "trace RAM". And it could pipeline stuff, like writing to "trace RAM" the previous trace datum, while at the same time shifting in the next from the uC. And so on..

 

Anyway, my trusted source hinted that trace is not something that is a prime objective for Atmel Studio - but you did need a paper weight, right?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Tue. Oct 13, 2015 - 06:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want fancy features like Trace then look at using ARM/Cortex chips. In particular look for "MTB" (Micro Trace Buffer)(*). This allows you to use some of the RAM inside the chip to hold a log of the instructions that were executed. When you break in the debugger it reads out the contents and is able to show you the last few hundred instructions executed in sequence.

 

For this to happen the CPU itself has to contain this MTB "recorder".

 

To do otherwise would involve the CPU being stopped after the execution of every opcode (or maybe just the "flow breakers"?) for the debugger to record what was just executed which (because of the relatively low speed of the debug interface) means the CPU would execute code at a stupidly slow speed.

 

When the AVR One! first came out it did have such trace but Atmel later withdrew support for the feature which would seem to suggest they found some catastrophic error in their implementation. After that the $599 AVR One! started to look very expensive indeed.

 

(*) while the D20 is Cortex M0+ and one of the "+" is the potential for the CPU to have MTB I don't think Atmel devices do. Studio does have "Percepio Trace" though - which is probably worth investigating.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bengtr wrote:
2. Tell me if there is any tool, or which ones, that support back trace and how to enable that function.
AVR ONE! and tracing is in IAR EWAVR32 for AVR32 UC3.

IAR Systems

User Guides: IAR Embedded Workbench for Atmel AVR32

C-SPY(r) Debugging Guide

http://ftp.iar.se/WWWfiles/AVR32/webic/doc/EWAVR32_DebuggingGuide.pdf

(go to page 163 for "Trace")

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
(some older Studio presumably supported trace?.
Yes in AVR32 Studio; version 2.6 in the archive.

There's an AVR32 Studio 2.7 "somewhere" (Beta?).

Atmel Corporation

Studio Archive

http://www.atmel.com/tools/STUDIOARCHIVE.aspx

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
f you want fancy features like Trace then look at using ARM/Cortex chips. In particular look for "MTB" (Micro Trace Buffer)(*).
Is it ARM signal SWV or SWO that has the trace information?

Some of the SEGGER debuggers support ARM trace; IIRC, an Eclipse plug-in has a trace feature.

ARM DS-5 has tracing.

If not real-time, QEMU can emulate some Cortex-A and Cortex-M; an extended QEMU can trace but don't know if QEMU can pass the trace information to a debugger.


SEGGER

J-Link - Supported IDEs

https://www.segger.com/jlink-ide-integration.html

GNU ARM Eclipse

A family of Eclipse CDT extensions and tools for GNU ARM development

How to install the SEGGER J-Link?

http://gnuarmeclipse.github.io/debug/jlink/install/

...

  • when SWD is selected, it is capable to sample the SWO pin, for trace messages and other ARM specific debugging
  • it is fast, up to 15 MHz for JTAG clock and up to 7.5 MHz SWO sampling frequency for the new V9 hardware (12 MHz JTAG / 6 MHz SWO for V8, and even up to 100 MHz SWO for the high-performance ULTRA+, PRO models)

...

GNU ARM Eclipse has a QEMU plug-in.

ARM DS-5 Development Studio

DS-5 / Compare DS-5 Editions

http://ds.arm.com/ds-5/compare-ds-5-editions/

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Bad time to take a holiday I see... I feel a lengthy post coming up :) 

 

First of all, Studio supports trace. Have done since 6.2. However, there are so many types that I'll try to go through and summarize (I have been wanting to do this for some time, especially dues to the abysmal documentation in studio about the subject. 

 

First, to answer OPs question, NO. Atmel Studio 6.2 and 7.0 does not support any trace that is special for the AVR One! The trace capability in the AVR One! is part of the Nexus (Class 2 I think) specification, used in  AP7000 and UC3. This is the trace feature that AVR32 Studio and IAR has. Specifics on what is in the Nexus class 2 spec is detailed in the AVR32 UC3 technical reference, but for streaming trace (AVR One! was used to capture streaming trace, i.e using the FPGA), it was probably program execution, data watch etc in a non-intrusive way. Read to bottom for some thoughts on why this trace is not available in Studio 7.

 

So, the special things that came in AVR One! is only streaming trace (similar to PTrace on ARM) for the UC3. 

 

Now, there were mentions of using trace buffers above (MTB). This was introduced in Studio 6.2 for both ARM (MTB) and UC3 (NanoTrace). Both these techniques reserves a ram buffer, and the core embeds 'packets' in this buffer with branch information (i.e branching from PC to PC). This can be used to 'fill in the gaps' in the program execution, showing what part of the program has been run. It is not completely non-intrusive however, since the currentl implementation in studio only supports the 'break on buffer full' mode, where the core halts once the buffer is fully written and studio then reads out the buffer and starts the core again (i.e there's a small time for each full buffer where the core is halted). MTB is available on (all?) most Cortex-M0+ devices from us (at least the D21, R21, L21 etc, not sure about the x20 cores). NanoTrace is available on UC3L, (and in 7 it was activated for B and ... C i think). The datasheet should contain refrences to these terms if they are available. The simulator emulates this for all devices it supports, even if the real device does not support this. 

 

So, that was buffered trace, now onto what streaming trace is available. Here, the Percepio plugin is the main visualization tool. Note that due to the abstraction done in Studio, even though Percepio claims to only support ARM, they also support some techniques on UC3 and actually most of the trace capabilities I'll talk about below also works in the Simulator (for those wanting to look at the AVR while it runs).

 

Since Percepio mainly focuses on ARM, I'll primarily talk in that context. Studio implements only SWO trace (One-Wire trace), not Parallel Trace (up to 4 pins). All EDBG, Atmel-ICE and JTAGICE3v3 and Segger probes supports this if the SWO pin is connected. Note that due to the relative low spec on both the EDBG, Atmel-ICE and JTAGICE3v3, trace can only be captured at about 1.5 MHz (TPIU Clock). For stable reception, .75 MHz is probably better. Segger has a bit more horsepower, and can usually capture 6 MHz or 12 MHz. See the segger userguide for the specification on the different Segger probes (more expensive = faster trace).

 

The first streaming trace available is Application Output, also known ass ITM, SWO, SWV and probably other three-letter short forms. It is, in short, 32 stimulus registers in the ITM part of the debug system that can be written to, where the data written to it is streamed out on the SWO pin. The ITM functions are part of CMSIS

 

There is also a 'similar' feature on the Mega devices (using JTAG), the OCDR register. This is a 8 bit register that can be written to by the application and is then read out live by the debugger (at a quite slow speed though). See 'IDR Events' here. These messages are captured and shown as IDR messages.

 

Then comes data watch. This is a variant of data breakpoints (uses a data breakpoint) but instead of halting the core on a match, it just sends out the value of the match. This is known as a DWT package on ARM. This is supported by the Live Watch plugin to studio. Note that it is a bit quirky and sometimes, if it does not manage to set up streaming trace of a variable it will set a normal databreakpoint with a 'low level continue' behaviour, mimicking streaming trace.

 

Then, Interrupt trace. This is specifically used in SWO trace on ARM and in Percepio. Percepio can either show this as normal Interrupts, or if there's an RTOS running it can add some more fancy information about what the RTOS is doing. 

 

Then, PC Sampling. This is available on ARM and UC3 and Simulator (intrusive) and on ARM as non-intrusive. As the name implies, the program counter is sampled and used to give statistics about program execution. I usually use this in intrusive mode when wanting to demonstrate trace.

 

What OP seems to want is what is known as ETM on ARM (or old-school emulators for AVR). As far as I know, we do not have any devices with ETM today (as it is primarily used on CM4 and maybe on CM7).

 

So, that was a short list of the traces that are available in Studio today. 

 

So for my thoughts on why we do not have Nexus trace in studio. I think that basically, it was deemed too expensive to make it work properly when converging AVR Studio 4 and AVR32 Studio. The usage numbers we had were quite small. Most of the users that used this sort of high-end trace on the UC3 were using IAR anyway, so we left it to them.

 

Phew, long talk straight from Death Valley (it's HOT HERE).

 

 

 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

especially dues to the abysmal documentation in studio about the subject. 

I read those section yesterday while researching an answer for this thread and I have to say I agree. What I took away from it was that ARM and UC3 both have CPU mechanisms to "sniff" the PC while the CPU is running so they can be traced. AFAIK there's nothing equivalent for tiny/mega/xmega (though I haven't read all your post yet!). There also seemed to be a way to set up a trace buffer (they even call it "MTB") but it wasn't clear to me which CPUs this applied to and do they truly have the ARM MTB unit in them or is this "faked"?

 

EDIT: Ok I have read all that now - seems to confirm most of what I thought - OP was looking for some mega32 technique to trace. So you seem to be saying "pepper your code with writes to OCDR". The only thing is, if you are going to do that you might as well just make them writes to an LED or LCD or UART or similar so I don't really see the advantage. Also in previous Studio versions I could never get the IDR thing to work anyway - are you sure it actually works? (I was using JTAGICE mkII version A at the time).

 

As for ARMs - that would seem to be the way to go if you want MTB. Again to research it I pulled a D20 datasheet at random and searched for "trace" in it yesterday. There as no mention of "Micro Trace BUffer"/"MTB" or anything like that and the word "trace" only appeared twice - both near a diagram of the 10 pin SWO/SWD header but there was no further explanation. So either the M0+ devices don't all have MTB or the authors of your datasheets forgot to mention this gem!

 

Personally I might be tempted to choose a CPU on the basis of whether it has MTB or not and I walked away thinking Atmel M0+ didn't have it. (can I mention a competitor but you should see how the Code Red IDE for NXP LPC M0+ does MTB stuff - I love the coloured display of the trace with fading colour further back so you can instantly see the progression to where you eventually stopped!)

Last Edited: Wed. Oct 14, 2015 - 10:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmh, I do think that the d20 did not have MTB, but all the other in the 20 series should (I seem to remember some talking with ic about why on earth they didn't fit it).

On the d10,i don't think it's there either (pricing point, MTB adds slightly to the cost of course )

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thansk a lot for a fantastic answer. I think many people will have great use of this information and some might hopefully avoid spending 500$ on something they have no use for. So there is really something with that IAR thing after all...

 

But there are another player out where. What about Imagecraft and their debugger? Does it support anything of this?

 

A final question so I can be sure. There is nothing useful with AVR One! anymore, not even if I bundle it with IAR?

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that all trace depends on on-chip hardware (except the old school emulators). On AVR there is almost (except OCDR) nothing on the chip to do trace, and by that logic not of Imagecraft either (since they as far as I know delve in AVR8).

 

The AVR One! gives as I said streaming trace one the UC3 using IAR. Only on UC3. It was also the fastest debugger that we made, until the JTAGICE3 (or Atmel-ICE).

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I checked and SAM4L has a trace implementation called ITM and D21 MTB. D20 has none. For all that I am really happy that I checked this up before doing my switch into ARM. I even have a designed board with a D20 and I will switch that into something else. Now I of course is curious about the difference between ITM and MTB.

 

For my AVR One! I will try a refund. It is a very nice looking brick but if I got it right I cannot even use it for ARM and for AVR it is only has the benefit of a nice outfit compared to ICE3.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So for us 8-bitters the main advantage is that whenever you pick up your target board to put it away but having forgotten to disconnect it, the debugger will stay on the bench. For all the other ICEs the separation point would likely be beyond the ICE.. ;-)

 

And if you have colleagues close by, it looks impressive compared to their Dragons. :-)

 

And Bengt; if you can afford the Yokogawa then the $700 for the ONE! is merely a handful of change, right? ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Oct 15, 2015 - 05:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, I actually has a number of students passing by and as well many visitors as everyone takes them to our lab because it is something to show compared to offices. Maybe I should line up all my debuggers just for show. The students will think "Wow, Bengt has an impressive set of tools" while they have to stick to dragons or ICE3. I also have a Yokogawa oscilloscope that also look a bit more fancy or unusual compared to most scopes.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the AVR simulator do trace?  Would that be useful, or do the situations where traces is desirable all stem from unpredicted external events?

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the AVR simulator do trace?  Would that be useful, or do the situations where traces is desirable all stem from unpredicted external events?

Closest it gets is "stimuli and logging" but I don't think that logging includes a full trace of code execution.

 

I was going to point you to the page in the manual but beneath this:

 

http://www.atmel.com/webdoc/simu...

 

I cannot actually find any mention of logging. Certainly AS4 had both stimuli and logging - maybe AS6/7 only has the former?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trace is enabled for all simulator models, and is non-intrusive regarding code. Timing is a different matter...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does that include AVR tiny/mega? (remember the OP here is asking initially about mega32)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the simulator is not dependant on any OCD in the chip, so you can trace the tiny10 if you like :-).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See this page about ITM and MTB. http://www.keil.com/support/man/docs/uv4/uv4_db_tp_features.htm

It depends on what ARM core it is. MTB (in M0+) only tracks program flow changes (which is enough for a basic trace) while the ITM (in M3, M4) is more advanced.

 

Both Atmel ICE and JTAGICE3 supports ITM! I couldn't find if any of them supports MTB. Not a word about MTB in the help pages of the tools so maybe they do not.

 

I also found a difference between them! JTAGICE3 support ITM at 1 MHz while Atmel ICE support it in 3 MHz!

 

Note that IAR I-Jet supports MTB in an unknown speed and I-Jet Trace supports both MTB and ETM (even more advanced than ITM) in 150 MHz. I suppose you get something for the bucks.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MTB does not need any special intervention from the debugger, so the debugger user guide does not mention it... (from a debug standpoint, it's just memory access).

 

Also, MTB and ITM are completely different in what data the produce (MTB => brances ITM => Stimuli). Note that many of the other trace sources on CM3,CM4 are collectively (and wrongly) called ITM :)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
ARM DS-5 has tracing.
Only for Atmel SAM9 and SAMA5.

http://ds.arm.com/developer-resources/supported-devices/#Atmel

ARM recommends Keil MDK-ARM for other Atmel:

http://www.keil.com/ulinkpro/chips.asp

Though the price of a Keil ULINKPro is about double that of an Atmel AVR ONE! it might be reasonable.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you moelsen. All this explains why there are so many confusions about trace capabilities. And it is a shame because trace is sometimes extremely powerful.
Also, i wonder if, just if, AVR one! would have supported ARM, what performance would it had?

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.