|
Are there plans to support Infineon's Tricore architecture? The MCU's ASIL rating goes up to ASIL-D and Infineon is a very popular choice for automotive MCUs, so it seems like a great fit considering Zephyr is targeting ASIL-D. |
Replies: 24 comments 81 replies
|
Bump, any update on this? |
|
@ilanbiala no plans currently however, we would consider any contributions supporting this architecture. |
|
@ilanbiala I have a received xmc4000 based development board today. I will start working on this for Zephyr support. I will be able to start for Tricore after this. |
|
Please submit a Pull Request |
|
@parthitce just wanted to see if you ever got a chance to work on Tricore support? |
|
@ilanbiala Yes I did ported the arch parts of the Zephyr with the help of Aurix 2x ISA. But the board which I have from Infineon is based on Aurix 3x and it's not straight forward with the ISA for 3x series. I had to go via various NDA process which is almost done and waiting for Infineon to release the ISA in their collaborative platform. IFX HAL is BSD licensed in general, but am still not sure about the open sourcing the IFX based in 3x. But HAL for 2x is possible. So the SoC porting is yet to be done and waiting for the ISA and license clearance from Infineon. I used the Toolchain from hightech (close sourced), but there is also an attempt to port the GCC backend for tricore from my end. GCC backend work is posted here: https://github.com/parthitce/gcc, but it's long way to go. I will push the WIP tree for tricore Zephyr port once I get the license clearance from Infineon. |
|
Awesome @parthitce, glad to hear that things are at least progressing! Any easy way to follow what's going on? |
|
@mgiaco But in short, Linumiz and I myself handling this. |
|
Hey, whats the status on the tricore port? I have quite some experience with the tc3xx devices and a few boards to hand. I just saw one commit in the branche there. |
|
Is there any update on this? |
|
Is there any update on this? |
|
No immediate plans |
|
Hey, I startet the work to add Support for tricore Architecture. I'm able to Boot my tc37 and context switching is mostly done. Irq and gpio are next. Then I'll publish what I have, but the rest is up for debate. |
|
Hey, I'm currently checking on how to publish my results with my employer. I'm actually done with all the required drivers and arch support. |
|
That would be great. For our project we’re using gcc 11. Currently I run it via wine after extracting it from ADS, but I’ve just built tricore-gcc 11 for Linux and will switch to that if there are no issues. |
|
Can you write me an email christoph.seitz@infineon.com (also in german) and we can set up a meeting. I'm interested in your use case and then we can discuss how we can support you. |
|
I'd be super interested in this as well. I have quite a lot of hardware to test with. Would you be able to share your work privately? I might be able to help with some development. |
|
new release planned for AURIX TC3 and TC4 very soon (Feb 2026) See progress here: Infineon: Aurix Zephyr RTOS Upstream (view) |
|
I found nuttx has tricore support nuttx_tricore |
|
Very cool! |
|
see new release here in the downstream: https://github.com/linumiz/nuttx/releases/tag/v1.0.0-tricore |
|
You find the current progress under: https://github.com/go2sh/zephyr/tree/tricore Supported boards: Current compilers supported are: CMake options for gcc are: CMake options for clang are: |
|
Quick update, Infineon did share the Linux version of the DAS service, I haven't been able to get it to work sadly. It uses some out of band ftdi library instead of the linux ttyUSB system, so you have to do a little dance to prevent linux from grabbing the device in order for the ftdi library to find it. |
|
@photex could you share the link? In the end I just setup a windows machine on my network and created a remote access through VSCode+SSH to improve a bit my developer experience |
|
https://softwaretools.infineon.com/tools/com.ifx.tb.tool.infineontoolaccesssockettas 8.0.5 is available for Linux. |
|
Thank you @photex , I was able to install and started to pick some traces of what is going on inside of this TAS runtime, if I find something useful I'll comeback here to share. |
|
Do you still plan to publish? |
|
Can you check if the Board file mentioned is there? Maybe there is some spelling error. Deleting the cmake cache and zephyr cache might help as well. |
|
@go2sh @uLipe looks like I might have ran something out of order... started from scratch and I can get further in the build. Thanks for the help! I'm now getting the following: Still looking into it but figured I would ask in case any one else hit it. |
|
Hey @cperkulator , sorry for the late response, I was in a hurry at my work. I faced the same problem as you, doing a clean rebuild resolved this issue. I don't see what is behind of such problem. |
|
I'm experiencing the same issue as @cperkulator. I'm trying to reproduce the issue under GDB like this: This is the backtrace I get when linkink zephyr kernel: This is the portion of code that fails: static void
lang_memory_set_current(lang_memory_region_type *r, bfd_vma dot)
{
lang_memory_region_mirror_list *l;
lang_memory_region_mirror *gr;
bfd_vma offset;
r->current = dot;
offset = dot - r->origin;
for (l = r->mirror; l; l = l->next)
{
for (gr = l->mirror; gr; gr = gr->next)
{
/* do not set backward
if one region is in multiple groups the DOT may have been
increased due to an allocation in one of the other regions
*/
if (gr->region->current < (offset + gr->region->origin) )
gr->region->current = offset + gr->region->origin;
}
}
}This is a piece of code added in EEESlab/tricore-binutils-gdb@78991a3 to support linking for Tricore architecture. After a quick and not-so detailed look, it seems that the linker espects the ROM memory region to have a mirror, which is actually not initialized, and the dereference of an invalid pointer causes the Segmentation fault. Maybe the problem is in the tricore LD linker script provided by @go2sh , but I'm not an expert and could be wrong For me, doing a clean build does not solve the issue. PS. If it's useful to someone, I added Github Actions to build and release tricore-elf-gcc executables for both windows and linux in my fork: https://github.com/NoMore201/tricore-gcc-toolchain/tree/main You can find last build in the Release section |
|
UPDATE: after a more detailed look, it seems that this PR fixed the above mentioned Segmentation Fault: EEESlab/tricore-binutils-gdb@2283fc7. The problems is that struct |
|
Hello guys, is there already support of ZEPHYR for Infineon Aurix device (TC37xx, TC36xx)? |
|
See the comment below. NDA is the main point for TC4 support. Customers with NDA can get access to it. |
Please email me to: ak.alexander.kozhinov@gmail.com |
|
@go2sh I suppose the foundation already made can be used as well for supporting the TC27x, right? They are the target chip I'm using currently. |
|
Sure, I think there could be a lot of reuse happening. But I have never worked with tc2. :) |
|
Great to hear, currently I'm tweaking your branch to get it working to the TC27x evaluation board I have in hands, I think it is time to add proper device tree for this soc even though is very minimal, are you generated the dts files for the TC3 target using any automation script or by just using the information from the reference manual? Thank you. |
|
btw what tools to be used? |
|
I don't think it can be built with the TASKING compiler, used by AURIX development studio. You need a GCC/Clang compiler. Personally I used the open source tricore-elf-gcc EEESlab/tricore-gcc-toolchain-11.3.0. You can build the compiler yourself, or grab a pre-built bundle from my fork: https://github.com/NoMore201/tricore-gcc-toolchain/releases. Check out Zephyr getting started guide and this comment for further information #68826 (comment) |
|
Are you assuming to add the TriCore Aurix port as official ZEPHYR clone and supported board ? |
|
As a general status:
|
|
It would be great if they made the work on it public. |
|
@cperkulator I hope too, but having worked with Infineon MCUs in the latest years, Infineon doesn't seem to be the kind of company to easily share its work to the public under an open license. Happy to be proven wrong of course. |
|
@go2sh how is the port going? I should have some free time the next couple weeks to test things out. |
|
If anyone is interested I rebased tricore-gcc implementation to 13.3 https://github.com/NoMore201/tricore-gcc-toolchain/releases/tag/13.3-20250516. This toolchain also includes a pre-built QEMU executable and tricore-elf-gdb with @go2sh patches for correct frame unwinding |
|
Nice addition I put this on my to-do list to test on the weekend :) |
|
Hello everybody, I have good news for you. TC4 has launched publicly a few weeks ago and I'm able to upload the complete port, which has been internally maintained to github. This includes furthermore fixes for TC3x devices. I'm currently cleaning up the code and I'm in preparation to upload a downstream fork under the Infineon Github (https://github.com/infineon/) repository. Once done I'll update the post. The development will carry on there and everybody interested is invited to contribute. Thank you everybody for your patience. |
|
A question to all here: Which publicly available debugger do you use for tc3/tc4 in conjunction with onboard Infineon DAS Debugger Hardware? |
|
I maintaine there a set of oss tools for tricore. Debugging works with openocd and gdb. |
|
What is TC4 in this context? |
https://documentation.infineon.com/aurixtc4xx/docs/ukk1718002103459 |
|
Got it, I figured but from what I saw it was announced earlier publicly in 2024 already so wasn't sure. |
|
Ping @go2sh , do you think the downstream fork with the TC support will be published this year? Thank you! |
|
@go2sh I'd also like to know if there is any plans for upstreaming the TC4 support. |
|
See comment from @parthitce . We worked very hard the last few months on the upstreaming and are finally there for tricore. More to follow.🎊 |
|
The TriCore architecture and Infineon AURIX platform support PR is now open: #107516 Covers TC3x (TC1.6.2P) and TC4x (TC1.8P), three hardware boards, QEMU targets, and six peripheral drivers. Details in the PR description. |
|
Thank you. I'll give it a try. |
|
I would like to ask, is it currently supported to compile in the Windows environment? |
|
Technically yes. Zephyr should be possible with Windows as well. w.r.t, you will be needing compiler for Windows and it should work. I haven't tested it myself with Windows. |
|
Thank you for your reply. Currently, I have tested both TC3x and TC4x on Windows using the HighTec toolchain. Among them, TC3x uses the cross-compile setting during the compilation process. However, the HighTec toolchain under Windows is unable to print the sys-root parameter, which leads to the compilation failure. I'm not sure if the "cross-compile" setting for the gcc toolchain is correct when used on Windows. When executing the TC4x compilation, the host/llvm used requires:
After making this modification, the TC4x project can be compiled normally, and after being burned onto the board, it can correctly print the information. |
|
Thanks for testing it in windows. I will review the changes needed and will address it in next push to upstream. |
|
Hi .all, you find the current downstream repo with our developments efforts here: https://github.com/Infineon/zephyr-aurix |
The TriCore architecture and Infineon AURIX platform support PR is now open: #107516
Covers TC3x (TC1.6.2P) and TC4x (TC1.8P), three hardware boards, QEMU targets, and six peripheral drivers. Details in the PR description.