TMS570LC4357 Bank 7 Linker Generated ECC

Hi Stu,

I can recreate the ECC calculation done by auto-ecc but in the process had to 're-learn' the fact that the flash array on this particular part is natively be-8 or le (not sure which exactly).

Anyway the calculation has some byte-swapping in it that is different than the calculation on the TCM parts and is not readily apparent from the TRM.

This C program does the calculation and gives the 2nd result:

// Win32Project1.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

unsigned int eccdat[] = { 0x1FC0007F, 0x00FFFF00, 0xFF0000FF,
					      0x003FFF80, 0xFF0000FF, 0xFF0000FF,
					      0x1FC07F80, 0xFF00FF00, 0xFF00FF00,
					      0x0FC19F83, 0xC0FCC0FC, 0xC0FCC0FC,
					      0x13C6A78D, 0x38E338E3, 0x38E338E3,
					      0x14DAA9B5, 0xA699A699, 0xA699A699,
					      0x1D68BAD1, 0x15571557, 0x15571557,
					      0x0A7554EA, 0xB4D1B4D1, 0x4B2E4B2E };

unsigned int byteswap(unsigned int val) {
	unsigned int retval;
	retval = ((val & 0x000000FF) << 24);
	retval = retval | ((val & 0x0000FF00) << 8);
	retval = retval | ((val & 0x00FF0000) >> 8);
	retval = retval | ((val & 0xFF000000) >> 24);
	return retval;
}

int main()
{

	int i, j, k;

	unsigned int w1, w2, w3, w4, w5, r;

	unsigned int a1[] = { 0xF0200000, 0xF0200008, 0xF0200010, 0xF0200018 };
	unsigned int d1[] = { 0x536F6D65, 0x66662074, 0x6F726520, 0x56000000 };
	unsigned int d2[] = { 0x20537475, 0x6F205374, 0x696E204E, 0x00000000 };

	unsigned int am = 0xfffffff8;


	for (k = 0; k < 4; k++)
	{
		r = 0;

		for (i = 0; i < 8; i++) {
			w1 = (eccdat[3 * i + 0]);
			w2 = (eccdat[3 * i + 1]);
			w3 = (eccdat[3 * i + 2]);

			w1 = w1 << 3;
			w1 = w1 & a1[k] & am;

			w2 = w2 & byteswap(d2[k]);
			w3 = w3 & byteswap(d1[k]);

			w4 = 0;
			w5 = 0x80000000;

			for (j = 0; j < 32; j++)
			{
				if ((w5 & w1) != 0)
				{
					w4 = w4 ^ 0x01;
				}
				if ((w5 & w2) != 0)
				{
					w4 = w4 ^ 0x01;
				}
				if ((w5 & w3) != 0)
				{
					w4 = w4 ^ 0x01;
				}
				w5 = w5 >> 1;
			}

			r = (r << 1) + w4;

		}

		r = r ^ 0x0c;

		printf("res = 0x%x\n", r);

	}
    return 0;
}

Yields

I need to look now into what's going on in the compiler/linker.  It may be a setting that needs to be different or may be an issue we need to file a bug report on.  Not sure yet.

Best Regards,
Anthony

I also rebuilt your project and can get the same result when using linker ECC.

Only doubt I haven now is whether the problem is in the file or in the loader. I haven't been able to use the objdump or armdis utility to dump the contents of the .out file and actually show the data section at 0xF0200000 or the .ecc3 at 0xF0100000 yet. not sure why.

Ok that was my mistake - there was a file "rtiBlinky.out" in the folder and I kept hitting it w. command completion instead of 'rtiBlinkyNV.out'.

When I disassemble NV.out,  I can see that the ecc values are wrong in the disassembly of the .out file.

So it's an issue now either with the linker or the linker command file ..  I'll have to check that there isn't some missing switch or option needed.

But, I have tried the C program above implementing the TRM algorithm and none of the combinations of 'mistakes' in endian are coming up w. the values below so I am thinking some other issue may be at play.

Ok actually I can reproduce the linker results if I take my program and change the address mask
from:
unsigned int am = 0xfffffff8;
to:
unsigned int am = 0x00fffff8;

So I am fairly certain this is a bug in the linker now. This LC4357 takes more address lines into account than the previous generation for better protection - and probably the linker didn't comprehend all of the upper bits.... Many times bank 7 is left erased for FEE use - so it makes some sense for this issue to have escaped for so long.

EDIT:  Filed a bug report on the linker:  SDSCM00052814

I would be confident in the ECC computed on the lower banks.   Just the addresses with non-zero upper 8 or 16 bits of address are likely an issue.

Thanks Anthony, glad you can replicate the issue and validate it in your calculation.

As this appears to be a bug in the linker I bet I can't define a separate ECC algorithm in the linker script with a different mask for the Bank 7 ECC as a work around until the linker is fixed can I?

Hi Anthony,

How can I track the progress of bug SDSCM00052814? If I search for it on the compiler defect databases is can't be found.
Do you have an general idea of time it normally takes for a Linker bug to be fixed and released?

Thanks,
Stu

Hi Stu,

It's not yet been accepted by the compiler team. They have to accept it and turn on a flag to make it visible.
It should show up in a matter of time.

I don't know how long it will take to get this fixed. At this point - I would probably suggest opening a thread on the Compiler forum asking for the disposition and timing of a resolution to SDSCM00052814.

Thanks and Best Regards,
Anthony