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.

MSP-EXP432E401Y: 3-wire SPI weirdness - Ti Drivers - Timing Issue?

Part Number: MSP-EXP432E401Y
Other Parts Discussed in Thread: MSP432E401Y

Stefan - First, wish to thank you for your earlier help on these SPI questions...

Am changing things up: Have now experimenting with 3-wire implementation - with the MSP432E401Y chatting with a 25LC1024. Code is based as closely as possible on the spimaster example, from simplelink_msp432e4_sdk_4_20_00_12 - with all the master-slave handshaking bits removed.

Port D lines are per defaults, with key pins now set up as discrete GPIO lines: (The syscfg tool has been very helpful here; thanks for this!)

EEPROM_CS    - PD2
EEPROM_HOLD  - PD5
EEPROM_WP    - PD4

Tweaking various parameters, the first 2-3 bytes (of my all-important message "DON'T MESS WITH TEXAS") are always wrong. Assuming I have a timing issue, I've been trying to move around the CS and HOLD signals. Please note: the CS in trace below is at about 16µs before first byte sent - there is a 50 ns minimum CS setup time per DataSheet.

On a (perhaps?) related note: Have tried to use the usleep() function to tweak µs delays, but resultant delays are in the millisecond range. What do I need to know?

    SPI_Params_init(&spiParams);
    // SPI now in 3-wire mode? Will this help control over the CS?
    Display_printf(display, 0, 0, "  - setting up SPI_Params...\n");
    spiParams.frameFormat = SPI_POL0_PHA1; // other code suggests Mode 3 - POL1 PH1
    spiParams.bitRate = 10000000;  // SLAVE MAX 10 MHZ ON MSP432E4 - so 25LC1024 can be 3.3v
    spiParams.dataSize = 8; /* <-LOU MOD dataSize can range from 4 to 8 bits */
    masterSpi = SPI_open(CONFIG_SPI_MASTER, &spiParams);
    if (masterSpi == NULL) {
        Display_printf(display, 0, 0, "Error initializing master SPI\n");
        while (1);
    }
    else {
        Display_printf(display, 0, 0, "Master SPI initialized\n");
    }

    /* Copy message to transmit buffer */
    strncpy((char *) masterTxBuffer, MASTER_MSG, SPI_MSG_LENGTH);

    for (i = 0; i < MAX_LOOP; i++) {
        /* Datasheet: "The CS pin must be low and the HOLD pin must be high for the entire operation."  */
        ///////////////////////////////////////////////////////////////////////////////
        GPIO_write(EEPROM_CS, 0);    // pulls low
        GPIO_write(EEPROM_HOLD, 1);  // pulls high

        /* ----------------------------------------------
         * Initialize master SPI transaction structure --- */
        masterTxBuffer[sizeof(MASTER_MSG) - 1] = (i % 10) + '0';    // ORIGINAL
        memset((void *) masterRxBuffer, 0, SPI_MSG_LENGTH);
        transaction.count = SPI_MSG_LENGTH;      // SPI_MSG_LENGTH;
        // tDaughterComs.count = (sizeof(SpiRxBuffer) / sizeof(SpiRxBuffer[0]));
        transaction.txBuf = (void *) masterTxBuffer;
        transaction.rxBuf = (void *) masterRxBuffer;

        /* Toggle user LED, indicating a SPI transfer is in progress */
        GPIO_toggle(CONFIG_GPIO_LED_1);
        // usleep(1);  // 1µs ?? I hope? -- much too long  (1 OR 10 µs generates 1.8+ ms delay until first result!)

        /* Perform SPI transfer */
        transferOK = SPI_transfer(masterSpi, &transaction);
        if (transferOK) {
            Display_printf(display, 0, 0, "Msg sent: %s", masterTxBuffer);
            Display_printf(display, 0, 0, " -result: %s", masterRxBuffer);
        }
        else {
            Display_printf(display, 0, 0, "Unsuccessful master SPI transfer");
        }

        /* Toggle user LED OFF */
        GPIO_toggle(CONFIG_GPIO_LED_1);/* Sleep for a bit before starting the next SPI transfer  */

        sleep(2);
   
        // --- DE-SELECT EEPROM
        GPIO_write(EEPROM_HOLD, 0);  // Pull HOLD LOW - end of operation
        GPIO_write(EEPROM_CS, 1);    // pulls high
    }

    SPI_close(masterSpi);

  • Hi LouEEEE!

    Let me look into this.

  • Dennis - Fully understood if you're unable to help with this...

    In fact, hope all of our friends in Texas are AOK? Hopefully things getter better...?

    Meanwhile: Bump on this question - can anyone else weigh in?

  • Hi LouEEEE!

    Thanks for the concern.  All is well here in Dallas now.

    If you are still having trouble maybe you can reduce your code to smallest size possible that still demonstrates the issue and post here for me to take a look.  If proprietary you can send me a friend invite and we can share privately.

  • Dennis - Thanks for getting back on this...

    Nothing proprietary at all. In fact, as I mentioned above, it's a (nearly) verbatim lift of the spimaster example. Significant changes are only that I've put it into explicit 3-wire mode, adding GPIO for the Chip Select and Hold pins.

    And this example is really focused in on what we wish to tease out. Its only issue is that I cannot send the first 2 bytes of the 30-or-so byte message. Any single cycle of the loop effects a test.

    Assuming it's a timing issue, I'd try to fiddle with the placement - timing - of both EEPROM_CS and EEPROM_HOLD and direct manipulation of usleep(), which I cannot get to do what I expect it to(?)

    I'm getting the sense that this is something of an orphan question... Anybody have any thoughts on it?

  • Got it!  Ok, let me get under the hood and see what' going on.  I'll update you.

  • Hi LouEEEE,

    Looks like I have come up empty handed on this one.

    I'll change the status of this posting to RESOLVED, but if this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
    If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.

  • OK - Have been waiting for your response - hoping I was onto something useful here. (It isn't generally useful as a real production setup, but it seemed to be a reasonable test of something.)

    I'll reconstruct it in a couple of days, and report back.

    But, meanwhile; on my specific questions above - about usleep() - or another clever way to move the timing of EEPROM_CS and/or EEPROM_HOLD - any thoughts?