Infineon AURIX™ TriCore, looks interesting

[legacy]

Infineon TriCore, AURIX™ 65nm die
what do you think about, guys ?



edit:


there is also an arduino-like board

[coppice]

Interesting. I thought the Tri-Core died off a long time ago.

[Sal Ammoniac]

Yes, very interesting. Is there a development environment other that the Arduino IDE? Eclipse/GCC perhaps?

[legacy]

TriCore getting started with HighTec 

I need more time to search for the best development tools 

[legacy]

TriCore Family brief (pdf)

[gocemk]

Interesting. I thought the Tri-Core died off a long time ago.

Infineon TriCore's were used in Bosch EDC 17 ECU's for diesel motors and in their petrol counterparts in EU vehicles (VW Golf Mk7 & other VW from same era, BMWs, Audis and Mercedeses from 2010 onwards). I left that industry 4 years ago, so i am not sure about the current status of the TriCores in automotive but they were quite common (dominant) 3-4 years ago.

[coppice]

It looks like infineon is the only one of the original partners still using TriCore in modern devices. I tried Googling for the other partners, as I can't remember exactly who was on the list. No Luck. Is infineon, NXP and Freescale correct?

[stfsux]

BROM / Key Flash <- if it's the bootrom with a kind of "secure boot" for checking firmware signature, that would be an interesting feature!

[tszaboo]

Friendly advice:
Don't touch Infineon microcontrollers.

[Jeroen3]

So they made a MCU with 3 cores running the same code to see if the cores are broken?

[legacy]

Friendly advice:
Don't touch Infineon microcontrollers.

why not ?

[JPortici]

So they made a MCU with 3 cores running the same code to see if the cores are broken?

I think so. "Lockstep core" on core 2 and 3 would suggest so

[0xdeadbeef]

They are still used a lot in automotive applications and the older Tricore "Audo" controller had a somewhat interesting timer cell concept like ten years ago but IMHO Infineon doesn't have the experience to develop proper multiprocessor systems. While the Tricore MCUs were always plagued by fragmented memory with dozens of weird buses and an inefficient cache implementation, this seems to have become even worse with their multicore architecture.

[Sal Ammoniac]

Friendly advice:
Don't touch Infineon microcontrollers.

Want to elaborate? We use Infineon MCUs here and are quite happy with them and Infineon's support.

[Scrts]

We use Renesas, ST and Freescale at the moment, but this is in automotive company. This discussion and board is actually interesting. I wonder if there's anything else usable for small companies and startups? You can't jump to a major microcontroller, full AUTOSAR suite, buy MCAL, etc...

[tszaboo]

Friendly advice:
Don't touch Infineon microcontrollers.

why not ?

All I have experience is their C166 8 and 16 bit processors, or whatever they are called. They are a despicable hack job, never worked as they should. In a mature product (like 10 years of production) we found issues not in the errata. The programmers hated it, I had colleagues who quit, just to get away from working with it (and dead end "legacy support" project).
 I would not be surprised, if their 16 bit microcontroller is just two 16 bits glued together with chewgum. And they are expensive, for no good reason.

[0xdeadbeef]

Well, at its time, the C167 and its derivatives weren't so bad (I faintly remember there where issues with the embedded flash though). Anyway, that's like 20 years ago. Even  ~18 years ago there were better 32bit alternatives on the marked like the Hitachi SH7055 which I think might live on to some degree in current Renesas controllers. Anyway, the original "Audo" Tricore processors are actually quite old. Like the last time I used them at work was eight years ago and they weren't new back then. As stated before, the only thing worth mentioning was their timer cell arrays (GTC/LTC) but they had some weird design decisions like only one small RAM block being DMA capable, another one wouldn't allow atomic access and so on. Also when the frequencies increased above what the flash could deliver, they implemented a very poor cache strategy where loading constants from flash would cripple the performance because cache lines with instruction could be dropped, so you had to avoid using ROM constants. They even implemented another special RAM (scratch pad RAM) for the interrupt service routines as interrupt routines in flash would also cause cache/performance issues.
I haven't worked with the Aurix multicore processors myself (yet), but what I hear is that they really glued three "Audo" cores together and as they still didn't manage to develop a proper cache design they added processor specific RAM instead of fixing the cache consistency issues by a proper design. I understand even the newest Aurix cores don't have an MMU which is somewhat embarrassing. This also means that to swap from a ROM calibration to a RAM calibration during development, you need to use their pityful overlay registers instead of switching MMU entries. Meh.
Anyway, peripheral wise, the Aurix MCUs now feature Bosch's general timer module (GTM) instead of the timer cells (LTC/GTC) and peripheral controller (PCP) in the Audos. Haven't used it myself, I understand it's pretty complex (with command sequencers) but still limited to 16bit and 24bit timers.

[stfsux]

They are a despicable hack job, never worked as they should. In a mature product (like 10 years of production) we found issues not in the errata. The programmers hated it, I had colleagues who quit, just to get away from working with it (and dead end "legacy support" project).

Sounds like fun, ive never used this type of microcontroller.
Please tell us more about it.
Im not feeding the troll, im just curious.

[Jeroen3]

@0xdeadbeef, sounds like a typical day fighting on-chip-external ROM and RAM on a 8051 sold today. If you're careless, your application grinds to a halt very soon.

[tszaboo]

They are a despicable hack job, never worked as they should. In a mature product (like 10 years of production) we found issues not in the errata. The programmers hated it, I had colleagues who quit, just to get away from working with it (and dead end "legacy support" project).

Sounds like fun, ive never used this type of microcontroller.
Please tell us more about it.
Im not feeding the troll, im just curious.

I dont know. I was working as a PCBA designer, not a programmer. It was only discussions at the dinner table. Luckily, I never got involved with the micro itself. And though management was pushing it for some reason, I dodged it every time. Should have not called it "experience".
As 0xdeadbeef said, they were probably OK, 20 years ago. Now, I was only meeting them, when they were in the legal age to order beer in a bar.
In general, I dont like Infineon as a company, did not like Siemens either. They just do bad job, when it comes to electronics engineering.

[tiger99]

Just thought I should post that as I have newly discovered this forum, and spotted that there was some feeling that the Aurix was a dying product. Fortuitously, I happen to have some on-going experience of it.

The Aurix is very much alive and is in fact being used by a large worldwide manufacturer, not of vehicles themselves, in a number of new and upcoming automotive products with a projected production life of many years. Indeed we are awaiting the arrival of a (cheaper) variant with less memory than the one that we are using on second-stage prototypes right now.

Personally I do not like them at all, as there is a great deal of hardware complexity, and therefore an immense amount of software detail that has to be just right. Simplicity is important for safety and reliability. But the various I/O blocks can do a lot by themselves without CPU overhead, once initialised. I do recommend a close study of the data sheets, there is much more there than you will think at first glance! Oh, and if you want MANY 12 bit analogue inputs, some fast, look no further!

Our product has a number of ASICs as well as the CPU, mixed technology with analogue bits, high voltage drivers and low voltage CMOS logic on the same chip, and as those are our own intellectual property, made by one of the well-known foundries, and used for years, they are quite affordable, as is the CPU. But development tools for the Aurix are eyewateringly expensive...

Which is why I prefer the TI TMS570. Dual core with error checking, but a lot simpler and based on the ARM architecture. Development boards are very affordable, much like an Arduino, I have two at home. The main development tool, Code Composer, is now free and runs on Linux or the other inferior operating system. What is there not to like?

[Sal Ammoniac]

Personally I do not like them at all, as there is a great deal of hardware complexity, and therefore an immense amount of software detail that has to be just right. Simplicity is important for safety and reliability. But the various I/O blocks can do a lot by themselves without CPU overhead, once initialised. I do recommend a close study of the data sheets, there is much more there than you will think at first glance! Oh, and if you want MANY 12 bit analogue inputs, some fast, look no further!

Where did you find the data sheets/reference manuals? I searched the Infineon site and couldn't find anything. Do they require an NDA?

Our product has a number of ASICs as well as the CPU, mixed technology with analogue bits, high voltage drivers and low voltage CMOS logic on the same chip, and as those are our own intellectual property, made by one of the well-known foundries, and used for years, they are quite affordable, as is the CPU. But development tools for the Aurix are eyewateringly expensive...

The Infineon site had something called the TriCore Entry Tool Chain, which is based on Eclipse/GCC and is free to download and use. I also found a board called the ShieldBuddy, which is around 100 Euros. Are additional, expensive, development tools needed?

Which is why I prefer the TI TMS570. Dual core with error checking, but a lot simpler and based on the ARM architecture. Development boards are very affordable, much like an Arduino, I have two at home. The main development tool, Code Composer, is now free and runs on Linux or the other inferior operating system. What is there not to like?

Is it a true dual core, or just a lockstep core? Can you decouple the cores so they can execute code independently rather than just in lockstep?

They're based on the Cortex-R -- what advantages does that have over a Cortex-M running at the same clock rate? Cortex-M seems to be a much nicer architecture, especially with respect to interrupts and exceptions.