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-PGA460: GetDistance Energia program working only after use with the PGA460-Q1 EVM GUI

Part Number: BOOSTXL-PGA460
Other Parts Discussed in Thread: PGA460-Q1, ENERGIA, PGA460,

I seem to have an issue with what I think is the THR_CRC_ERR.

My hardware setup is as follows:

The BOOSTX:-PGA460 EVM attached over the MSP430F5529LP launchpad. The muRata transducer is mounted on a foam support. 

To use the setup with the PGA460-Q1 EVM GUI provided by TI, I first upload the "boostxlpga460-firmware.bat" file. The setup works flawlessly. I usually program my own threshold values on the Device Setttings>>Threshold tab. Thus, the GUI shows the THR_CRC_ERR to be cleared.

When I attempt to use the same setup with the GetDistance Energia program (immediately after using it with the GUI with the GetDistance code uploaded), I have no issues. The settings I program through the serial monitor are as follows:

1. Communication Mode: 0=UART, 1=TCI, 2=OneWireUART ... 0

2. UART kBaud: 0=9.6, 1=19.2, 2=38.4, 3=57.6, 4=74.8, 5=115.2 ... 0 

3. P1 and P2 Thresholds: 0=%25, 1=50%, or 2=75% of max ... 1

4. Transducer Settings: 0=Murata MA58MF14-7N, 1=Murata MA40H1S-R, x=Skip ... 0

5. TVG Range: 0=32-64dB, 1=46-78dB, 2=52-84dB, or 3=58-90dB, x=Skip ... 3

6. Fixed TVG Level: 0=%25, 1=50%, or 2=75% of max, x=Skip ... 1

7. Minimum Distance = 0.1m * BYTE ... 1

8. Run System Diagnostics?: 0=No, 1=Yes ... 1

9. Echo Data Dump: 0=None, 1=P1BL, 2=P2BL, 3=P1LO, 4=P2LO,... 1

10. Burn User EEPROM?: 0=No, 1=Yes ... 1

11. Command Cycle Delay: 10ms * BYTE ... 9

12. Number of Objects to Detect (1-8) = BYTE ... 1 

13. UART Address of PGA460 (0-7) = BYTE ... 4

System Diagnostics displayed on serial monitor is as follows:

Configuring the PGA460 with the selected settings. Wait...
System Diagnostics - Frequency (kHz): 8.77
System Diagnostics - Decay Period (us): 1632.00
System Diagnostics - Die Temperature (C): 29.33
System Diagnostics - Noise Level: 4.00
EEPROM programmed successfully.

The values that display following this correspond pretty close to the expected distance values. And so everything works fine (as long as the procedure followed is as explained above).

The real issue starts when I disconnect and reconnect the setup (restarting the device through USB port power). The serial monitor shows everything going fine until user input part is over. After that, the System Diagnostics is shown as follows:

Configuring the PGA460 with the selected settings. Wait...
System Diagnostics - Frequency (kHz): 8.93
System Diagnostics - Decay Period (us): 560.00
System Diagnostics - Die Temperature (C): 28.00
System Diagnostics - Noise Level: 3.00
EEPROM programmed successfully.

I noticed a consistent Decay Period (us) difference between the two procedures. And the object distance shows a constant erroneous value of 5.98 m.

To get it back to work, I am required to cycle back to the first procedure of uploading the firmware using the GUI.

I also discovered that during this procedure, to quicken the process, on GUI restart (as it usually prompts after firmware upload) I only have to hit the All Mid-Code option on the Device Settings>>Threshold tab to clear the THR_CRC_ERR. After that, I then re upload the GetDistance code (WITHOUT DISCONNECTING the setup) and then it all works properly again with the right distance values being displayed. This leads me to believe that this behavior might be associated to the THR_CRC_ERR and the subsequent Px_THR_y threshold registers as that is the only thing that gets manipulated as I click on the All Mid-Code button on the GUI.

I need to be able to power down and power up the setup and obtain correct values after. I can only vaguely guess that the problem is to do with the Thresholds.

  • Hi Kevin,

    Can you confirm that your PGA460's UART_ADDR power-up with a value of 0x4 when using the GUI? This may be where your issue stems from.

    Keep in mind that line item 4 from the COM terminal prompt for the Transducer Settings is a EEPROM bulk write command. This command includes an update of the UART_ADDR value. The value of PULSE_P2 is currently hard-coded in the PGA460_USSC.cpp file's void pga460::defaultPGA460(byte xdcr) function case 0 as PULSE_P2 = 0x10, which is UART_ADDR = 000b.

    Try one of three corrective actions:
    1) When prompted for the transducer setting, enter a value of 'x' to skip this line item's command configuration. The device will use the user settings loaded from EEPROM upon power-up. I recommend this approach if you have already configured your device settings with the GUI. Otherwise, this command from the Energia sketch will override your previous settings.
    2) Use the GUI to set your device to UART_ADDR = 0, then flash the 'F5529LP with the Energia project, and always use address 0 when prompted.
    3) Update the PGA460_USSC.cpp file's void pga460::defaultPGA460(byte xdcr) function so that case 0 (for Murata MA58MF14-7N) PULSE_P2 = 100xxxxxb to force address 4.

    If one of these resolves your issue, then I can consider adding an additional prompt for the user to update the value of PULSE_P2 if the Transducer Selection is not skipped. This will ensure the device is updated to the same or different value as intended.
    The problem with a use case such as yours is that the device starts in UART_ADDR=4, and is updated the UART_ADDR=0 when using the bulk EEPROM write command with hardcoded values. Thus, all subsequent commands become invalid since the device now expects UART_ADDR=0.
  • Hey Thanks! It works now. I only had to skip the transducer settings and retain the UART_ADDR as 0. I would like help with the following also:

    1. During usage of the BOOSTXL-PGA460 EVM with the F5529LP in the setup as explained above, can you confirm if the following pins are the only ones in use? If I have missed out any, please mention. I would like to build a shield over this and so require a list of unused pins (wrt F5529LP Launchpad) so that I dont disturb any of the internal electronics or communication.

    TX(1) - P3_3, RX(1) - P3_4 for UART comunication with the EVM
    TXD - P4_4, RXD - P4_5 for Serial communication
    SCK(1) - P4_3 for UART voltage level determination
    P1_1 for PUSH2, P_1 for PUSH1, P1_0 for LED1 and P4_7 for LED2

    2. In the system diagnostics reply on the Serial monitor, what does the frequency part signify? Is it the frequency of the signal used to excite the transducer?
  • Hi Kevin,

    1. I am highlighting the pins that are required for USART (UART or SPI) operation of the BOOSTXL-PGA460 in Energia:

    // Pin mapping of BOOSTXL-PGA460 to LaunchPad by pin name
    #define DECPL_A 2
    #define RXD_LP 3
    #define TXD_LP 4
    #define DECPL_D 5
    #define TEST_A 6
    #define TCI_CLK 7
    #define TEST_D 8
    #define MEM_SOMI 9
    #define MEM_SIMO 10
    #define TCI_RX 14
    #define TCI_TX 15
    #define COM_SEL 17
    #define COM_PD 18
    #define SPI_CS 33
    #define SCLK_CLK 34
    #define MEM_HOLD 36
    #define MEM_CS 37
    #define DS1_LED 38
    #define F_DIAG_LED 39
    #define V_DIAG_LED 40

    The other pins can be shared with another BoosterPack.

    2. During the decay stage of the record interval, a frequency measurement on the transducer node is performed to validate the performance and proper tuning of the transformer and transducer matching. The system diagnostics should be very close to the FREQ value used to drive and center the DSP. Based on the values from your last post, you may not have the frequency diagnostic feature enabled. When FDIAG_LEN is 0h, the frequency diagnostic feature is disabled, and the reported value will be invalid.