• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 29 subscribers
  • Views 922 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.

LM4F120 SSI with external DAC - no output

Rob P
Prodigy 100 points
Other Parts Discussed in Thread: TLV5616

I'm trying to connect a TLV5616 to the lm4f120 launch pad via SSI.  I'm getting no errors when running the code, but I'm also not getting any output.  I'm using the 3.3V out from J1 and the gnd from J3 for Vdd and Gnd for the 5616. I have a simple voltage divider for Aref.  I have SSI0TX connected to DIN, SSI0CLK connected to SCLK, and SSI0FSS connected to FS.  The CS pin on the tlv5616 is tied low.

On the output side, I have tried connected OUT to both a 4.7k resistor and an LED to ground and also a simple LED driver (4.7k to 2n3904 base, emitter to gnd, collector to LED to 2k).

My code simply ramps the output from 0 up to 4095 and back down again. I'd expect to see the LED pulse, but I'm getting nothing.  I've verified Vdd and Aref with my multimeter (3.3v, 1.65v as expected).

Have I made an error in my code?  Since the 5616 wants a falling clock edge to transfer the data, I'm using Mode 1, but I've tried other modes with no effect. I've verified in CCS that the output I'm trying to write does increment and go back down again.  I did notice that the result of SSIDataPutNonBlocking always appeared to be 0, unless I stepped into it and then it came back 1.  Even in the 0 case I examined the SSI registers and saw that the transmit FIFO was not full.  It showed empty at the time, too, but the output is clocked so high that it would have emptied by the time I observed it.

Here's the code from main:

    ROM_FPUEnable();
    ROM_FPULazyStackingEnable();

    //
    // Set the clocking to run directly from the crystal.   //80 MHz?
    //
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ |
                       SYSCTL_OSC_MAIN);
                       
    //
    // Initialize the UART.
    //
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
    ROM_GPIOPinConfigure(GPIO_PA1_U0TX);
    ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    UARTStdioInit(0);

    //
    // Hello!
    //
    UARTprintf("Hello, world!\n");
    
    RGBInit(0);
    RGBSet(COLOR_RED, 1.0f);
    RGBEnable();

    // init ssi
    SysCtlPeripheralEnable(SYSCTL_PERIPH2_SSI0);
    GPIOPinConfigure(GPIO_PA5_SSI0TX);
    GPIOPinConfigure(GPIO_PA2_SSI0CLK);
    GPIOPinConfigure(GPIO_PA3_SSI0FSS);
    GPIOPinConfigure(GPIO_PA4_SSI0RX);

    // SSIConfigSetExpClk(SSI0_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_1,
    //		SSI_MODE_MASTER, 20000000, 16);
    SSIConfigSetExpClk(SSI0_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_1,
    		SSI_MODE_MASTER, 10000000, 16);

    SSIEnable(SSI0_BASE);

    float intensity = 0;
    float increment = 0.1;
    unsigned long * color = (SysCtlClockGet() == 80000000 ? COLOR_BLUE : COLOR_RED);

    unsigned short spiData = 0;
    short spiIncrement = 400;
    long entriesWritten = 0;

    while(1)
    {
        RGBSet(color, intensity);

        entriesWritten = SSIDataPutNonBlocking(SSI0_BASE, 0x4000 | spiData);
        if(entriesWritten == 0)
        {
        	//a bad thing
        }

        //SSIDataPut(SSI0_BASE, 0x4000 | spiData);
        //SSIDataPut(SSI0_BASE, spiData);

        //
        // Delay for a bit.
        //
        SysCtlDelay(SysCtlClockGet() / 80); // 10 / 3

        intensity += increment;
        if((intensity >= 1.0) || (intensity <= 0))
        {
        	increment *= -1;
        }

        spiData += spiIncrement;
        if((spiData >= 4000) || (spiData <= 0))
        {
        	spiIncrement *= -1;
        }
    }

  • 0
    Prodigy 100 points

    Ha.  I added

    GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_5 | GPIO_PIN_4 | GPIO_PIN_3 |
                       GPIO_PIN_2);

    From the example, but I don't think that did it.

    Instead, I replaced the LED with a new one and everything works.  I must have blown it somehow when fiddling with the circuit.

  • 0 in reply to Rob P
    Guru 117855 points

    Good for you - effort/resourcefulness awarded.

    I've not read the spec for your DAC - but most do not provide much in the way of current output.  (many we've used require/benefit from an op-amp buffer - interposed between DAC output and "outside world.")

    I'd not have thought to use an Led to monitor a voltage swing - scope or even an analog bar-graph (composed of 8 to 20 Leds - each driven by a proper analog to digital converter/processing circuit - appear far more, normal/customary.) 

    Note too that a 2 x16 char Lcd can serve as an 80 segment bar-graph - with clear scale notations upon the 2nd line.  (suggest such as a neat addition to your test bench - cost effective & even "low frequency, scope-like" in its capability...)

    Usually that GPIOPinType() you list is required - although you may liberate the FSS pin from that role - instead controlling it as "normal" GPIO.

    When we visit clients with such "off board" circuit add-ons - always we stress the importance of power turning ON/OFF in unison - both the MCU and accessory board.  Power to one board only - too often - proves destructive to the non-powered board.  Insure that the board to board, power connectors you've devised are secure - and always "ON."

  • 0 in reply to cb1_mobile
    Guru 26105 points
    Hi,
    I think there may be some problems with hardware first: doubt a potentiometer will do same job as a reference circuit - do not know how much current is drown while operating. Better idea is to use the 5V as VDD, taken from USB connector and 3.3V ref from micro supply, to apply to DAC.
    Also, saw this note on page 12 of the data sheet:
    After the write operation(s), the DAC output is updated automatically on the next positive clock edge following the sixteenth falling clock edge. So the SSI mode should be Freescale SPI format with SPO=1 and SPH=0 (driverlib lingo: SSI_FRF_MOTO_MODE_2). 
    And even with Stellaris micros, never used SYSCTL_PERIPH2_SSI0.

    Petrei

  • 0 in reply to Petrei
    Guru 117855 points

    Petrei said:
    even with Stellaris micros, never used SYSCTL_PERIPH2_SSI0.

    @ Petrei,

    That one, "threw me for a loop" too - some other post.  But I checked - it is listed w/in StellarisWare9453!

    Commend your diligence in "better read" of poster's data sheet.  (than poster)  Critical to properly mate the MCU format to that of the external/targeted SSI device.

    Your "better idea" of 5V from USB & 3V3 (you are Euro based - aren't you?) surely makes sense - should be heeded.

  • 0 in reply to cb1_mobile
    Prodigy 100 points

    As explained prior, there is no hardware problem as evidenced by everything working correctly if a timer isn't enabled.

    Secondly, the data sheet clearly explains (at the header of the page and in the text) that the DAC operates from vdd ranges of 2.7 - 5.5V.

    Third, you've read about the DAC output, but not the timing of FSS as it relates to clock. I'm definitely using the correct mode here. (Then, a falling edge of FS starts shifting the data bit-per-bit (starting with the MSB) to the internal register on the falling edges of SCLK.)

    Fourth, the data sheet shows that the DAC has a rail to rail opamp at the output, so sourcing current isn't a problem.

    Thanks for trying to help, though.

  • 0 in reply to Rob P
    Guru 117855 points

    Rob P said:

    Thanks for trying to help, though.

    Damning with faint praise!  (let the record show that law school (after eng) was good for something...)

  • 0 in reply to cb1_mobile
    Prodigy 100 points

    Ha. No worries. I genuinely appreciate the help :)

  • 0 in reply to cb1_mobile
    Guru 26105 points

    Hi,

    @cb1-mobile,

    My first StellarisWare version is 54xx (don't remember exactly the lasts two figures) and used with TI DACs and never used _PERIPH2_ - if this does not hurt then OK (there is only one place where is defined, does not matter..)

    And yes, I am Euro based...

    On the other side, I am aware of the phrase that states the output of the DAC is only on the sixteenth rising edge of the clock - if this does not trigger anything, I give up (momentarily).

    Petrei

  • 0 in reply to Petrei
    Guru 47900 points

    Petrei said:
    if this does not trigger anything, I give up (momentarily).

    Monsieur Petrei - others here/myself - know that you, "never give up!"

    But 3.3V - from Euro based guy - even this Yankee (NYC) knows to use 3V3!   (for past 10 years, I'd say)  Euro clients forced this upon us - decimal is too easily lost (disappears) - thus it makes good sense!  Ciao...