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.

PGA460: PCB

Part Number: PGA460

Hello,

My team and I have the evaluation module/GUI application and it works great as expected. Now, I'm struggling with the code for our own custom board. Before receiving our PCBA we put together the intended circuit and thresholds on the breadboard, and were able to dial it in to match our needs. I've been using the Arduino code as reference, but our custom board uses a Kinetis MCU. We are using UART (with 2 stop bits) as our communication method, 5V logic from the MCU, pulling the TEST pin to 5V through a resistor to match. 

For testing, I've been writing the thresholds, delay, write to EEPROM, delay, writing 1 burst and 1 listen, delay, and then using the UMR command to retrieve the distance. It always returns the following no matter the circumstance: 

44 01 11 11 11 87

Here's a sample of my output from the Kinetis to the PGA460:

55 10 01 11 11 11 11 11 FC 5A A4 1C E7 38 38 38 38 00 01 11 11 11 11 11 FC 5A A4 1C E7 38 38 38 38 00 81

55 0C 01 11 11 11 11 11 FC 5A A4 1C E7 38 38 38 38 00 00 00 00 00 22 22 22 4D 94 4B 00 C0 32 00 04 04 72 FF 0C 11 22 69 CA 00 00 00 00 48

55 00 01 FE

55 05 FA

Running this will only work without UMR request:

{ 0x55, 0x09, 0x1B, 0xDB}

But returns:

44 C0 FA

Should it be returning a 0x40 instead of 0x44?

 

  • Hi Nicholas

    We have received your question. Due to holidays our responses will be delayed. The subject matter expert will get back to you after a week.

    Regards
    Vaibhav
  • Hi Nicholas,

    The first return byte from the PGA460 is always the diagnostic field. Assuming UART_DIAG=0 for UART diagnostic mode, the device should return a value of 0x40 to indicate there is no UART communication issue (see table 4. UART Diagnostic Data Descrption of the datasheet for details on the diagnostic field bit descriptors). In your case, a diagnostic field value of 0x44 indicates your have an error of: "Consecutive sync field bit widths do not match".

    Your command execution flow is correct, and your checksums are valid, so I suspect this issue due to the UART configuration and/or timing.
    • What UART buad rate are you using (PGA460 accepts 2.4k-115.2kBaud)?
    • How long of a delay are you waiting between commands? Just for debug purposes, can you increase the delay to a value of extreme margin (i.e. 100ms) between each command?
    • Can you confirm that the THR_CRC_ERR bit is cleared (register read DEV_STAT0) to ensure the threshold was successfully written to? You can also probe the transducer's positive terminal to determine if it is bursting when you send the burst/listen command.
  • Akeem,

    Thanks for getting back to me so quickly and thank you for the datasheet reference.

    - I am using a baudrate of 115200
    - Testing using a 500ms delay between commands
    - The THR_CRC_ERR bit is not cleared. It returns "44 84 37" after requesting a register read.
    - I connected the oscilloscope to the transducer, per your suggestion. I set it to trigger mode, and nothing happens after a burst command.
  • Hi Nicholas,

    When the THR_CRC_ERR is not cleared, the driver output is disabled, and the PGA460 will not allow a burst command to execute. This is why your UMR is not updating.

    The PGA460 cannot properly handle your UART configuration as-is, or at least when a UART command has a large number of bytes (i.e. bulk threshold write), which is why your THR_CRC_ERR is not clearing. When probing the Rx pin of the PGA460 during the bulk thr write cmd, how does the timing and inter-field wait time length compare to the EVM-GUI's bulk thr write cmd? I have not worked with the Kinetis MCU, so I don't know if its 2-stop bit configuration is sufficient in timing. You may need to manually add delay between each UART byte transmitted to emulate the proper inter field wait time.

    In the meanwhile, a temporary workaround is to perform single register write of each threshold byte to clear the THR_CRC_ERR and test performance.
  • Okay Akeem,

    I was able to figure out that the buffer was "overflowing". The last byte would always fall off the stream and attach to the beginning of the next message, if there was one. I added a slight delay per byte, like you mentioned and it seemed to negate some of the issue. I am now able to write the thresholds with a {0x40, 0x80, chksum } DEV_STAT0 response. I did notice that I receive a 0x44 diagnostic attached to any command (with the correct data) following a UMR command. I think this will work for now though.

    Thank you for your help!