• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 2842 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/MSP-EXP430FR5994: Can't transfer SPI data

Bryan Evenson24
Intellectual 540 points
Part Number: MSP-EXP430FR5994
Other Parts Discussed in Thread: MSP430FR5994

Tool/software: TI-RTOS

I have been able to successfully use some SPI low-level driver examples (examples use SPI without DMA) for the MSP-EXP430FR5994 dev board and I am now trying to get SPI working with my TI-RTOS project and I have not had any success.  I am trying to figure out what is not setup correctly for SPI on my TI-RTOS project.


Steps to reproduce:

1. In Code Composer Studio, create a new CCS project and pick the "Empty (minimal)" project under the TI-RTOS examples for the MSP430FR5994.

2. Replace empty_min.cfg and empty_min.c with the two attached files.

3. Jumper P6.0 and P6.1 together so that EUSCIA3 is setup for loopback mode.

4. Build and run the project.

When I do this, the SPI transfer get setup, but the DMA interrupt never triggers.  I am guessing that there is something not setup correctly for the DMA, but I can't figure out what I'm missing.  Does anyone see what I need to change in order to get SPI transactions to work with TI-RTOS?

8611.empty_min.c
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/*
* Copyright (c) 2016, Texas Instruments Incorporated
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* * Neither the name of Texas Instruments Incorporated nor the names of
* its contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/*
* ======== empty_min.c ========
*/
/* XDCtools Header files */
#include <xdc/std.h>
/* BIOS Header files */
#include <ti/sysbios/BIOS.h>
#include <ti/sysbios/knl/Task.h>
/* TI-RTOS Header files */
#include <ti/drivers/GPIO.h>
// #include <ti/drivers/I2C.h>
// #include <ti/drivers/SDSPI.h>
#include <ti/drivers/SPI.h>
// #include <ti/drivers/UART.h>
// #include <ti/drivers/Watchdog.h>
// #include <ti/drivers/WiFi.h>
/* Board Header file */
#include "Board.h"
#define TASKSTACKSIZE 512
Task_Struct task0Struct;
Char task0Stack[TASKSTACKSIZE];
/*
* ======== heartBeatFxn ========
* Toggle the Board_LED0. The Task_sleep is determined by arg0 which
* is configured for the heartBeat Task instance.
*/
Void heartBeatFxn(UArg arg0, UArg arg1)
{
SPI_Handle handle;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
2335.empty_min.cfg

  • 0
    TI__Guru 56685 points
    Hello Bryan,

    I'm unfamiliar with TI-RTOs, but I would check your DMA register settings to make sure it is triggering on the correct SPI Module/Interrupt. The DMA Trigger assignments are located in the datasheet in section 6.12.8, Table 6-11. The register you want to look at is DMACTLx, where x is from 0-4. Each register holds the trigger for two different DMA Channels. So DMACTL0 is for DMA Channels 0 and 1. DMACTL1 is for DMA Channels 2 and 3, and so on.
  • 0 in reply to Jace H
    Intellectual 540 points

    Jace,


    Thanks for the advice.  I checked and I see that DMACTL2 is set to 0x1110, which sets up channel 4 to trigger on UCA3RXIFG and sets up channel 5 to trigger on UCA3TXIFG.  DMA channels 4 and 5 are being setups with the correct source and destination addresses for the data, so they should be ready to execute the transactions when commanded.  I'm assuming this means that the UCA3RXIFG and UCA3TXIFG interrupts need to be enabled to trigger the DMA to start.  UCA3IE_SPI is set to 0, so the UCA3 won't trigger any interrupts to initiate the transfer.  I think this may be the cause of the issue.


    From looking through the code, I think the UCA3 interrupts need to be enabled at the end of SPIEUSCIADMA_configDMA in SPIEUSCIADMA.c in TI-RTOS.  Is this correct, or is there some other mechanism that should be triggering the DMA transfers to start?  In the meantime I'm looking into how to rebuild TI-RTOS in hopes of trying this change out.


    Thanks,

    Bryan

  • 0 in reply to Bryan Evenson24
    Intellectual 540 points

    I still haven't had any luck using the SPI driver in TI-RTOS.  I've modified TI-RTOS to enable the SPI interrupts after configuring the DMA, but the UCA3IFG remains 0x0.  So far I haven't been able to get any interrupt related to the DMA or the SPI port to trigger and I'm not sure what else there is to try.


    Any insight as to what may be going wrong would be appreciated.

  • 0 in reply to Bryan Evenson24
    TI__Guru 56685 points

    Bryan,

    If the UCA3IFG is not being triggered, then it is not see the SPI transaction. I would check a few things here:

    • *Are any other USCI IFGs being set? (UCA0IFG, UCA2IFG, UCB0IFG, etc.)
    • *Are your pin configurations for the USCI A3 SPI pins set properly? (Set to SPI functionality)
    • *Are your physical SPI pins connected to the correct USCI?
    • *Can you check with a logic analyzer to make sure transactions are happening over the SPI pins?

    The following application note will be of some help as well.  Solutions to Common eUSCI and USCI Serial Communication Issues on MSP430 MCUs

  • 0 in reply to Jace H
    Intellectual 540 points

    Jace,


    Thanks for the suggestions.  In response to your questions:

    * I've verified that no other USCI IFGs are being set after I call SPI_transfer().

    * I modified the "msp430fr5994_euscia0_spi_09" demo to operate on USCIA3.  I verified that I can send and receive on the eval board with this register level example, so I've confirmed that I have my external wiring setup correctly.  I compared the register settings on this example with what gets setup with the SPI drivers with TI-RTOS.  There were minor differences in the SPI registers for the clock and baud rate generation.  I tried setting the UCA3 registers to match what they were set to in the msp430fr5994_euscia_spi_09 demo and I still didn't get any interrupt to trigger.

    * I've checked with an oscilloscope and I've confirmed that no data is being transmitted on the the SPI bus.

    Could someone look at the empty_min.cfg I have in the first post and let me know if I have the HWI setup correctly?  From reading the TI-RTOS user's guide, I can't tell which function the HWI should be calling, or which interrupt should be monitored (the SPI interrrupts or the DMA interrupts).  Does someone at TI have a working example of using the TI-RTOS SPI driver that I can use as a starting point?

    Thanks,

    Bryan

  • 0 in reply to Bryan Evenson24
    Intellectual 540 points

    I've been doing more testing with the register level example in hopes of at least getting this to work with TI-RTOS.  I started getting something setup to transmit a message as opposed to single messages, which meant stopping transmission when the message was done.  I found something odd.  If I disable the TX interrupt (UCA3IE &= ~UCTXIE) when the transmit buffer register UCA3TXBUF is empty, then later when the TX interrupt is enabled again it does not trigger.  However, if the TX interrupt is only disabled immediately after filling the transmit buffer register, then TX interrupt will trigger again if it is re-enabled.  This could explain why I never see the TX interrupt fire when using the SPI driver with TI-RTOS.

    Is there something else that needs to be set when re-enabling the TX interrupt so it will trigger in all cases?

  • 0 in reply to Bryan Evenson24
    TI__Guru 56685 points
    Bryan,

    Please keep in mind that the TX Flag is set when the TX buff is emptied. By turning of the interrupt as this happens, you will not get an interrupt. Once you turn it back on, you should get an interrupt again as long as the flag hasn't been cleared, which could possibly happen if you got a RX interrupt and depending on the priority of interrupts. Reason for this is that when the IV is accessed, the highest priority flag is cleared.

**Attention** This is a public forum