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.

BOOSTXL-TUSS4470: BOOSTXL-TUSS4470 and MSP-EXP430F5529LP - Getting ADC values using energia at 1MHz

Part Number: BOOSTXL-TUSS4470
Other Parts Discussed in Thread: MSP430F5529, ENERGIA, TUSS4470, MSP-EXP430F5529LP

Hi,

I successfully configured BOOSTXL-TUSS4470 to work properly with a 1MHz transducer using the reference configuration posted by Prodigy.

https://e2e.ti.com/support/sensors/f/1023/t/927400?BOOSTXL-TUSS4470-BOOSTXL-TUSS4470-and-MSP-EXP430F5529LP-with-STEMInc-SMD15T21R111WL-transducer-inconsistent-voltages

 

It works well through the GUI, but when I try to sample the transducer and read the raw ADC values I keep getting the same flat signal.

I am using the following register init:

tuss.tuss44x0_regWrite(0x10, 0x5F);
tuss.tuss44x0_regWrite(0x11, 0x00);
tuss.tuss44x0_regWrite(0x12, 0x1C);
tuss.tuss44x0_regWrite(0x13, 0xC1);
tuss.tuss44x0_regWrite(0x14, 0x00);
tuss.tuss44x0_regWrite(0x16, 0x00);
tuss.tuss44x0_regWrite(0x17, 0x07);
tuss.tuss44x0_regWrite(0x18, 0x14);
tuss.tuss44x0_regWrite(0x1A, 0x04);
tuss.tuss44x0_regWrite(0x1B, 0x00);
tuss.tuss44x0_regWrite(0x1C, 0x08);

I've changed lines 64 - 67 to support the 1MHz, and the configuration for the burstBitBang to tuss.burstBitBang(1, 4); (1usec according to 1MHz)

When I try to use the burstBitBang using the burstTimer instead of simple toggling the device halts.

Do you have any idea/working example to sample the ADC at 1MHz?

Thanks.

  • Hi Itamar,

    I will have to look into the burstBitBang and burstTimer functions to double-check their support for 1MHz. Let me get back to you later today on this matter.

    Have you had a chance to oscilloscope probe the IO1 or IO2 pins to check whether the MCU is actually pulsing at 1MHz?

  • Hi Itamar,

    I've double checked the high-frequency operation to find the following limitations:

    • When using the burstBitBang function, a frequency of up to 424 kHz is supported.
      • Frequencies above 425kHz will always be restricted to 425kHz. This is due to the MCU's clock and speed of the GPIO bit bang for the MSP430F5529 in Energia.

      When using the burstTimer function, a frequency of up to 260 kHz is supported.
      • Frequencies above 260kHz will cause a timer error, and result in either a driver frequency of 260kHz or 30.75Hz.

    When attempting to run the burstTimer in 1MHz mode, the hardware does not halt for me; only the driver error of 30.75Hz instead of 1MHz is generated.

    This all being said, the initial release of the TUSS44x0 library primarily targeted the low frequency (<100kHz) applications. A future version of the library may be released to fully support the complete range of frequencies up to 1MHz. However, Energia may not be best suited for 1MHz transducer operation since it typically is used for slower applications (operating in millisecond resolution). You may need to port this project to Code Composer Studio to enable faster operation and support for 1MHz operation in the meanwhile.

  • Thank you for your quick and informative response.

    I guess I will have to port the library and use it without energia.

  • One more question please - I cannot find a reference to it on the datasheet.

    Is there any way to increase the resolution of the ADC values in a way that I won't get just the envelope of the signal?

    I am trying to get the actual returned echo of the 4/8/16 transmitted pulses.

  • Itamar,

    The TUSS44x0 devices are analog front end only devices that return an analog output at the VOUT pin. The MCU's integrated ADC is used to capture and digitize this echo envelope, so you will need to configure the MCU's ADC settings to modify the resolution and sample rate.

    The TUSS44x0 can only output the demodulated log amp output signal, so this is your only echo envelope output option.

  • I understand.

    Thank you for your help Akeem.

  • We are using a 1MHz transducer for millimeter-level accuracy with short range (under 100 millimeters) liquid level measurement using the Texas Instruments code libraries and the TUSS4470. Akeem said that the project code can be ported to support 1MHz, but it is not clear what type of changes to the TI code libraries are needed to support this ability. He described that the burstTimer can be used to add support for 1MHz while the burstBitBang function may not be able to achieve that frequency. Is any additional information available that describes the required code changes? An alternative is to use a 400 KHz transducer, but I have not found enough evidence to confirm it will produce a comparable accuracy for liquid level measurement compared to the 1MHz transducer.  Also, does TI have any documents that explain how the output values produced by the example Energia code can be used to generate distance (meters) and time values? I read the software development guide located here, but could not find a description of the output values. Thank you,

    John

  • I want to clarify a main question in my last post :  Is Energia the factor that currently prevents 1MHz operation, or is it the C plus plus code library?

    Thanks,

    John

  • Hi John,

    Energia is currently the limiting factor preventing 1MHz operation because it forces a much slower clock in background files that the user is not recommended to access. I believe the DCO frequency used by the timer function I have created for the TUSS44x0 library is forced to reference ~1.045MHz instead of something more ideal like 4-16MHz to allow for a proper clock divisor to reach 1MHz.

    The MSP430F5529 is capable of a master clock of 25MHz, so if you were to create your own project in Code Composer Studio (CCS), you will have complete control over the clocks used throughout the MCU. It is possible to enable a 1MHz bit bang or timer based toggle of the IO1/2 pins on the TUSS44x0 using the MSP430F5529, just not with Energia.

    The problem with Energia is that many features reference the same clock from the MCU (SMCLK). So if you were to change the clock settings in "C:\ti\energia-1.6.10E18\hardware\energia\msp430\cores\msp430\wiring.c" file, you could unintentionally break a different feature used by Energia, such as the serial communication to the PC. I've tried editing the Energia init_clock function in the past, but created more problems, so it is a known limitation of the IDE. Eventually, our team will need to create a CCS example to enable 1MHz. In the meanwhile, I hope the Energia project can serve as a good example for the structure required by your custom CCS project.

    FYI, the MSP430F5529 in Energia uses a 16MHz master clock by default. You can change the master to 25MHz so that the timer based burst toggle increases from a 260kHz max to a 400kHz max in Energia. To change the master clock in Energia, update the following line in the boards.txt file found in the source directory of the Energia IDE:

    Form:

    MSP-EXP430F5529LP.build.f_cpu=16000000L

    To:

    MSP-EXP430F5529LP.build.f_cpu=25000000L

    I know this doesn't solve the 1MHz problem, but enables you to use the 400kHz transducer alternative you mentioned. I don't see why a 400kHz transducer can't be used for level detection with millimetre accuracy. The main disadvantage of the 400kHz option will be a longer ring decay, meaning the minimum detectable distance may be worse than the 1MHz, while the 1MHz may not be able reach as long of a maximum range as the 400kHz.

  • Hi Akeem,

         Thank you for your detailed response, it provides valuable insight into alternative options and makes everything more clear. I'm not familiar with using a divisor to derive a lower clock speed from a higher one, but I can research this concept.  If it is the best solution, I will port all or some of the TUSS44x0_Ultrasonic.cpp Energia functions I need (code available from the TUSS4470 page here: step 6) from Energia C PlusPlus code into C code using the MSP430 driverLib (docs here) included in Code Composer Studio.  Does anyone know if TI provides  information on how to derive voltage and time values from the values produced by the captureADC function in the TUSS44x0_Ultrasonic.cpp file?  Thanks,

    John

  • Hi John,

    You can likely get some additional support from the MSP430 MCU E2E forum if you have questions about the internal ADC capture. Just create a new post targeting the MSP430F5529 as your device in question.

    The entire ADC capture sequence is abstracted to Energia's analogRead function, which I know runs relatively slow compared to what is possible. The C-code details of Energia's analogRead function can be found at "C:\ti\energia-1.6.10E18\hardware\energia\msp430\cores\msp430\wiring_analog.c" for reference. At line 349 of this file, I found this note regarding analogRead:

    // The below ADC configuration applies this rule to all channels right now.
    // ADC10CLK = 5MHz / 5 = 1Mhz
    // Tsample = S&H / ADC10CLK = 64 / 1 MHz = 64 us
    // Tconvert = 13 / ADC10CLK = 13 / 1 MHz = 13 us
    // Total time per sample = Tconvert + Tsample = 64 + 13 = 67 us = ~15k samples / sec

    The ADC clock and sample+hold times can be much faster when you create you custom CCS project. There may be some working high speed and resolution ADC examples at dev.ti.com in the Resource Explorer.

  • Hi Akeem, 

        After alot of research, I have a question about the EVM GUI.  I want to make sure that my code is sampling at least the same sample rate as the EVM GUI since I used the exported EVM GUI results to determine if the output XML data would meet requirements for accuracy.  The TUSS4xx0 EVM GUI users guide says on page 15, "Record - Sets the record length of the ADC in 12ms increments up to 73 ms.  The MSP430F5529 ADC captures 2048 samples over the specified record length." That's 85333 samples per second when using a 24ms record time, or 6 times more samples per second than the code you posted above.  If the input signal is around 40KHz or below, the EVM GUI meets the Nyquist sampling rate rule but does not meet it for the maximum 1MHz input signal supported by the EVM GUI.  When using an input signal above 40KHz, is the EVM GUI is still able to provide accurate results? Thanks,

    John

  • Hi John,

    Yes, the GUI is able to capture the result of transducers up to 1MHz with ~6us step resolution for a 12ms record length. In the case of a 1MHz (1us step) transducer, the waveform will definitely be under-sampled. However, even when bursting a 1MHz transducer with a single or few pulses, the amplitude of the ring decay is large enough to still create a wide-enough echo signature for the MSP430's ADC to capture. The bigger problem for a 1MHz transducer when using the EVM-GUI is that there is a delay between bursting and the ADC turning on to start sampling on the MCU. The MCU code is currently not able to both burst and sample the ADC simultaneously, so there is a bit of a blind zone created by the GUI. For 1MHz evaluation, I recommend that you first start with an external oscilloscope to monitor the VOUT pin so you can still use the GUI to configure the device, but eventually move to a high-speed ADC to capture the 1MHz results more efficiently on your own hardware solution.

  • Hi Akeem,

        I found an example in the Resource Explorer inside Code Composer Studio, "adc12_a_ex5_repeatedSingle.c" that uses 'Repeat Single Channel Mode' to automatically repeatedly trigger a new sample on the edge of the clock (see section 28.2.7.3 of the MSP430x5xx user guide) using a 5MHz clock speed. If I can determine the correct sample timing using section 28.2.5.3 of the same document, I may be able to achieve the same 170 ksps rate as the EVM GUI when it's set to record for 12ms. Another variable is calculating how much code overhead time contributes to sample time since every value in ADC12MEM0 must be immediately transferred to main memory using the interrupt handler. Thanks again for your help and advice,

    John