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: How to exert fine control over SPI CS pin using SPI Transaction?

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

I am having no luck getting a simple response from a Microchip 25LC1024 EEPROM. Code below will successfully write a 32-bit transaction; the command 0xAB, followed by 24 bits of drivel. (0xAB: Release from Deep power-down and read electronic signature). If CS is kept low, the response should be 0x29, the Manufacturer's ID, per this from the DataSheet:

It's clear that the CS bumps high right after the MOSI write; how do I control this in a more granular fashion using the SPI Driver??

(Must admit, I've never tried the SPI Driver approach before). We've done this on a pin-by-pin GPIO basis in other contexts; do I have to go back to that? For that matter, what is the advantage of moving to the EUSCI model? Which approach is optimal on this platform? IE, which should we figure out, then stick with? Really lovin' the MSP432E platform; am doing early experiments.

Following code is based loosely on spi_master, with all the master-slave notification bits removed:

/* Open SPI as master (default)
     * The 25LC1024 contains an 8-bit instruction register.
     */
    SPI_Params_init(&spiParams);
    spiParams.frameFormat = SPI_POL0_PHA0;
    masterSpi = SPI_open(Board_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");
    }


     /* Initialize master SPI transaction structure */

     uint8_t masterTxBuffer[32] = SSE_RDID; // 0xAB Release from Deep power-down and read electronic signature
     uint8_t masterRxBuffer[32];

     transaction.count = 4;  // LOU MOD: 4 * 8 bits?
     transaction.txBuf = (void *) masterTxBuffer;
     transaction.rxBuf = (void *) masterRxBuffer;

     /* Toggle user LED, indicating a SPI transfer is in progress */
     GPIO_toggle(Board_GPIO_LED1);

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

  • Hi,

    you are using the MSP432E device but you also say that you are using the EUSCI. The EUSCI is only available in MSP432P4 and MSP430 devices. So not sure what is right but i assume that you are using the MSP432E4.

    For the SPI: based on the figure from the EEPROM data sheet you need to send 0xAB as command and then 24 bits address after that you expect to receive 8 Bit as answer. Within this frame the CS signal should stay low.

    As the SPI can only receive while sending data you need to provide an additional byte to the transaction. This means you your case you should transmit 5 Bytes:
    - command (1 Byte)
    - Address (3 Bytes)
    - Dummy to receive (1 Byte typically 0xFF or 0x00)

    The last byte in the receive buffer then your answer.

    Regards,
    Stefan
  • Stefan,

    I thank you for weighing in with your feedback on this. I've tried exactly your suggestion; in fact, had already tried this and variants of it; longer frames, etc. No Joy. Trace is below:

      

    Think I better look at how to set SPI clock speed on this board; the 25LC1024 expects a 20MHz max CLK speed.

    I am happy for any further suggestions. As always, this will turn out to be something really simple.

    I'm also now checking all breadboard connections (for the 6th or 7th time!); I'd be happy if it turned out to be something so simple. I'm even swapping chip; is it possible this one is defective? Seems unlikely.

    Indeed, I am using the MSP432E4. And not using EUSCI; I should have said what would be the advantage. Was only asking the question as I'd seed so many examples of EUSCI use out there - yes, on MSP432P.

  • The protocol would look OK. Just two things which came in my mind:
    Why is the CS line going low outside the frame?
    Have you also checked the other pins of the EEPROM. E.G the HOLD signal being high (just to ensure)

    Regards,
    Stefan
  • OK, well; First; I should thank you for putting me onto what I'm sure is The Right Track...!

    I had been blithely ignoring the HOLD signal thus far, thinking: Hey, I'm not doing any transaction HOLDs, so why bother? However, sure enough, the HOLD is held low by default during the whole transaction. Clearly this won't work: The CS pin must be low and the HOLD pin must be high for the entire operation. (Again, very early, cursory experiments with this thing; I'm learning!)

    Stefan Schauer said:
    Why is the CS line going low outside the frame?

    As to CS: I have been relying, thus far, on the following from TI-RTOS docs: ...the SPI driver provided with TI-RTOS has been designed to operate transparently to the SPI chip select. When the hardware chip select is used, the peripheral automatically selects/enables the peripheral.

    Right, but this is clearly not gonna be good enough in my case(s).

    Going off to implement pin-specific GPIO controls; will report back.

  • Checking Docs: Am using SDK 2.30.00.14. The SPI Driver docs don't clearly indicate how to 'set' Software chip select.

    • Hardware chip select No additional action by the application is required.
    • Software chip select The application needs to handle the chip select

    OK, have been trying to set up HOLD and CS as GPIO pins; Clearly missing something fundamental here...

    Code is based on spimaster_MSP_EXP432E401Y_tirtos_ccs

    in MSP432E401Y.c (added to end):

    GPIO_PinConfig gpioPinConfigs[] = {
    ...
        /* Output pins for BOARD_SPI0 - EXPERIMENTS with 25LC1024 */
        /* PLACE these into MSP_EXP432E401y.h typedef enum MSP_EXP432E401Y_GPIOName,
         * then Map these to more sensible names in Board.h?            */
        GPIOMSP432E4_PQ0 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW, /* SPI CS */
        GPIOMSP432E4_PQ1 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_LOW | GPIO_CFG_OUT_LOW, /* SPI HOLD */

    in MSP432E401Y.h (added to end of enum:):

    typedef enum MSP_EXP432E401Y_GPIOName {
        (...)
    
        /* CONTROL pins for SPI_MASTER
         * see definition array in MSP_EXP432E401Y.c
         * */
        MSP_EXP432E401Y_SPI_MASTER_CS,
        MSP_EXP432E401Y_SPI_MASTER_HOLD,
    
        MSP_EXP432E401Y_GPIOCOUNT

    Then mapped them in Board.h:

    /* MOD: Add two pin controls for SPI-MASTER (see defs in MSP_EXP432E401Y.c file  */
    
    #define Board_SPI_MASTER_CS         MSP_EXP432E401Y_SPI_MASTER_CS
    #define Board_SPI_MASTER_HOLD       MSP_EXP432E401Y_SPI_MASTER_HOLD

    Then, in '.c' code:

    GPIO_init(Board_SPI_MASTER_CS);
    GPIO_init(Board_SPI_MASTER_HOLD);
    
    // Have tried this both ways; same result:
    // GPIO_write(Board_SPI_MASTER_HOLD, 1);  // HOLD HIGH
    GPIO_write(Board_SPI_MASTER_HOLD, Board_SPI_MASTER_HOLD);  // HOLD HIGH

    Related: I can't find an explicit option to set the SPI Driver to 3-wire mode - would this be the right approach, given external assertion of CS?

    Am I better off trying this using SPIMSP432DMA?

    What is the Best Practices approach to implementing multi-CS on one master?

  • Hi Lou,

    yes, that looks OK from the Setup for the HOLD.

    To use you should use:

    GPIO_write(Board_SPI_MASTER_HOLD, 1);  // HOLD HIGH

    For the CS there is already a pins assigned


    GPIO_PinConfig gpioPinConfigs[] = { ....... /* MSP_EXP432E401Y_SDSPI_CS */ GPIOMSP432E4_PC7 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_HIGH,

    So it is on PC7 - not sure if you have used this pin for that already.

    Regards,

    Stefan

  • Hi Lou,

    could you solve the issue or do you have further questions regarding this topic?
    If solved, please select "Resolved" for the post that solved your issue so this thread can be closed out. If you have a different question, please select "Ask a related question" or " Ask a new question".
    Thanks a lot!

    Best regards,
    Stefan
  • Hi Lou,

    I suppose that you were able to move on with your application as you didn't reply anymore, so I'll close this post.
    Please feel free to comment again if you look for further assistance regarding this topic, it will re-open the thread. If you have a different question, please select "Ask a related question" or " Ask a new question".

    Best regards,
    Stefan
  • Stefan, I thank you again for your inputs. (I wish I could move on with my application, but one is pulled in several 'move on' directions at once.) I am circling back to this specific topic this week, with any luck, and will post back here.
  • Hi Lou,

    thanks for the update.

    I just set the status to resolved but you can add a new comment and the status will change to open again.

    Regards,

     Stefan

**Attention** This is a public forum