DK-LM3S9B96-FS8 expansion board problem

Stefan -

It sounds like the EEPROM on the FS8 daughter board became corrupted, so the set_pinout.c code can not determine what daughter-board is attached and therefore stalls the processor.  Does this match your understanding of the situation?

If this is the case,all of the FS8 dependent examples should receive DAUGHTER_UNKNOWN from the  DaughterBoardTypeGet function and hang.  All of the SDRAM dependent examples should work fine. 

You can build the project with "SIMPLE_PINOUT_SET" defined in the makefile or project.  This will force it to believe that a FS8 is attached.

 - Eric

Your answer match my problem!

The function DaughterBoardTypeGet  returns DAUGHTER_UNKNOWN.
I'll try to build the project with "SIMPLE_PINOUT_SET".

Thanks!

Building the project with "SIMPLE_PINOUT_SET" doesn't work.
When all the LCD examples are tested, the LCD doesn't show anyting, just a solid white color when FS8 is attached to the EPI.
Is the FS8 board correctly initialized when using the "SIMPLE_PINOUT_SET" definition?
Can i recieve the data parameters (stored in I2C EEPROM) to set the struct manually?

All SDRAM examples work fine!

If you build the examples with SIMPLE_PINOUT_SET defined and you are using a release of StellarisWare from the last 2 months, this should configure the EPI correctly for the FS8 daughter board and all the examples should run with that daughter board attached. The binaries you generated will not work with the SDRAM daughter board, however, since SIMPLE_PINOUT_SET hardcodes the EPI configuration for the FS8 board. If your FS8 board doesn't have the correct configuration information in the EEPROM, you will also find that you can't run the binaries from the StellarisWare distribution since they will think they are running on a system equipped with the SDRAM daughter (or no daughter since the SDRAM board doesn't have the required EEPROM to allow detection).

If you are finding that the examples you are building with SIMPLE_PINOUT_SET are not working with the FS8 board, that's a bit more worrying. Use your debugger to step over PinoutSet() at the beginning of each example then examine global variable g_eDaughterType. If the apps were built correctly, it should be set to DAUGHTER_SRAM_FLASH. If it's set to something else, that tends to suggest a problem in the build (typo in the SIMPLE_PINOUT_SET define, define missing, etc.). If this variable is set correctly and you are using the latest version of StellarisWare (release 5961as far as I can remember), this may indicate that your FS8 daughter board has a hardware problem of some sort.

I forgot to provide the EEPROM parameters in my last post - sorry. Here are the structures that are used to identify the two daughter cards that are currently available. Labels used in these definitions can be found in the driverlib/epi.h and boards/dk-lm3s9b96/drivers/set_pinout.h header files. The strings defined by g_pcIDNames are appended to the end of each structure when it is written to the EEPROM. I'll try to put together a little application that writes these and either include it in the next StellarisWare release or, more likely, post it to the forum.

//*****************************************************************************
//
// Daughter board ID information blocks to be written to EEPROM.
//
//*****************************************************************************
const tDaughterIDInfo g_psIDBlock[2] =
{
    {
        //
        // SRAM/Flash daughter board.
        //
        {'I', 'D'}, 0, 0, DAUGHTER_SRAM_FLASH, 1, EPI_MODE_HB8, 0xFFFFFFFF,
        20, 20, 90, 90, 0, 0, (EPI_ADDR_RAM_SIZE_256MB | EPI_ADDR_RAM_BASE_6), 0,
        0, 0, 0, 0, (EPI_HB8_MODE_ADMUX | EPI_HB8_WORD_ACCESS), {0}
    },
    {
         //
         // FPGA daughter board.
         //
         {'I', 'D'}, 0, 0, DAUGHTER_FPGA, 1, EPI_MODE_GENERAL, 0xBBFFFFFF,
         25, 25, 0, 0, 0, 0, (EPI_ADDR_PER_SIZE_64KB | EPI_ADDR_PER_BASE_A),
         0, 0, 0, 0, 0, (EPI_GPMODE_DSIZE_16 | EPI_GPMODE_ASIZE_12 |
         EPI_GPMODE_WORD_ACCESS | EPI_GPMODE_READWRITE | EPI_GPMODE_READ2CYCLE |
         EPI_GPMODE_CLKPIN | EPI_GPMODE_RDYEN), {0}
    }
};

const char *g_pcIDNames[2] =
{
    "Flash/SRAM/LCD",
    "FPGA/Camera"
};

Here's the promised tool that will allow you to rewrite the contents of your daughter board ID EEPROM. This is a binary I built locally so beware - it's not been through the same testing as it would had it gone through a proper release cycle. That said, it runs fine on my board so will likely work fine for you too. The source for this will be available in the next StellarisWare release for the dk-lm3s9b96.

Flash the unzipped binary file to address 0 on your dk-lm3s9b96 and reboot. You will find a command line interface on UART0 - follow the instructions to read or write the required ID information to your board.

THANKS!

The problem still exists, but I'm now sure that my FS8 daughter board has a some kind of hardware problem.

Stefan,

There is one other thing to check before assuming that the problem is on the daughter board. If you can step through the function PinoutSet() at the top of any example app, check to see which daughter board type it detects (look at global variable g_eDaughterType). If it is DAUGHTER_NONE (indicating that it could not read the EEPROM), run again and see where the function EEPROMRead exits. If you find that you fall into the I2C_MASTER_ERR_ARB_LOST case after the call to I2CMasterErr(), you may be seeing a problem related to one of the lm3s9b96 chip errata. A problem in some chips can cause spurious edge detection on some GPIOs and, for I2C, this can cause incorrect loss of arbitration on some transactions. I've seen this on a small number of boards and the typical result is a white LCD (since the software assumes there is no daughter card present and tries to drive the screen via GPIO bit-banging rather than through the EPI).

No I2C error exists on my board...

Now i'm testing a new daugther board and the problem still exists.
What shall i do, please help me to solve this problem!

Just to clarify, you ran the dbeeprom tool and it can read and write the EEPROM on the daughter board correctly (so we know that the EEPROM and I2C interface is working correctly)? If that is the case, have you also verified that PinoutSet() reads the correct daughter board ID (g_eDaughterType should end up set to DAUGHTER_SRAM_FLASH)? If both of these are fine and you don't have the PD0 and PD4 jumpers installed between the audio jacks at the top of the board, then it does sound to me as if there may be a hardware problem somewhere on your board. As one final check, you could try running some of the binaries from the StellarisWare release (if you've not done this already) rather than ones you have rebuilt locally. You should also try running some of these with the FS8 daughter board removed and the LCD jumpers replaced to see if they run correctly in that configuration. These are probably obvious but I don't see them mentioned in the thread above so...

Started first time with your bin file:
Current daughter board: None or SDRAM

Reprogrammed and restarded status:
Current daughter board: SRAM/Flash/LCD

Shall check if it work now...

grlib_demo Still not working, my source or your bin.
g_eDaughterType is now correct = SRAM/Flash/LCD board, before None!
PD0/PD4 jumpers are not connected...

Get the board type with I2C seems to work now after reprogramming the EEPROM.

This is helpful. So the last question is whether or not our binary runs on your board with the FS8 removed and the correct jumpers reinstalled. If it does, that tends to suggest an FS8 problem. If it doesn't, you may have a bad display or some other problem on the DK board itself.

Your binary (Same as before) now runs with the SDRAM board and all jumpers reinstalled!
2 different FS8 boards are tested ordered from Mouser and Farnell in Sweden.
Maybe they are from the same production batch.