Multicore Programming on Tricore

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
I am trying to write a program on the tc299 which uses two cores. I have based the design off of one of the software platform demos. Additional interrupt rountines were added, but whenever I try to change the service provider from CPU0 to CPU1 the interrupts are no longer called. Why will the interrupts only run on CPU0? How might I go about fixing this? Additionally, I would like to add a main program to another cpu. I have read the application note AP32201, which was mentioned in another thread, but was unable to figure out how to do this. I am also aware of the tc_blink example program, but this seems to be on a different level of abstraction than the software platform examples. Are there any other resources for doing this, or could someone give me some help?

Thanks
0 Likes
9 Replies
lock attach
Attachments are accessible only for community members.
User9888
Level 3
Level 3
Hi,

I reworked one of my examples to address both of your questions. You'll find it attached to this thread. I've done a quick test and it works on a TC277 application kit. That means you'll have to rework it a bit to make it work for TC299 instead.

A couple of things worth mentioning upfront. Within the linker misc options I added the --non-romable command line option, which means in my case all code is located in ram. That means I had to do some tweaking to make it all fit, but has the added advantage that in the debugger options I can disable the "program flash when downloading" checkbox and safe some time. Also note that in the "startup configuration" menu I only enable tc1. This explains why the switch statement in main only addresses two cores.

The main program dynamically determines which core is executing it. For tc0 it redirects to core0_main, which simply contains a while-forever. For tc1 it redirects to core1_main and starts blinking an LED through GPT12. Note that in both IFX_INTERRUPT and IfxSrc_init associate the interrupt to the proper service provider.

Note that if your LEDs reside on a different GPIO port, or pins, you will need to adjust the pin-mapper document and the IfxPort_togglePin function in function core1_main.

Let me know how this works out.

Best regards,

Henk-Piet Glas
Technical Product Specialist

0 Likes
Not applicable
Thanks for the help. I also happen to have a tc297 application kit, which has an led on the same pin. I believe that I have made all of the necessary changes to the pinmapper and program, but I cannot get it to work. Upon entering debug mode, the whoami function returns CPU0 on the first pass and then appears to get stuck in the never ending loop, so the interrupt routine is never called and the led does not blink. Perhaps I have not made the correct changes, but I will try and adapt it to work with the tc299 program that I have written..
Thanks
0 Likes
User9888
Level 3
Level 3
sgreene wrote:
Thanks for the help. I also happen to have a tc297 application kit, which has an led on the same pin. I believe that I have made all of the necessary changes to the pinmapper and program, but I cannot get it to work. Upon entering debug mode, the whoami function returns CPU0 on the first pass and then appears to get stuck in the never ending loop, so the interrupt routine is never called and the led does not blink. Perhaps I have not made the correct changes, but I will try and adapt it to work with the tc299 program that I have written..
Thanks



OK,

Let me know how that works out. It could be a quirk in the debugger, I'm not sure. I generally try to give it a free run first, but there are some specifics to it which maybe are best demonstrated by means of the following snapshot.

2196.attach

Note that the application is represented as a parent node with - in this case - three threads below it, each representing one core. You can select each one with your mouse. For lack of a better name, I'm going to call this the core selection bar. Following a reset this bar 'lands' on the first. If you hit 'continue' at that point, or step it the way you did, all other cores are halted while doing so. If however, following your download, you manually place the core bar on the parent and _then_ hit 'continue' all cores will start running concurrently. You also see this in the above snapshot, as all have state "running". I've had it a couple of times also where I first had to reset the target, then place the core bar on the parent, and then hit 'continue'. You may want to try that as well, if it doesn't work the first time.

Good luck,

Henk-Piet Glas
Technical Product Specialist

0 Likes
Not applicable
I am experiencing the same problem with your program as I am with mine. If I switch the blink program from running on core 1 to running on core 0 the led blinks and everything works. I have made sure that all cores are running in the debugger and in the startup configuration. I also added print statements to ensure that the led was not a problem. Interestingly enough switching the provider for printf in my program to core 1 still works, but nothing else can run on core 1. Perhaps it is a problem with the debugger, but I am at a loss what to do. Are there any odd settings in the debugger that might cause this?
0 Likes
lock attach
Attachments are accessible only for community members.
User9888
Level 3
Level 3
sgreene wrote:
I am experiencing the same problem with your program as I am with mine. If I switch the blink program from running on core 1 to running on core 0 the led blinks and everything works. I have made sure that all cores are running in the debugger and in the startup configuration. I also added print statements to ensure that the led was not a problem. Interestingly enough switching the provider for printf in my program to core 1 still works, but nothing else can run on core 1. Perhaps it is a problem with the debugger, but I am at a loss what to do. Are there any odd settings in the debugger that might cause this?


Hi,

Everything's possible. However, it seems to be handling the download properly because you get to the point of the main entry point. That's generally a good start.

Although at this point we don't support either of the application kits that you're using I don't suspect that to be the cause either. If you want to do things right you'd therefore have to create a self-made target board specification that reflects your board, and use that instead of the triboard configuration that you've probably using now. But, as said, I don't think that to be the cause since it fails following from the main entry point.

I returned to the code and this time targeted it to an officially supported TriBoard. In my case TriBoard TC2x8 fitted with TC298. I can't get it to run because it traps when using IfxPort_Io_initModule to initialise P33.6. Since it has so few properties that it can go wrong with I'm not really sure why that is. I chose the pragmatic solution whereby I initialise the LED myself and then I can get it to run as before. I have attached the results. In terms of code there isn't much of a difference but I though you might want to take a look at it.

If the fault behaviour persists it might be worth halting the application and clicking each core in the debugger. Per core it will then show you where it's at. Often I find the disassembly window revealing because it can show you whether the program counter has gone AWOL (pointing to an address that doesn't match any of the addresses in your map-file) or maybe even halted because of a trap. In case of the latter you will have to establish which trap it was and see whether it provides any hints as to what may have gone wrong. The former may be a bigger challenge. I wouldn't immediately know where to start searching in that case.

Best regards,

Henk-Piet Glas
Technical Product Specialist

0 Likes
Not applicable
If anyone was following this thread I did eventually figure out that, as Henk tried to point out in the first post, you have to change the startup configuration to actually start both cores. Specifing that you want a multicore project in the creation wizard is not enough. Doing this only includes the startup files for each CPU, but does not, as I had thought, actually start the CPU. Go to Project Window>properties for >C/C++build>startup configurations and click start tc1 and tc2. If upon lauching the debugger there are no function calls under CPU 1, this is likely your problem. Otherwise using the project that Henk provided is very useful for figuring out how to implement multicore programs. Thanks for the help.
0 Likes
User9888
Level 3
Level 3
Hi,

sgreene wrote:
If anyone was following this thread I did eventually figure out that, as Henk tried to point out in the first post, you have to change the startup configuration to actually start both cores. Specifing that you want a multicore project in the creation wizard is not enough. Doing this only includes the startup files for each CPU, but does not, as I had thought, actually start the CPU. Go to Project Window>properties for >C/C++build>startup configurations and click start tc1 and tc2. If upon lauching the debugger there are no function calls under CPU 1, this is likely your problem. Otherwise using the project that Henk provided is very useful for figuring out how to implement multicore programs. Thanks for the help.


Good to hear the example worked for you, once all cores were up and running. Glad I could help!

Best regards,

Henk-Piet Glas
Technical Product Specialist
0 Likes
User9888
Level 3
Level 3
Hi,

Thought some of you might be interested to hear that some of the aspects that I addressed here, have been poored into an application note that you'll find here:

http://www.altium.com/white-papers/appnote-aurix-multi-core-tricore-programming-essentials

In addition we made a matching offline desktop recording that follows the same storyline:

http://go.altium.com/tasking-tricore-webinar-september-2016-recording.html


Best regards,

Henk-Piet Glas
Technical Product Specialist

0 Likes
User12303
Level 1
Level 1
thanks, i see
0 Likes