我參考幫助文檔Isolate the iLLDs from an AURIX™ Project into a Library Project，我在MULTICAN_FD_1_KIT_TC275_LK編譯不會LINK到static library，如下圖產生編譯錯誤。請問這個要如何解決?另外其他的example的程式添加進來之後要再拿裡設定?在幫助文檔好像沒有對static library後續更新。

Dear Aurix Users,

I have some questions about Pflash ECC mechanism is Aurix TC23x device.

First question is that in what situation will cause the Pflash ECC error. Dose the Pflash is effected by Electromagnetic Disturbance?

The second question is about the ECC correction mechanism

The user manual says that the ECC will be automatically evaluated when reading data.

Dose it mean ECC will be automatically evaluated when the data is read from Pflash to DMI(Data ram)?

I think the ECC may not correct the error in program flash, so there is still exist bit flip error in Pflash, but the ECC mechanism can ensure us to obtain the corrected answer when it is read from flash to RAM.

Thanks,

Let's be honest: The I2C Interface of the TC3xy-family is an overcomplicated mess. Most semiconductor manufacturers would implement a simple shift register and then add FIFOs, burst requests and DMA but Infineon did it the other way round and then nailed the that overcomplicated byte-, half-word- or word-aligned FIFO cludge onto something that could be mistaken for an I2C bus logic.

The manual is basically useless, excessively describes state changes, i2c assymmetric timing alignment but fails to describe the registers sufficiently, is mostly obscure, uses multiple terms for (basically) the same thing without explaining them properly (bytes, characters, packets, bursts - so what DOES an i2c interface transmit then?) but fails to explain one, ONE single simple use case such as "receive 2 bytes from an i2c slave".

The sample code Infineon publishes on GitHub is exactly that: A good example of what code should _not_ look like in the year 2021 when it claims to have been written and i'm not even sure whether it actually works out of Infineon's sample code scope.

I basically got it to work and manage to transmit a given number of bytes to an i2c slave (a real-time clock), but fail to receive a specified number of bytes. It always reads the amount of bytes that fit into the FIFO. The "BREQ" interrupt flag cannot be reset, the "RX"-interrupt flag is never set despite the fact that it is apparently receiving data from the slave and storing it into the FIFO. The hardware doesn't care what i write into the MRPS register and RPS is stuck at "8".  Since my code apparently cannot synchronize to what's going on on the i2c bus, i fail to set "SETEND" at the correct occassion (and the Infineon sample code doesn't set it where the manual specifies it to be set either). I can also not debug properly because the I2C hardware refuses to be controlled and when using SPEN, it goes into "disabled" state while debugging (DISS is "set" then) rendering my debugger's interface completely useless.

I am thinking about reverting to a bit-banging driver i wrote for a C166 derivative almost 20 years ago. But before i do, please help me and explain to me:

How can i manage to receive a given number of bytes (like "1")?
What do i need to do to reset the BREQ interrupt flag?
What is MRPS actually for?
What exactly _IS_ a burst request and how do i service it in software properly?

My software is simply meant to read out time/date during initialisation, long before any sort of interrupt/DMA configuration is set up. Because it only reads a couple of bytes, the runtime is not really an issue, but i simply cannot get it to work.

Many thanks in advance for any support and many greetings,

Oliver