Using openocd with an Infineon Aurix TC3xx cpu. 3/13/2025 brad@heeltoe.com
This will allow you to program the flash on an AURIX TC3xx cpu and control it somewhat. It doesn't replace a full blown debugger (like an iSystems bluebox) but it does allow for use cases like automation and will allow you to automate a test stand so you can fully erase the flash, reset the target, program it and run code.
The basic picture is:
+--------------+ +----------------------------------------------+
| TC3xx target | <--DAS--> mini-wigger <--usb--> | linux box; FTDI driver + TAS + aurix-openocd |
+--------------+ +----------------------------------------------+You will need:
a linux computer runnig Ubuntu 22.04
"mini wiggler" USB tool [mini-wiggler]((https://www.digikey.com/en/products/detail/infineon-technologies/DAPMINIWIGGLERUSBTOBO1/20485597)
An AURIX TC3xx target TC375 dev kit
Some time and patience
Open an Infineon account so you can download the TAS server
https://softwaretools.infineon.com/tools/com.ifx.tb.tool.infineontoolaccesssockettas
Download the x86 64-bit FTDI driver
https://ftdichip.com/wp-content/uploads/2025/02/libftd2xx-linux-x86_64-1.4.32.tgz
download openocd from github
git clone https://github.com/lisper/aurix-openocd.git
Using Ubuntu 22.04:
Pull aurix gcc, gdb and openocd from github
build and install them all (no small task)
download and install infineon "TAS" debug interface
download and install FTDI driver
build example using aurix gcc
debug it with stock "ddd"
I've configured everything so it gets installed in /opt/aurix. My
recommendation is to make sure you can create files and subdirs under
/opt/aurix. That way you can build and install things as your
native user without playing with sudo.
I run everything in a separate window. You could use "tmux" or X windows. I would start the TAS server, openocd and gdb in separate windows so you can see their output.
FTDI driver Just unpack the tar file and copy the ".so" shared library to the same subdir as the TAS server.
The library you want is called "libftd2xx.so". In the tar file it's in the subdir "linux-x86_64/libftd2xx.so"
TAS
TAS is part of "DAS v8". You should download the file DAS_v8_0_5_Linux.tar.gz
from Infineon. Unpack the tar file.
Once unpacked in DASv805/TASV110/bin you will find tas_server which is a linux executable.
tas_server must be run as root, on the same machine which has the "mini-wigger" connected via USB.
The TAS server needs the FTDI shared libary and you need to tell it where to find it using LD_LIBRARY_PATH.
Blah blah blah.
Run the TAS server like this:
sudo -s
LD_LIBRARY_PATH=. ./tas_server
It will just sit there and run with no output.OpenOCD Once the TAS server is running, you can run the openocd server on the same machine.
/opt/aurix/bin/openocd -f board/infineon/kit_a2g_tc375_lite.cfg -s /opt/aurix/share/openocd/scripts
Starting openocd should produce a bunch of output showing it connecting to TAS
and finding your target. This is assuming you plugged in a mini-wiggler to USB
and connected that to a TC3xx target which has power.GDB Aurix gdb gets installed as /opt/aurix/gdb/bin/tricore-elf-gdb. You can run this as a comment and then type:
target remote :3333
When you hit return you should see the openocd program spit out some output showiung it's connected.
ddd You may have to run ddd one to create a ".ddd" directory in your home dir. Once created, modify the ~/.ddd/init file; otherwise it hangs talking to gdb:
(remove the line with "not set" and replace it with "(gdb)")
-set extended-prompt not set\n\
+set extended-prompt (gdb) \n\I use this command:
ddd --debugger /opt/aurix/gdb/bin/tricore-elf-gdb main.elf
which I run in the same directory as my firmware build output.You'll need to arrange TAS server and it's FTDI library somewhere. And once that's done you'll need to build OpenOCD.
Find a nice home for your github clones, like ~/git . Then clone the repo there.
mkdir ~/git
cd ~/git
git clone https://github.com/lisper/aurix-openocd.gitYou can build in the cloned repo, but don't. It's bad hygiene. Instead, create a build subdir and build there. Once the nice things about gnu it's it's "configure" systems which allow one to easily build in a separate directory.
cd ~/git
mkdir build
cd build`Create a file called "make-aurix-openocd.sh" in the build subdir:
mkdir -p aurix-openocd
cd aurix-openocd && ~/git/aurix-openocd/configure --srcdir=/home/brad/git/aurix-openocd --enable-jlink --enable-ftdi --enable-stlink --enable-tas-client --prefix=/opt/aurixRun the shell script to configure the build dir
cd ~/git/build
chmod +x make-aurix-openocd.sh
./make-aurix-openocd.shNow build it
cd aurix-openocd
makeIf the build completes, install it
`make install`Now you're ready to connect to the target.
There are a few github repos with promising name related to AURIX TC3 development. I've been pulling them and trying to build tools to see what I can use.
A lot of them are pretty dependent on the environment and sometimes won't build. Or won't run. But I managed to craft a version of OpenOCD which will work with a mini-wiggler and allow me to do basic work on a TC3 development board.
I'll post a recipe shortly. Given a modern day linux installation (Ubuntu 22.04) and a mini-wiggler USB dongle and a dev board it appears to be possible to do real development.
At some point I'd like to do the same with a TC4, but I suspect getting a TC4 dev board will not be an easy trick. We'll see. I grew fond of theTC4 - it's a very powerful chip.
crowdsourced FPGA multicore cpu with virtual peripherals This seems like some of the "many small cores" projects of the past, but with an application in robotics and small devices... I wonder about applying this to UAV's, or even assisted flying. Stability management. The project includes an emulator, which is a very cool idea. You can try out ideas easily and quickly to see how they adapt. I want to look more deeply into it's simulation environment...
It looks like you'll need to break out board as well to get reasonable connections (USB, HDMI). Seems like a lot can be done with that. I have not used a Zynq yet, but I have done with with the older Virtex parts which had a PPC 4xx inside.
If you are looking for FPGA board with HDMI, microSD, usb, etc... you might also consider the Pipistrello board from Saanlima
I've used it on a few projects - the larger LX45 part has a good amount of internal ram and the HDMI out is very handy.
Over the years I've done a number of experiments using Verilog, a hardware modeling language. In several of these experiments I have attempted to recreate old CPU designs like the MIT CADR lisp machine and the DEC PDP-8/I. My latest experiment is to recreate the PDP-11, in modern verlog, using modern simulation techniques.
Note that this has been done before. I know of at least 2-3 old microcoded versions and more recently there are 3 other groups which have done this, but in all the cases the code is either not in verilog or is proprietary and closed. Not very helpful.
I have not (yet) delved into SystemC, but I have done some fun work with co-simulation. Most recently I wired my RTL simulation of the pdp-11 in almost-verilog to a "known good" pdp-11 instruction set simulator. The idea is that both the RTL simulation and the instruction set simulator run the same code and at the end of each instruction cycle the results are compared. The "results" are the internal register values, the processor status word and the list of bus operations which occurred (address, type, data).
In a perfect world the two simulations will run in lock step and any deviation is a bug. And this is mostly true. The comparison turns out to be extremely helpful and very valuable.
Again, however, this is not new. I learned this technique from others who are smarter than I am.
While attempting to recreate the pdp-11 I ran into a number of interesting problems. The instruction set is fairly simple but it is not RISC. The effective address computations are complex and in many cases doubled.
Let me supply an example:.
Here is a list of the 8 addressing modes. A complex instruction can have a source operand (with one of these addressing modes) and a destination operand (with one of these addressing modes). So, in the worst case you need to compute the effective address and do one or more fetches for the source and destination.
mode symbol ea1 ea2 ea3 data side-effect
0 R x x x R x
1 (R) R x x M[R] x
2 (R)+ R X x M[R] R<-R+2
3 @(R)+ R M[R] x M[M[R]] R<-R+2
4 -(R) R-2 x x M[R-2] R<-R-2
5 @-(R) R-2 M[R-2] x M[M[R-2]] R<-R-2
6 X(R) PC M[PC]+R x M[M[PC]+R] x
7 @X(R) PC M[PC]+R M[M[PC]+R] M[M[M[PC]+R]] xSeems complex, yes? Each M[] is a memory read. The basic register indirect is simple. But modes 6 & 7 add the side effect of reading addition operand data from the next instruction location. This increments the pc as well as fetching an offset which gets added to the result of a previous EA calculation.
So, how to implement this? My first thought was a complex state machine. After a while I got frustrated and thought it might be easier just to make a machine which recodes the old pdp-11 instruction into new "risc-like" instructions on the fly. Sort of a just-in-time binary recompilation. I think this is how modern day X86 machines work. The fun idea would be to have several "machines" running ahead and converting the pdp-11 CISC instructions into simple RISC instructions, filling several FIFO's. The then RISC engine could use modern ideas like a multi-stage pipeline, speculative execution and branch prediction. While very cool, I quickly decided that was more complexity than I wanted at this stage.
I do think, however that it might make sense initially to do a simple "recoding engine" and a simple "risc pipeline". I want to do it and compare the gate count to a state machine version.
So, I set out to do a simple state machine version. I tried to compress the states as much as possible but current feel there has to be a decode state, four states for each operand, an execute state and a write-back state. The four states for each operand can be reduced to a little as one, depending on how the instruction decodes. I tried to eliminate the single EA state for each operand but instructions like:
mov @(R5)+,@(R5)+causes problems. Why? because the value of R5 is incremented twice, once after each EA calculation. If I did the EA and post-increment in one state I needed to special case the increment (to be 2x) if the both registers were equal. And it got to be a big mess. I capitulated, added a state, and reduced the complexity.
I should note here that all pdp-11's, except one, are microcoded. And I can see why.
At some point I do want to try an experiment by adding a pre-fetch unit, keeping at least 3 words available and doing the EA calculations in parallel. The EA calculation will stack up (i.e. stall) queuing up for memory reads, but it has the potential for being more efficient, especially if there is a cache which does burst reads and the line size is at least 8 bytes.
I know this might all sound crazy, but I've learned a lot in the process and almost everything I have learned has been useful in my day job.
I bought a used iphone 2G model for work. I didn't intend to use it as an actual phone. But, as time wore on, I started playing with it, and (mostly) prying it out of the hands of my 10 and 12 year olds and I've grown to like it.
Oddly, I've yet to activate it. I suppose I will soon, but the idea of spending $75/month is a little painful right now. I guess I'm paying $50/month for my current phone, so maybe it's not that much of an increase.
The most fun part for me has been the mp3 player. I have a lot of music on our home file server, all legally paid for and ripped from CD's. Except for the mp3's I downloaded directly from Amazon (THANK YOU Amazon for selling MP3's!). Anyway, all of the music is legit. And now I can load it onto the phone and listen to it as I walk to and from work. Heh - I've become one of those "young people" who wear headphones. But I swear it's great to listen to music on the way to work.
I may have to upgrade to the 3G version, however, if only for the EDGE and GPS. I think the GPS might come in pretty handy.
I'm a little sad because my sleek little MP3 playing Sony Ericson slide phone is still pretty cool. I didn't intend to cheat. It just happened.
One thing I will mention - using iTunes can be a real pain. It's a very pretty interface but for the first time user it can be pretty confusing. I spent 15 minutes trying to figure out how to get music into it from a file on my hard disk. It should not be that hard.
I should also mention that the apps you can buy (or download for free) from the Apple "app store" are pretty cool. There's a lot of things to browese through. A few too many, to be honest. I would be nice to find some place the reviews the apps and recommends the best ones. Naturally my son (he's 10) immediately downloaded the Star Wars "light saber" app. Even I find it fun after a few coctails.
Even without activation the 802.11 connectivity make it a very useful device. I can browese, get weather, stock info, you tube, send email, etc...
All in all, I like it. And I didn't think I would.