Regarding FC3379 ECC, byte trimming and bit cutting.

NFT

The latest PC3K has been upgraded to version 9.3.
Some NFT users reported that after cutting bytes and bits, all ECC corrections show as passed, yet none of the final produced files are valid.

I accidentally discovered that for PC3K’s FC3379 1160+1144x15, the ECC function fails to fix 68-bit errors completely—it misses 4 bits of correction.
When a single segment contains errors of 64 bits or more, the remaining 4-bit errors will be omitted and left uncorrected.

This screenshot shows that after cutting a large number of bits and then performing ECC correction, more serious errors occur.
However, the ECC status displayed in the map shows all corrections as successful.

Switching to NFT, you can clearly see this issue.

When viewing the HEX data and switching the ECC status, obvious uncorrected errors can be seen.


View the bitmap.
Before NFT correction:

After NFT correction:


FC3379 byte and bit cutting

For certain unobservable error bytes and bits, tick Decrypted ECC to assist with error analysis and judgment.

Increase the bitmap display scale to accurately locate the bit positions that need to be cut.

For example, in the following cases:

You can see that at position 6879, one bad byte is caused by cut bits and needs to be trimmed.
After trimming:

You can see that even after correctly trimming 1 byte, the subsequent data was not XORed correctly.
Additionally, it is strictly aligned with the end of Plane 0.
Nevertheless, the ECC for the current segment shows as verified and passed, which indicates there is one byte of unreported error at the ECC boundary.

After trimming, the subsequent data can be seen to have correct XOR results.
This type of issue used to be very troublesome when dealing with bit errors, but with the assistance of these functions, it is no longer a problem.