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-Q1: UART Diagnostic Data , diagnostics byte which should by 0x40. When the problem occurs, I get 0x4B (0b0100’1011) instead

Part Number: PGA460-Q1
Other Parts Discussed in Thread: PGA460
  • When I try to read the distance, I occasionally get a “device busy” diagnostic message.
  • The issue happens sometimes after 5s but that time can be a lot longer. When the issue happens, I get either 1 or 2 of those “device busy” messages shorty after one another.
  • The issue seems to be completely random.

Technically this is about the diagnostics byte which should by 0x40. When the problem occurs, I get 0x4B (0b0100’1011) instead:

I don’t know how to interpret the value 0x4B. It tells me that the device is busy but at the same time it tells me that the baud rate is too high (which it isn’t – I am using 57600) and also that the checksum from the master is wrong (which is not possible because I use the exact same code every time I initiate a read).

The sequence is as follows:

  1. Do the initialisation
  2. Loop:
    1. Wait 100ms
    2. Send command 0x00: Burst and listen (Preset1)
    3. Wait 500ms
    4. Send command 0x05: Ultrasonic measurement result
    5. Read response  à This is where I occasionally get diagnostic code 0x4B instead of 0x40
    6. Back to a.)

What I want to know is quite simply what diagnostic code 0x4B really means. Is the device busy or is it a sync field issue or is it a checksum issue? If the device is busy – why is it busy considering above very defensive timing.

  • Hi Pejman,

     As you mentioned, I would expect Table 4 in the datasheet to tell you the status of the diagnostic field.

    Can you try the following:

    • Just to make sure, can you tell me the value of the UART_DIAG bit within the PULSE_P1 register?
    • For the packets that have this diagnostic field issue, can you verify that the received checksum from the PGA460 matches the expected checksum value of the packet?
    • Can you provide a logic analyzer output screenshot that shows when this issue occurs?

    Thank you,

    Mekre

  • UART_DIAG bit within the PULSE_P1 register is 1, The byte is 0x4B.

    I changed the baud rate to 57600 and I do no get any error, any explanation?

    I do not have a logic analyzer, problem is that the error is reported on the next read from PGA460. I trigger when the error is reported on the next read. 

  • Hi Pejman,

    At higher baud rates, you can be more likely to get transmit and receive errors.  As an example, here is a snippet from a microcontroller user’s guide that shows how the UART TX and RX errors can increase at higher baud rates for that specific microcontroller family:

    Regards,

    Mekre

  • This is the snapshots using logic analyzer. The start bit from PGA460 is too short.. Diagnostics byte is always read as 0x40 by logic analyzer. I think the microcontroller I use has problem detecting this narrow start bit. Why the pulse width of PGA460 is too narrow? Why it does not keep its TXD line at logic one level so the start bit at the start of transmission could be detected properly by the master? 

    My question is "how to configure PGA460 to keep its UART TXD "High" when it is in idle mode? 

  • Hi Pejman,

    It is possible for the PGA460's TXD pin to not be idled high prior to returning data, as is mentioned in the bottom of the below thread:

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/783905/boostxl-pga460-diag-byte-value-always-0x44-as-first-read/2904551

    Can you try adding a pull-up resistor on the TXD pin to see if it makes a difference?

    Thank you,

    Mekre

  • Hi Mekre, thank you. I did pull up the TXD yesterday with 10K and it fixed the issue. Your suggestion is absolutely correct.  As the TXD is 'low' in idle, when PG460 sends data and communication starts, there is a very narrow pulse which the master  cannot see as a start bit. When the controller communicates at higher baud rate, it seems it can see the transition as it is prepared for sampling the line for start bit faster.  After 0x40 , the next byte is 0x19, if controller does not see the start bit, it sees the transition at 8th bit of 0x40 as the start bit.  00000010. The next byte is 0x19 -10011000. There are two stop bits from PGA . So the sequence is 0000001011010011000. What the master sees is 11010011 or 0xEB instead of 0x40.