programming POST into I2C EEPROM [6678]

Hi Jeff,

I am not sure why it appears a byte swap is occurring, the README is correct in stating that it should be left disabled. Could you try enabling it when writing to EEPROM to see if that fixes the issue?

For your second question, are you referring to the .bin files located in program_evm? If so than it is eeprom50.bin. You can also get the post binary from [MCSDK_SRC_DIR]/tools/post/evmc6678l/bin/post_i2crom.bin.

Also if you could let me know where the conflicting information is located so I can look into clarifying it for future users, that would be great.

Casey-

Thanks for your reply.

Casey Smith said:

I am not sure why it appears a byte swap is occurring, the README is correct in stating that it should be left disabled. Could you try enabling it when writing to EEPROM to see if that fixes the issue?

We did and now on the digital scope we see the same I2C EEPROM output byte stream as with the EVM.  But we don't see UART output from POST on the scope yet.  Is there another way we can confirm that POST is attempting to run?  Are there some progress locations in memory that we can check?  Any chip output signals?

Casey Smith said:

For your second question, are you referring to the .bin files located in program_evm? If so than it is eeprom50.bin. You can also get the post binary from [MCSDK_SRC_DIR]/tools/post/evmc6678l/bin/post_i2crom.bin.

Ok.  Is there any difference between eeprom50.bin and post_i2crom.bin?

Casey Smith said:

Also if you could let me know where the conflicting information is located so I can look into clarifying it for future users, that would be great.

 I had previously found one Wiki page that mentioned POST as being included in the 0x51 binary, but I can't find it again.  And, all my searching is consistently showing 0x50 + POST.  So please ignore my initial comment on that.

 -Jeff

Hi Jeff,

Is the application image loaded on the C6657 board correctly. YOu can connect to the device after powering on and check the program counter. Also look at the location where the POST example is loaded in L2 memory to confirm the ROM loaded the binary accurately. In debug view you can load the symbols of the POST example using Run Tab by selecting the following options Run->Load  Program-> Load symbols only and browsing to the post .out file. If the core is executing the post example, it should show you where it is executing code at.

UART baudrate is configured based of the PLL settings to obtain the 15200 bps baudrate so if you have different PLL settings then it is likely you will need to modify the UART dividers to obtain 115200 bps using your main PLL settings. This is done using the platform.lib for the EVM  provided in the PDK package. If you are doing this on C6678 platform, you can use the System debug GEL file provided on the wiki here to see the PLL settings.

http://processors.wiki.ti.com/index.php/Keystone_Device_Architecture (Look under debug sub section)

Hope this helps

Regards,

Rahul

Rahul-

Thanks.  The program counter was at 0x20b0c952, which  I assume is still in RBL code and means POST was not loaded from I2C EEPROM correctly and/or is not running correctly.   Then we loaded and ran post_i2crom.out manually, after initializing our board using Gel scripts.  Now we can see UART-to-USB output from our board.  But the POST I2C read test fails -- and more disturbing -- POST stops at that point and does not try to run Flash memory tests or Ethernet loopback test.

1) What is POST testing  for I2C read?  Which bus address?  How does it determine failure?

2) We found post_i2crom.bin, as you mentioned.  This is both smaller (48 Kbyte vs. 64 Kbyte) and newer (Nov 2012 vs. June 2011) than eeprom50.bin for our Rev 1.0 EVM 6678 board.  Can we use post_i2crom.bin with a Rev 1.0 EVM?

Thanks.

-Jeff

Rahul, Casey-

A follow-up to my comments / questions above.  We have I2C EEPROM boot and POST working now.  We can see POST results on 6678 UART output, using our UART-to-USB bridge (this part of our board design follows the EVM 6678 board very closely).  Also, we used post_i2crom.bin, not eeprom50.bin.  Although I'm not sure if this is the correct choice for Rev 1.0 silicon boards, it seems to work.  We keep byte swap disabled when loading post_i2crom.bin into memory.

New question:  POST fails on NOR Flash test... this is not unexpected, as we have not debugged this part of our board yet.  But, POST completely stops after this failure.  I looked at post.c and it looks like POST should continue to the next test.  Can you comment?  Can a NOR test failure hang the whole chip?  Should POST be advancing to the next test?

Thanks.

-Jeff

Jeff,

After examining POST source code it seems this is expected behavior. After the test is executed, the result of the test is passed to the post_display_status function (post.c, line 1125):

test_result = post_test_nor();
if (test_result == POST_TEST_RESULT_FAILED)
{
    acc_fail++;
}
post_display_status(POST_TEST_NOR, test_result);

If test_result is POST_TEST_RESULT_FAILED post_display_status calls post_display_led_error(), which never returns (post.c, line 199):

else if (test_result == POST_TEST_RESULT_FAILED)
{
    msg = strcat(msg, msg3);
    if (post_write_uart(msg) != TRUE)
    {
        post_display_led_error(POST_TEST_UART);   /* Never return from this function */
    }
    post_display_led_error(test_id);  /* Never return from this function */
}

post_display_led_error() blinks some LEDs on the board in an infinite loop.

Hope this helps.

Casey-

We have modified POST to change the "one error and done" behavior, so now we can see results of all tests.

We're now trying to turn on additional debug information in POST, in order to see more debug info about the peripherals that fail (NOR and NAND Flash).  This requires PLATFORM_DEBUG to be set to 1 in platform_internal.h, which in turn requires ti.platform.evmc6678l.lite.lib to be rebuilt (according to the makefile in the POST project).  I located the platform_lib_evmc6678l project, but rebuilding does not change the .lite.lib file.

Is there a separate project for the Lite version of  platform_lib?  Or, is there something in the project that can be changed to indicate the Lite version?

Thanks.

-Jeff

Casey-

Update -- we solved this by changing the Active Configuration in the library project to "Lite".

Now we can see additional POST debug info, which indicates the SPI NOR Flash test is failing because the device ID code comes back zero:

  SF: Got idcode 00 00 00

For our device (which is 2x the capacity as the one on the EVM 6678), we're expecting device ID 20 BB 19.  I'm not sure whether to suspect a hardware or software problem. Which file in POST makes the initial NOR Flash ID read?

Thanks.

-Jeff