Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

MSP432P401R: Logic analyzer: SPI shows weird signals

Part Number: MSP432P401R

I have a logic analyzer attached to MSP432-EUSCI_B3-Pins in SPI slave mode. I read data using DMA channel 7 (DMA_CH7_EUSCIB3RX0). The DMA-finished-interrupt gets called so we have some DMA transfer taking place.

But when I try to capture/visualize data in logic analyzer I only see some peaks but no proper signal for SPI slave. Here is an example of two 32 bit transfers:

However, if I add the following code after initialization/enabling of PRIMARY_MODULE_FUNCTION the logic analyzer shows correct signals - but then the DMA does not work anymore!

GPIO_setAsInputPinWithPullDownResistor(GPIO_PORT_P10, GPIO_PIN3 | GPIO_PIN2 | GPIO_PIN1);

Any ideas how I can have both DMA and logic analyzer working properly?

  • Is this related to the errata PORT34? http://www.ti.com/lit/er/slaz610q/slaz610q.pdf#page=5

    Can you replicate the issue with a code example?
    http://dev.ti.com/tirex/#/?link=Software%2FSimpleLink%20MSP432P4%20SDK%2FExamples%2FDevelopment%20Tools%2FMSP432P401R%20LaunchPad%20-%20Red%202.x%20(Red)%2FDriverLib%2Fspi_3wire_incrementing_data-slave

    Regards,
    Chris

  • After reading errata PORT34 I cannot imagine this issue as root cause - I neither use any of the timers nor any of the pins mentioned there.

    I will give the code example a try, tomorrow.
  • Here is the result: after disabling all the DMA stuff and implementing an ISR as in spi_3wire_incrementing_data-slave example the situation changed slightly:
    The SPI input pin /seems/ to work correctly for 2,7 milliseconds - then the first "peak" appears as shown in the screenshot above, and the story continues...
  • Meanwhile I found the real root cause: it's a hardware wiring issue - the SiMo- and SoMi-pins of SPI are swapped and hence it cannot work!
    I noticed the error when trying to send out non-zero bytes (with controller configured as slave I've seen no reason why to put anything else than zeros on the line) - the sent bytes appeared as signals on the SiMo-Line (controller input).

    So if one sees weird signals in logic analyzer it's worth checking the correct pin function/direction.

**Attention** This is a public forum