Errata Sheet - Infineon

More documents

Recommendations

Info

Errata Sheet Functional Deviations In the first case, if all the PSW[31:26] bits are cleared by UPDFL, no CAE trap will be generated. In the second case, UPDFL may still be used to set the FPU rounding mode, but in this case the remaining PSW bits, [31:26], must be cleared by UPDFL in order to avoid generation of an unexpected CAE trap. In all other cases, where FPU traps are enabled, some other method of manipulating the PSW user status bits must be used in order to avoid extraneous CAE trap generation. For instance, if in Supervisor mode the PSW may be read using the MFCR instruction, the high order PSW bits modified and written back using the MTCR instruction. CPU_TC.115 Interrupt may be taken on exit from Halt mode with Interrupts disabled A problem exists whereby an interrupt may be taken by the TriCore CPU upon exiting Halt mode, even if interrupts are disabled at that point. The problem occurs when an interrupt request is received by the TriCore CPU, with the pending interrupt priority number (PIPN) higher than the current CPU priority number (CCPN), and interrupts are enabled. In this case, where only the CPU pipeline status is preventing the interrupt from being taken immediately, the interrupt is latched and taken as soon as the pipeline can accept an interrupt. This may cause unexpected behavior whilst debugging, where interrupts are enabled before entry to Halt mode, or where interrupts are temporarily enabled during Halt mode. In this case an interrupt may be latched whilst the CPU is in Halt mode, and subsequently disabling interrupts during Halt mode, by setting ICR.IE = 0 B , will not prevent the interrupt from being serviced immediately upon exit from Halt mode. It should be noted that no corruption of the program flow is associated with this issue and that it affects debugging only, primarily the debugger single-stepping functionality. The problem may or may not be visible whilst debugging, dependent upon the implementation of single-stepping by the debugger. If single-stepping is implemented by the debugger setting Break-Before-Make (BBM) breakpoints on all instructions except the next to be executed, then if this problem occurs the next instruction when single-stepping will be the first instruction of the interrupt handler. However, if single-stepping is implemented TC1767, EES-AD, ES-AD, AD 26/73 Rel. 1.4, 11.12.2009
Errata Sheet Functional Deviations by setting a Break-After-Make (BAM) breakpoint on the next instruction to be executed, or a BBM breakpoint on the next but one instruction, the problem will not be visible. In this case, when single-stepping, the interrupt handler will be executed in its entirety before returning to the interrupted program flow and the breakpoint being taken after the next instruction to be single-stepped. Workaround As described previously, this problem affects debug only and in this case the taking of the interrupt immediately upon exit from Halt mode cannot be avoided if the conditions to trigger the problem occur. However, the debugger singlestepping functionality may be implemented in such a way that this problem does not directly affect the user, as follows: Upon first hitting a breakpoint, the debugger should read and hold the current interrupt enable status from ICR.IE. Interrupts should then be disabled by setting ICR.IE = 0 B . If the next debugger action is to single-step, a BAM breakpoint should be placed on the next instruction to be executed and the CPU re-started. In this case a previously latched interrupt may be serviced, but will not result in a further breakpoint being flagged until the interrupt handler returns and the next instruction intended to be single-stepped is executed. Subsequent single-step operations may be implemented using any appropriate method, since interrupts will be disabled before Halt mode is entered. If the debugger action is to re-start normal execution, the interrupt enable status should be restored from the value read upon hitting the initial breakpoint and the CPU re-started. DMA_TC.013 DMA-LMB-Master Access to Reserved Address Location DMA-LMB-Master goes into an unintentional lock-up state when a Read or Write access is made to a reserved memory location with an unrecognised slave. Subsequent Read/Write accesses from a DMA Channel, MLI, Cerberus or the DMA-FPI-Slave to all memory locations mapped to the DMA-LMB-Master TC1767, EES-AD, ES-AD, AD 27/73 Rel. 1.4, 11.12.2009
Page 1 and 2: Device Marking/Step Package TC1767
Page 3 and 4: 1 History List / Change Summary Err
Page 5 and 6: Table 4 Functional Deviations (cont
Page 7 and 8: Errata Sheet History List / Change
Page 9 and 10: Errata Sheet History List / Change
Page 11 and 12: Errata Sheet Functional Deviations
Page 15 and 16: Example Errata Sheet Functional Dev
Page 25: ; the remaining part of the interru
Page 29 and 30: Workaround Errata Sheet Functional
Page 47 and 48: Workaround Errata Sheet Functional
Page 49 and 50: directly followed by reading from
Page 57 and 58: PLL_TC.P005 PLL Parameters for f VC
Page 59 and 60: Errata Sheet Application Hints This
Page 61 and 62: Errata Sheet Application Hints FIRM
Page 63 and 64: Errata Sheet Application Hints The
Page 65 and 66: Errata Sheet Application Hints Mult
Page 67 and 68: Errata Sheet Application Hints The
Page 69 and 70: PCP_TC.H007 Do not use priority 0 t
Page 71 and 72: Errata Sheet Application Hints tran
Page 73: Errata Sheet Application Hints TC17

Errata Sheet - Infineon

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?