• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 2693 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Read/Write DK-TM4C129x SPI-EEPROM

Klaus Breining64693
Intellectual 540 points

Hi,

first to note: I  have read the post of Spandan89 in this forum about maybe the same issue. Somehow it seems he has solved his issue, but how was not mentioned. I was using the sample code mentioned there (1145.TM4C129_SSI3_MacronixFlash.7z). But on my board, I always read back 0xFF at every location.

Next I tried the sample application usb_dev_msc, but I get exactly the same effect. If I look at the datasheet of the Macronix flash, Pin 3 serves as the hardware write protect (WP#) and Pin 7 as a reset pin. But in all sample programs, these pins are left floating. I have changed the code in both samples to set the pins to High level - but the effect is the same.

Using an oscilloscope, the wave forms at the CS, SIO0, SIO1 and SCLK pins look reasonable. Reading and writing the status register as well as the config register seems to work - at least I can read back what I was writing there.

I am using Code Composer Studio 6.0.1 with the latest updates of the TI ARM compiler. Is there anything else that could be wrong?

  • 0
    TI__Guru**** 244400 points
    Hello Klaus,

    Has the CS jumper been moved to the SPI Flash instead of the uSD Card?

    Regards
    Amit
  • 0
    Prodigy 120 points
    Hi Klaus,

    What is the Macronix part number of the serial flash you are using (MX66L51235F)?

    The Reset signal has an internal pull-up, so it can be left floating if not needed.

    The WP# pin is "don't" care if SRWD (Status Register Write Diable bit-7) is set to '0' (default is '0' after
    power-up). Since you are able to write to the Status Register, SRWD must already be set to '0'.

    The BPx (BP3, BP2, BP1, BP0) bits in the Status Register must be set to '0' to enable writing to all areas of memory. If any
    of the BPx bits are set to '1', portions of memory will be write protected and only Reads will be allowed.

    If you are using the MX66L51235F and you have set WPSEL (Security Register bit-7) to '1', the BPx bits
    become "don't care" and all memory blocks/sectors are write protected automatically after power-up. You
    can unprotect all blocks/sectors by using the GBULK (Gang Block Unlock) instruction (0x98) after power-up.

    Please note that the WPSEL bit is OTP. Once you have set it to '1' (either intentionally or accidentally), there
    is no way to return it to '0'.

    Have you actually tried programming the memory? Remember that the unprogrammed (erased) state
    of memory is '0xFF'.

    Best regards,

    -Rick
  • 0 in reply to Amit Ashara
    Intellectual 540 points
    If I look into the schematics (spmu360.pdf) there is no jumper. The SPI-flash has its chip-select at PQ1 (SSI3FSS), the µSD-card at PH4.
  • 0 in reply to Rick Culver
    Intellectual 540 points
    Hi, thanks.
    If I measure at pin 7 of the flash memory (MX66L51235F), there is huge noise on this pin and the voltage is near 0V - so I can't see any internal pull-up. Is it somewhere mentioned in the datasheet? I did not find any hint.

    About the priority of SRWD and WP# I have to read again the datasheet, for me WP# had the higher precedence. Maybe I am wrong. In this case, this pin might really float.
    The BPx-bit I always set to '0' before I try to write. A read-back shows, that the bits are reset.
    I have to check, if WPSEL is set. I have never set this bit, but maybe an erroneous software could cause it?
    Maybe just executing GBULK could help - if WPSEL is set, it should unlock. In the other case, it should not harm, I hope.

    Regards
    Klaus
  • 0 in reply to Klaus Breining64693
    TI__Guru**** 244400 points
    Hello Klaus,

    One of the first checks in the code is for the device ID. Do you see the print on a console (either error device id or correct device id)?

    //
    // First Read the DEVICE ID
    //
    ui32DeviceID = SSILibSendReadIDAdvMode(SSI3_BASE);
    if(ui32DeviceID != 0xC219)
    {
    UARTprintf("No External Flash... Read Back %x\n",ui32DeviceID);
    while(1);
    }

    UARTprintf("External Flash Detected with Device ID %x\n",ui32DeviceID);

    As for the jumper, it has to be physically moved from PH4 to PQ1 for any Flash access which is the SSI3FSS pin function

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 540 points

    Hi Amit,

    indeed, I can see the printout for the id C219. Also, on my board all jumpers of J7 are equipped. As there is no SD-card inserted, this should not be a problem.

    The CS should not be the problem as I can read and write to the status register. I will try to follow the hint of Rick about the WPSEL bit. Maybe my flash is killed for some reason. I have tried two different possibilities to access. Your library is using SPI advanced mode, handling FSS by the SSI hardware. Utils/SSIFlash is using legacy SPI mode handling the CS-pin with normal GPIO commands. As both methods react in the same way (and I am using software that obviously has worked already somewhere) something with my flash seems to be not ok. Just to be sure, I have also ordered a new board...

    Regards

    Klaus

  • 0 in reply to Klaus Breining64693
    TI__Guru**** 244400 points
    Hello Klaus,

    Why a new board? Just replace the Flash memory or do a small PCB with the same Flash for future replacements!!!

    So the connection between the devices is fine. The status register must have the WPSEL status, so a read of the same should show.

    Regards
    Amit
  • 0 in reply to Klaus Breining64693
    Prodigy 120 points
    Hi Klaus,

    The pull-up on RESET# is mentioned on page 7 of the current MX25L51235F datasheet, but it is just a footnote under the Pin
    Description table.

    The WP# function works in conjunction with the SRWD bit. If SRWD = 0, the WP# state is don't care. If SRWD = 1 and
    WP# = 0, the WRSR instruction is disabled thus protecting the SRWD and BP bits from further modifications.
    If SRWD = 1 and WP# = 1, the WRSR instruction is still enabled. Please see Table 7 Protection Modes on page 38 of the datasheet.
    In all cases, the areas of memory specified by BP bits being set to '1' will be protected.

    If the WPSEL bit is not set, the GBULK instruction will be ignored and cause no harm.

    Best regards,

    -Rick
  • 0 in reply to Rick Culver
    Intellectual 540 points

    Hi,

    just received a new flash memory, replaced the old one - everything is fine. Checking the old device, WPSEL was not set. All registers seemed to work normal but writing was not possible. I guess, this part was just dead for some reasons.

    At least now everything works, so thanks a lot for all your help.


    Regards

    Klaus