AURIX™ Forum Discussions
Currently I perform some Application Performance Optimisation and follow the Infineon Appnote AP3216810. One topic is to shift critical functions from PFLASH0/1 into the own PSPR0/1/2 of the respective Core.
But what about functions which are frequently used by all cores? In my case this is memcpy. I currently investigate to shift them also from PFLASH0 into PSPR1. It is clear that Core0/Core2 then need some extra cycles for instruction fetch from other PSPR1. But even worse in TriCore TC1.6.2 core architeccture manual, it is stated that segment 7H - 0H is Non-cacheable Memory. For own PSPR this is desired, but what about execution of code from foreign PSPR on Core0/Core2? Does this mean that due to uncached memory extra CPU cycles accumulate by each count of the of the memcpy function? I fear that this makes the situation even more worse on Core0/Core2 compared to just running it from cached PFLASH0 on all cores?
The other choice would be to use DLMU1, which is slower than PSPR1 but probably faster than PFLASH0 and cached for all cores.
One other idea is to duplicate the memcpy function and add it as memcpy_CORE0, _CORE1 and _CORE2 and put it into the respective PSPR for each core, and leave the original memcpy in PFLASH0 (since it is also used by crt0 for initialisation of variables). But is it that worth?
Is there any best practice which memory to use for common functions: PFLASH0, PSPRn or DLMUn?Show Less
I am developing an application for TC377 on TASKING compiler.
the current application takes up about 0.8MB of space.
currently the interrupt vector table (INTTAB) is positioned at the end of the 6MB of space available, and everything works fine. I also tried to move it to a position less distant from the end of the application (for example at the end of the first MB) and it continues to work regularly.
I would need to move it before application. if I try to do this the application crashes (I understand that it crashes at the first interrupt it receives). but strangely if I try to debug it everything works fine.
Can anyone help me?Show Less
AurixFlasher - DAS::Error: Device reset could not be performed.
Overall time: 732 ms
AurixFlasher Exit Status: Fail
What does this error means? The code for reading single channel through ADC is able to flash. But this error occurred when I tried to flash the code to read multiple input voltage through ADC. The code have 0 error, but can't flash. How to solve this issue?
It's not a Hardware issue since I can flash other programs.Show Less
Got a question regarding the Aurix MPU protection / access to flash...
Range based memory protection is enabled.
Access to flash on non-cached address’ (0xAxxx_xxxx) and cached address alias (0x8xxx_xxxx).
Effective address’ fall outside of all defined ranges (DPRx_L/U, CPRy_L/U)
- Access to 0x8xxx_xxxx causes Protection Trap (as expected)
- Read-Access to 0xAxxx_xxxx passes (expected: Protection Trap)
- Write-Access to 0xAxxx_xxxx causes BusError (expected: Protection Trap)
Is there anything specific for segment 10 wrt. to memory protection (e.g. any implicit access)?
Issue was reproduced with a TC375 and a TC397 with Lauterbach debugger.
May I ask if we can use GTM-TIM module as the quadrature decoder to determine the speed and position of the inputs signals?
If yes can you please help to give me some pointers for more readings or suggestions?
Thank you so much.Show Less
For MPN: SAK-TC277TP-64F200N DC, 2 OPN and SP# observed.
Kindly pls help to explain the different and will it affect functionality?
Thanks a lot!
As is shown in the pic, after 1.3 supply on about 130us, the OSC is starting up, but then the wave is decreased and off, and until now the ESR0 is not released yet.
The software is stopped on the start-up code, and clock is not initialized.
And another question is the default value of OSCCON is not matched on the UserManual, PROCONDF is 0x00000000 in UCB:
Could you tell me why OSC start-up before software initialized it and then get turn-off?
I have an AURIX TFT eval board with a TC397. I have been following Chapter 21 of the User Manual part 1 to configure the Extended Memory (EMEM).
I enable the module (IfxEmem_enableModule), then unlock it (IfxEmem_setUnlockMode) then configure the tiles for common memory mode (IfxEmem_setTileConfigMode with mode=IfxEmem_TileConfigMode_commonMemoryMode).
I get a good status back when I check the results:
SBRCTR Register 0x00010001 STBPON=standby power is enabled, and Unlocked mode
CLC Register 0x00000000 EMEM is enabled
TILEECC Register 0x00000000 Application mode
EMEM_TILESTATE Register 0x00000000 = Common Memory
But if I now try to write to a 32 bit value from the TriCore to a valid address in EMEM, such as address 0x99000000, it immediately goes to a bus error.
Am I not able to use EMEM like normal memory, or am I not using it correctly? Or maybe there is more configuration that I have missed before I can use it like normal memory?
I have a TC265 B-Step on a custom board with the debug interface lock enabled in the UCB.
I am able to connect to the microntroller with the correct password using the Memtool in combination with the miniWiggler 2.0 and DAS V7.1.8 64 bit. However, if I deinstall this version of DAS and install DAS V7.3.7 64bit, I am not able to connect and unlock the debug interface anymore. But normal connect on TC265 B-Step devices with unlocked debug interfaces still works.
Is this a bug of the current version of DAS? Or am I missing some configuration?
Any help is much appreciated, since I would like to use the current version of DAS.
I would like to know how long we have to setup or deactivate a watchdog after the power ON on a TC265.
I didn't find this information on user manual.
If I consider the Timer value is initialized with 0xFFFC and clock diviser initialized to 16384, I found a period of 0.5 ms with is very low.
What is the correct value ?Show Less