This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EEPROM

Other Parts Discussed in Thread: HALCOGEN, RM48L952

Processor: RM48L952ZWT

1. When specifying a block number, are block numbers zero (0) or one (1) based?

2. In the Halcogen example_TI_Fee_Write_Read.c, the example at the end after writing and reading a block, calls

TI_Fee_InvalidateBlock(BlockNumber);

and then

TI_Fee_Format(0xA5A5A5A5U);

to format bank 7.

a) Does InvalidateBlock() function the same way as erasing a flash, namely set all bits to one (1) and then the write function sets appropriate bits to a zero?

b) I understand the concept of formatting, such as formatting a disk to whatever format (NTFS, XFS, etc) before use, but why is that function at the end?

c) How do banks differ from blocks?

d) Why does TI_Fee_Format format bank 7, as opposed to bank 5 or 50 or 3 or whatever?

e) How many banks are there? Are there so many banks per block or blocks per bank?

3) I am trying to test EEPROM in my code (not the example, but my code) using my board, not the HDK. I do call TI_Fee_Init() prior to initiating the tests. I do a write operation and then do a read operation. The problem is that I get 0x00000000 back for the first cell in block zero, when I am expecting 0xFFFFFFFF, as that is what I wrote.

boolean doEepromTestWrite()
{
	uint32 uSize = 32;
	uint32 *lpdwBlock = (uint32 *)malloc(uSize);
	if ((uint32 *)NULL == lpdwBlock)
		return FALSE;

	uint32 uData = 0xFFFFFFFF;
	uint32 uIndex = 0;
	uint32 uWords = uSize / 4;
	uint32 *lpuIndex = lpdwBlock;
	for (uIndex = 0; uIndex < uWords; uIndex++)
	{
		*lpuIndex = uData;
		uData--;
		lpuIndex++;
	}

	TI_Fee_WriteSync(uBlock, (uint8*)lpdwBlock);

	free(lpdwBlock);

	return TRUE;
}

boolean doEepromTestRead()
{
	uint32 uSize = 32;
	uint8 uBlock = 1;

	uint32 *lpdwBlock = (uint32 *)malloc(uSize);
	if ((uint32 *)NULL == lpdwBlock)
		return FALSE;

	TI_Fee_Read(uBlock, 0, (uint8*)lpdwBlock, uSize);
	uint16 Status;
	do
	{
		TI_Fee_MainFunction();
		delay();
		Status = TI_Fee_GetStatus(0);
	} while (IDLE != Status);

	uint32 uData = 0xFFFFFFFF;
	uint32 uIndex = 0;
	uint32 uWords = uSize / 4;
	uint32 *lpuIndex = lpdwBlock;
	for (uIndex = 0; uIndex < uWords; uIndex++)
	{
		if (uData != *lpuIndex)
			return FALSE;
		uData--;
		lpuIndex++;
	}

	free(lpdwBlock);

	return TRUE;
}

Here is the test code that I created, less the display statements. I originally started with uBlock = 0, but then saw the example use one (1), so I set uBlock = 1 instead. Still, I read zeros back. I also did not incorporate the TI_Fee_InvalidateBlock() and TI_Fee_Format() calls, as I am not sure when to use them and what specifically they do

af

  • HI Sarah,

      Let me take a stab at your questions. I'm not an TI FEE expert. I have also forwarded your question to our FEE expert so he can supplement additional information.

     

    Sarah Weinberger said:
    1. When specifying a block number, are block numbers zero (0) or one (1) based?

    The BlockNumber starts with 1. According to the FEE user guide the BlockNumber default value is 1 and has a range from 0x1 to 0xFFFE

    Sarah Weinberger said:
    a) Does InvalidateBlock() function the same way as erasing a flash, namely set all bits to one (1) and then the write function sets appropriate bits to a zero?

    No, the invalidate merely marks the block as invalidate and not to be used again. The TI_FEE algorithm will know that it can not use an invalidated block again 

    Sarah Weinberger said:
    b) I understand the concept of formatting, such as formatting a disk to whatever format (NTFS, XFS, etc) before use, but why is that function at the end?

    The TI_Fee_Format() is used to erase the virtual sectors

    Sarah Weinberger said:
    c) How do banks differ from blocks?

     A bank is a physical bank. In RM48 device there are a total of three physical banks. There is bank0 (1.5MB), bank1 (1.5MB) and bank7 (64kB). You can visually see the physical bank boundary with a magnifier if you open up the silicon. A block in the context of FEE is a just a space inused to stored your user variables. 

    Sarah Weinberger said:
    d) Why does TI_Fee_Format format bank 7, as opposed to bank 5 or 50 or 3 or whatever?

    As explained in the prior answer the bank that is dedicated for FEE Emulation is denoted as bank7. The bank0-6 are used for normal banks (non-FEE purpose). Bank0 and 1 are physically implemented. Bank2,3,4,5,6 are simply reserved. 

    Sarah Weinberger said:
    e) How many banks are there? Are there so many banks per block or blocks per bank?

    Again there are only three physical flash banks. In the context of FEE there is only one bank that is dedicated for FEE emulation which is bank7. You can have multiple virtual sectors in the bank7. Each virtual sector can contains multiple blocks.

    Sarah Weinberger said:
    3) I am trying to test EEPROM in my code (not the example, but my code) using my board, not the HDK. I do call TI_Fee_Init() prior to initiating the tests. I do a write operation and then do a read operation. The problem is that I get 0x00000000 back for the first cell in block zero, when I am expecting 0xFFFFFFFF, as that is what I wrote.

    At the beginning of a virtual sector is some header information. The header may indicate if a virtual sector is ready for erase or if the virtual sector is current active, invalid or in the state of being copied or empty. You are reading the first cell which is head information. What I will suggest you do is to program something that will stand out like 0x12345678. As you view the memory browser it will be easier to spot the value. I will also highly recommend you to read the TI FEE userguide. It is not a big document. You just need to read the first few pages and you can answer many of your questions. 

  • 1. There was no link to the TI FEE user guide. The RM48L952ZWT page does not list TI Fee in the user guide section.

    ti.com/product/RM48L952/technicaldocuments#doctype6

    2. Great idea to use the memory viewer!

    I noticed that my actual data is offset by 4-bytes. Why is that?

    Write Memory Viewer:

    Read Memory Viewer:

    Do all blocks start off with a 4-byte internally used array that is zero filled? What does TI use these 4-bytes for? Are these values anything other than zero?

  • Sarah,

    Normally the TI FEE userguide is located in the the HalCoGen installation directory at C:\ti\Hercules\HALCoGen\v04.xx.xx\Docs\TI FEE User Guide.pdf. I'm attaching here.

    6283.TI FEE User Guide.pdf

    Secondly your memory browser window is showing address range from 0x80000330. This is a SDRAM address. The bank7 address starts at 0xF0200000.

  • Hi Charles,

    Thank you for the TI FEE user guide.

    Yes, because I called TI_Fee_Write to write the block of memory at lpdwBlock(s) and then I called TI_Fee_Read() to read back the block. The TI function returned the block with the extra zero padding. Is that some sort of padding? What is that?

    Basically, in the returned block of memory from TI_Fee_Read() can I always assume that the actual data starts 4 bytes in?
  • Hi Sarah,
    No it is not supposed to pad zeros but I don't know why at the moment. Looks like only the first word becomes zero but the rest is fine. I will need to let the TI_FEE expert help answer the question.
  • Hi Charles,

    I was wrong, as I did not look at the memory window carefully.

    There is no padding, just the first 4-bytes gets zeroed out. Notice that the second uint32 word is 0xFFFFFFFE. Had there been padding, the second uint32 would have been 0xFFFFFFFF. The first uint32 is supposed to be 0xFFFFFFFF but returned 0x00000000. All other values seem fine.

    Ask the FEE expert and let me know.

    Regards as well,

    Sarah
    P.S. thanks for helping out Charles.
  • Hi Sarah,
    While waiting for the expert to look into it, in the meantime can you change the first word to program to non-0xFFFFFFFF. Just want to know that any first value will turn into a zero or only if the first data is a 0xFFFFFFFF.
  • Hey Charles,

    That was an awesome idea to try something other than 0xFFFFFFFF and see if the problem persists. I should have thought of that. :-(

    Here is your answer: NO difference. I tried 0xFFEEFFEE as the starting value.

    Write:

    Read:

    Regards,

    Sarah

  • Hi Sarah,

      OK, this will be a good data point for our expert to look at. 

  • Hi Sarah,

    Can you send a screen shot of the memory browser for address starting at 0xF0200000? Also can you send ti_fee_cfg.c and ti_fee_cfg.h file?