Group Actions
Engagement
  • Author Author: peteroakes
  • Date Created: Date Created
  • Views 854 views
  • Likes 2 likes
  • Comments 1 comment
Related
Recommended

Raspberry PI 2.0, Windows 10 and Diagnosing issues with the SPI bus when writing software for the DAC8734.

peteroakes

The video leading up to this one can be found here Raspberry PI 2.0, Windows 10 and how to drive the DAC8734 from TI (AKA the DAC8734EVM Road test Board),

This is the third Raspberry PI 2.0, Windows 10 and how to drive the DAC8734 from TI - Software review

This post is a direct result of having issues while trying to get the DAC8734 working on the PI, in previous applications I had written on the PI and with Windows 10 for IOT, I had simply used Mode 0 SPI clocking and it worked without issues, This included many TI  chips. So my assumption was that the DAC8734 would be the same. I was wrong.

 

The Tektronix MDO304 proved invaluable in diagnosing this issue. things would have taken alot longer without it, nice one Tektronix, thanks.

image

This prompted me to put together a video and post describing the issue and showing how it was resolved. there are loads of pictures and I even managed to keep the video way under the 1Hr mark so many of you will be happy about that image

 

here is the rough schematic of the hardware

image

 

This is the SPI initialization routine from my code (The complete source code is available in the first post linked in above)

        public static async void InitSPI(TextBox StatusMessages)
        {
            statusText = StatusMessages; // keep pointer to status box incase of errors
            try
            {
                var settings = new SpiConnectionSettings(SPI_CHIP_SELECT_LINE);
                settings.ClockFrequency = 5000000;// 10000000;
                settings.Mode = SpiMode.Mode1; //Mode0,1,2,3;  DAC8734 needs mode 1


                string spiAqs = SpiDevice.GetDeviceSelector(SPI_CONTROLLER_NAME);
                var deviceInfo = await DeviceInformation.FindAllAsync(spiAqs);
                SpiDAC = await SpiDevice.FromIdAsync(deviceInfo[0].Id, settings);
            }


            /* If initialization fails, display the exception and stop running */
            catch (Exception ex)
            {
                statusText.Text ="\nSPI Initialization Failed";
            }
        }

 

you can clearly see the mode setting statement Spi.mode1 and the setting of the clock requency

 

the DAC8734 can run up to 50Mhz but as this was on a breadboard, the best i tried was 20Mhz, the clock was a nice sine wave by this time but still working

Here is a trace of the SPI but in mode 0, it was not working even though the scope was happily decoding it correctly. .

imageimage

 

I had to refer to the PDF data sheet and closly examin the timing diagrams in order to figure it out (I guess I could have simply fliped a few parameters in the code too but then I would not learn as much. As there was little information outside of the PDF I had been able to find including a lack of sample code it was down to sleuthing. There was no mention in the data sheet of the right mode

 

so time to compare diagrams, here is the one from the PDF

image

 

It can be clearly be seen that the timeing was wrong on the scope even though the scope was decoding it correctly (Tek is too cleaver for its own good, it defaulted to mode 0 too image. the PDF is showing the clock falling edge is the one to use to latch in the data but the scope is showing it using the rising edge

 

Switching the mode to 1 resulted in this trace

image

Bingo, the DAC was now responding reliably to my commands. Job done.

 

But in an effort to provide a little more education I went further and captured a bunch of traces with each mode from 0 through to 3 so you can clearly see the differences in the clocking in relation to the data

 

 

Mode 0 (Normally low level clock when idle, clocking in the data on the rising edge ). Yellow trace is the clock if you did not get that already image. Purple is the data and blue is the chip select (Off screen start due to a slow Win10IOT SPI driver)

image

 

Mode 1 (Normally Low clock when idle, clocking in the data on the falling edge of the clock). This race is outputting to dac 1 which is why the first byte is a 5, Register offset to the DAC output register)

image

 

Mode 2 (Normally high level clock when idle, clocking in the data on the rising edge ).

image

and finally

Mode 3 (Normally high clock when idle, clocking in the data on the falling edge of the clock).

image

 

One of the other issues I had was trying to get a sine wave out of the DAV using the Raspberry PI, this should have been possible to get a reasonable output frequency as I had already got upto 250Htz from a Launchpad using a tehnique of itterating through a 256 Entry 16Bit sime table array. simple right. well yes untill you fin the SPI drivers are running really slow. I am not refering to the actual clocking of the data, as you can see above int he traces, this is working fine. The issue as it ended up being is in the drivers time to return to the running application

If I run a loop of 255 cycles it takes over 11 seconds to complete, this works out to 4mS per cycle (256 Steps) which is really slow. commenting ut the lowest call to the DAC as seen in the code below resulted int he whole loop completing in 33mS

 

        public static void WriteDACRegister(UInt16 register, UInt16 value)
        {
            if( ! (SpiDAC == null) && (DACInitialized == false))
            {
                DACInitialized = true;
                DAC8734.InitDAC();
            }
            byte myChannel = (byte) (register);
            writeBuffer[0] = myChannel;
            writeBuffer[1] = (byte)(value >> 8);
            writeBuffer[2] = (byte)(value & 0XFF);


            try
            {
                //SpiDAC.Write(writeBuffer);
            }


            /* If initialization fails, display the exception and stop running */
            catch (Exception ex)
            {
                statusText.Text = "\nFailed to Wrie to DAC";
            }
        }

This is the sine loop

       public static void sine(UInt16 channel, int loopcount)
        {
            statusText.Text = "Sine Loop " + loopcount * 256 + " Steps\n ";
            UInt16 myChannel = (UInt16)(DAC_8734_DataBase + channel);
            if (loopcount > 32768) loopcount = 32768;
            WriteDACRegister(myChannel, 0); // set DAC to 0 to start and init if needed
            startTime = DateTime.Now;
            for (int y = 0; y < loopcount; y++)
            {
               for (UInt16 x = 0; x < 256; x++)
               {
            WriteDACRegister(myChannel, Sin_tab[0]);
                }
            }
            endTime = DateTime.Now;
            statusText.Text += "Total Time " + ((endTime.Subtract(startTime).TotalSeconds)).ToString() + "Seconds\n";
            statusText.Text += "Sine loop Done\n";
        }
    }

 

and this is the table it reads from (All this is in the source code attached to the previous post)

        private static UInt16[] Sin_tab = {  32768,33572,34376,35178,35980,36779,37576,38370,39161,39947,40730,41507,42280,
                               43046,43807,44561,45307,46047,46778,47500,48214,48919,49614,50298,50972,51636,
                               52287,52927,53555,54171,54773,55362,55938,56499,57047,57579,58097,58600,59087,
                               59558,60013,60451,60873,61278,61666,62036,62389,62724,63041,63339,63620,63881,
                               64124,64348,64553,64739,64905,65053,65180,65289,65377,65446,65496,65525,65535,
                               65525,65496,65446,65377,65289,65180,65053,64905,64739,64553,64348,64124,63881,
                               63620,63339,63041,62724,62389,62036,61666,61278,60873,60451,60013,59558,59087,
                               58600,58097,57579,57047,56499,55938,55362,54773,54171,53555,52927,52287,51636,
                               50972,50298,49614,48919,48214,47500,46778,46047,45307,44561,43807,43046,42280,
                               41507,40730,39947,39161,38370,37576,36779,35980,35178,34376,33572,32768,31964,
                               31160,30358,29556,28757,27960,27166,26375,25589,24806,24029,23256,22490,21729,
                               20975,20229,19489,18758,18036,17322,16617,15922,15238,14564,13900,13249,12609,
                               11981,11365,10763,10174,9598,9037,8489,7957,7439,6936,6449,5978,5523,5085,4663,
                               4258,3870,3500,3147,2812,2495,2197,1916,1655,1412,1188,983,797,631,483,356,247,
                               159,90,40,11,1,11,40,90,159,247,356,483,631,797,983,1188,1412,1655,1916,2197,
                               2495,2812,3147,3500,3870,4258,4663,5085,5523,5978,6449,6936,7439,7957,8489,9037,
                               9598,10174,10763,11365,11981,12609,13249,13900,14564,15238,15922,16617,17322,
                               18036,18758,19489,20229,20975,21729,22490,23256,24029,24806,25589,26375,27166,
                               27960,28757,29556,30358,31160,31964};

 

so there was clearly an issue with the Windows 10 driver (Ill report that to MS), to confirm this I captured the SPI bus across two itterations

the complete trace between two outputs, I have a cursor on to show the timing o 172.9uS, bu you can clearly see how long it takes to release the chip select line after the data has completed transmission, and then the horendious time before the next loop

image

this is a close up of the two bursts of data in the above trace

imageimage

 

As you see, nothing wrong with the actual transmission.

 

here is the video, it provides much more commentry and detail, hope you like it

 

So I hope you find this interesting and enjoy the little walk down the dark side of SPI debugging and I hope you came away from this a little more educated about the SPI bus, I know I did.

 

It is actually quite a simple bus to use and at the end of the day as useual, READ THE PDF, if you get into issues then READ IT AGAIN. we all fall into the trap of thinking it is something else (And that includes me) but careful examination of the datasheet nearly always will show you the error of your ways

and secondly, just because one chip from a specific manufacturer works one way, dont assume all of them will work the same way, as was he case with me, "Assume... makes an Ass out of You and Me image ". I guess were all never too old to learn we still have much to learn.

Parents Comment Children
No Data