• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 529 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.

Original question:

BOOSTXL-PGA460: Bus demo questions

BOOSTXL-PGA460: BusDemo Example Not Working/Inconsistencies

Joseph Summers1
Prodigy 130 points
Part Number: BOOSTXL-PGA460
Other Parts Discussed in Thread: ENERGIA, PGA460, PGA460-Q1

Hello,

I am working on getting the BusDemo example sketch to work with two boards. I have followed the example video exactly, but the program only works sometimes, and if it does then it only works for the master board, despite identical setup procedures. When the distances are not correct they are the same repeating value, where the exact value repeated changes each time I start over by flashing the boards from the GUI.

The strangest part is that re-flashing the boards, applying the exact same EEPROM and other settings, then uploading the Energia sketch and choosing the exact same prompt options again might have different results. Where the previous, identical setup process might give me repeating values on both boards, the subsequent setup using identical settings will produce accurate and changing distances on the master board only. I have never gotten accurate or changing distance values on the second board.

I am using an external DC power supply in addition to the USB power, with the correct jumper setting for this standard configuration. The DC voltage is usually 14V but I have varied it between 10 and 18V for testing.

The 0-ohm resistor at R15 was NOT removed.

The power and ground pins both use the same references, and the IO, COM_S, and COM_P pins are directly connected between the boards. All wires were verified with continuity tests.

The following is my setup process, although I have tried altering all parts of it at some point to attempt to get it to work or help identify the issue, including but not limited to using the example values from the video instead of the ones I save to EEPROM from the GUI.

1) From GUI, flash one board, set up desired driving frequency, pulse count, current, TVG, and threshold settings.

2) Change from UART to OWU, selecting "No" during the prompt.

3) Set the UART address (0 for the master board, 1 for the other).

4) Click "Read All" from Memory Map and verify that the address and OWU settings are correct.

5) Save settings to EEPROM

6) Turn off DC power and remove USB.

7) Repeat the process for the other board using the same MSP430 launchpad. The only difference is the UART address.

8) Using the UART 0 board as master, reconnect power and the USB.

9) Open Energia, upload an unmodified version of the BusDemo example sketch. 

Side note that might be relevant, the serial monitor will only sometimes display the prompts after a successful upload. Many times I have to upload it 2-3 times before it will display the prompts, even with the delay before printing changed to 5000 from 1000. Selecting 1, 0, x, s, or q does not continue to the next expected prompt or begin any measurement printing, even though the burst/listen light is blinking. The serial monitor is always opened before uploading the sketch. The baud rate is always 9600 for the serial monitor and correctly selected during the prompt.

10) Once I have set all the values (I have tried default values as well as skipping to only use EEPROM values where possible), I will always get distance values of some kind to display at the expected rate.

However, as stated before, the most I've been able to hope for is that the master board (I have tried using UART1 as master and selecting 2 devices with the same results) displays correct distances that change when moving a large object back and forth in front of the transducer.

Using the default values or my own custom values from EEPROM do not affect whether the program will display the correct distances from the master board. Both types of settings will successfully work for the one board sometimes.

As stated previously, identical setups from flashing the boards to configuring settings in the serial monitor will produce different results ranging from the master board only displaying correct distances to neither board displaying the correct or changing distances.

I do NOT receive distance values of 0 for either board for any tested setting combination.

I have tried multiple MSP430 launchpads, USB cables, and default closed-top transducers that came with the boards. I have not tried a different computer, but the single board examples such as GetDistance work perfectly every time on each board, although I still sometimes have to upload it multiple times before it will start printing to the serial monitor, even with an increased delay before printing.

I apologize for the wall of text, but I wanted to provide as much detail as possible since this is a weird issue to troubleshoot.

Thank you very much for any assistance!

  • 0
    TI__Mastermind 27950 points

    Hi Joseph,

    Thanks for providing an in-depth report of your problem (usually makes my job easier!).

    Assuming both addresses are correctly programmed (UART_ADDR=0 and 1), and you are receiving different non-zero values from both devices, it does seem that communication to both devices is successful on the OWU bus. You mentioned that the GetDistance example is successful - is this in OWU mode? When running either the GetDistance or BusDemo examples, are you choosing to skip the option#4 "Transducer Settings"? If not, the UART_ADDR may be overwritten; thus, I recommend you always skip this option (input --> 'x') to use GUI programmed values.

    Ultimately, if the GUI programmed EEPROM registers are the desired settings, all you need to do in the Energia setup is write to the threshold. This is option#10 "Bulk Threshold Write" in the bus demo (input --> 'true'). All other settings should be skipped or set to false during the setup. Do not perform a bulk user EEPROM write during setup, as this will set all UART_ADDR to the same value.

    Whenever you program the LaunchPad using Energia, you may need to physically click the RST button on the LaunchPad for the COM Serial to successfully display text on the Energia serial monitor so that you don't have to re-flash the code multiple times. This serial display printing is an initial flash programming with Energia problem.

    Considering the program sometimes works on the master board, these are the items I suggest you debug:

    1. Since R15 is populated on both EVMs, jump wire the 3V3 pin from the master board to the slave board. The EVM's interface switch(TS3L501ERUAR) requires 3.3V, and may create non-deterministic behavior when floating.
    2. Is the threshold getting written to? If THR_CRC_ERR is not cleared, the device will not burst, and the ultrasonic measurement results will not update. You may need to add an additional line of code after the Energia setup but before the burst/listen looping to read back DEV_STAT0 to determine if THR_CRC_ERR is 0 or 1 when the results are dynamically correct or statically incorrect.
    3. Does removing the slave board's IO from the bus effect the success rate of the master board? If so, the slave board could be negatively loading the bus.
    4. Can you try the IO connection approach whereby you remove R15 (0Ohm) from the slave board, and jump the IO from the master to the IO SMD test point of the slave board?
    5. Instead of using the IO-OWU interface mode for the bus demo, you can also use the standard UART (TX and RX) pins to run the demo, which may be easier to debug. If this mode works for you, the issue will at least be isolated to the OWI interface/transceiver. By the way, do you ultimately intend on using UART or OWU?
    6. Have you been able to monitor the IO-OWU pin activity on an oscilloscope? Is there a difference in the response between the master and slave boards?

  • 0 in reply to Akeem Whitehead
    Prodigy 130 points

    Akeem,

    Thank you very much for the detailed feedback. After some testing using your advice, I have figured out that the issue was primarily from the THR_CRC errors, but occasionally also resetting the UART address of the slave board during the prompts if I didn't skip any of them.

    I mistakenly believed that prompt 10 in the serial monitor, Bulk Threshold Write, was overwriting my own threshold values from the GUI that are saved in EEPROM, not actually writing to the threshold registers to clear the error. I assumed that the THR_CRC errors were resolved automatically, independent of the prompt options. Kind of embarrassing that this was the issue all along. 

    One thing that complicated it for me was that in the later stages of testing, I began to use the GUI to do one burst/listen from the Data Monitor to verify that the hardware was working properly. This, of course, cleared the error for that board but reset it once I disconnected power to set up the other board -- meaning that the last board used would work properly and the other still had the THR_CRC error. Since the last board used was always used as the master, only that board would work. The other complication is that I never cleared the CRC error using prompt 10 while also keeping the UART addresses the same. All my tests either said yes to both or no to both of the prompts. So from the end it just looked like only the master board was working correctly for some weird reason. In the end, it was simply me not understanding what each prompt actually did, especially with respect to fixing the CRC errors and changing UART addresses using the serial monitor prompts. From now on I will use my own values from the GUI but clear the THR_CRC error using the Energia prompt.

    Three variables affected the outcome, but I didn't know one of them was a variable because I didn't understand what I was doing. Again, pretty embarrassing but I sincerely thank you for helping me figure it out.

    I'm guessing that the answers to your questions are now unnecessary since the problem was solved, but I do have another question about OWU vs. UART. I'm still not entirely sure what the benefits of OWU would be for my project.

    I eventually intend to use 4 PGA460's in direct-driven full-bridge mode using your BusDemo program as a base for establishing a 3D localization system. The boards will be stationary, but the small-sized target will slowly move, so I've found that using the GUI to customize the frequencies, currents, burst pulses, TVG, and threshold values using the Data Monitor to be tremendously helpful. However, I can always just set those up using UART and save them to EEPROM for each board and then switch to OWU afterwards if there is a reason to use it for the actual program execution.

    Is there any advantage for this application in using OWU over UART? I've been reading through the documentation files but I can't seem to find anything that indicates that one would perform better than the other during the actual program execution. But I'm also pretty new to this stuff so I don't know how something like, say, TCI would affect this application. I definitely appreciate any guidance in this area.

    Thank you again for all the advice and help!

  • 0 in reply to Joseph Summers1
    TI__Mastermind 27950 points

    Hi Joseph,

    No worries on missing the THR_CRC_ERR, it's usually the culprit of most user's problems. Unlike the other device settings that are in EEPROM, the threshold is actually stored in SRAM, so you are unable to save the threshold registers to the device. That is why after you power-cycle the PGA460, the THR_CRC_ERR flag is reset high, and the threshold values are initialized as random. This is also true if you plan to use the low-power mode. When you wake-up from low-power mode, the thresholds will need to be re-written.

    There is a trick to copy and paste the threhsolds to and from the USER_DATA EEPROM space. Check out the description of the "Copy to USER_DATA1-16" and "Copy from USER_DATA1-16" features in the PGA460-Q1 EVM GUI user's guide. You'll find this feature implemented as the function "void pga460::eepromThreshold(byte preset, bool saveLoad)" in the PGA460_USSC.cpp file.

    Regarding the differences between USART, OWU, and TCI:

    • The USART offers two modes of operation: asynchronous (traditional) UART and synchronous UART. Synchronous UART is similar to SPI without a chip select. In UART mode, you use the TXD and RXD pins for communication at logic level (3.3V or 5V) up to 115.2kBaud. The SPI-like mode requires TXD, RXD, and SCLK to be used for up to 8MHz operation (much faster than UART, but requires the use of an extra pin).
    • OWU and TCI are one-wire interfaces, primarily intended for automotive applications. OWU is meant to emulate the LIN automotive interface, but uses the same command set as the UART mode. One-wire interfaces are typically preferable in automotive applications to reduce the cost and weight of the cables that run throughout the car (which adds up over millions of units). TCI is a custom one-wire interface that offers a real time response of the time-of-flight activity, but requires interrupts and timers to be enabled on the microcontroller.

    For your application, I recommend that you use either of the two low logic USART modes (UART or SPI). The problem with using the OWU or TCI modes is that they are VPWR logic level, meaning logic high will be between 6-28V, so you would need a transceiver to level shift to a microcontroller compatible level if you were to build your own hardware. USART, on the otherhand, is able to connect directly to a microcontroller.

    You can run the bus demo in UART mode (sketch serial prompt #1 -->'0'). The only connection you'll need to change is remove the jumper connecting the IO-OWU pins between the two, and add a two pin jumper to connect the TXD and RXD between the master and slave boards.

  • 0 in reply to Akeem Whitehead
    Prodigy 130 points

    Akeem,

    Thank you very much! This answered all of my questions and more. I will definitely look into copying the thresholds to the EEPROM space that way.

    Regards,

    Joseph Summers