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: Intial communication not working

Part Number: PGA460

Team,

at the start the attached INIT sequence is sent, which should put the PGA460 into UART Mode:  0xF0, 0xF8, 0xFC:

The violet trace in the plots is what the PGA 'sees'. Due to the hardware set-up we have the TX/RX lines appear inverted

As a 2nd step I am cyclically sending the command 0x06, which the PGA460 should respond to with 2 Bytes of data: 0x55, 0x06 (Command 6), 0xF9 (Checksumme).

 

UART: 19200Bit/s, 2 Stop Bit, TX/RX inverse (due to the hardware set-up), 1 Start Bit

 

Could you please assist in the debugging, so I can get the communication with the PGA460 working.

Best regards

Frank

  • Dear team,

    here'san update. The initial sequence with oxF0, 0xF8 and 0xFC is the same. We found an error within the command 0x06. If the PGA460 responds it is sufficient to send only two bytes (0x55, 0x06), Attached is the sequence. the PGA460 should reply with 2 data bytes and the checksum byte. This is curently not working.

    Channel represents the IO pin on the PGA460.

    Best regards,

    Jochen

  • Hi Jochen and Winnie,

    Thank you for posting to the Sensors forum!

    I will need some time to look into this and will aim to provide a response by the middle of next week.

    Best,

    ~Alicia

  • Hello Alicia,

    are you able to have a look on that topic today? This is really urgent.

    Best regards,

    Jochen

  • Hi Jochen,

    Looking at your UART signals, it seems as though you are only probing the Tx signal and not the Rx signal as your Rx signal seems to be a mirror of your Tx signal. The image below shows an example of what your Tx and Rx communication lines should look like.

    Best,

    ~Alicia

  • Hello Alicia,

    I have now attached the schematics of 1 channel. We use RX and TX on a UART interface of the microcontroller.

    As you see the RX line reads directly back the TX data. We use the IO interface on the PGA460. I still got no response from the PGA460.

    You see the IO pin in the oscilloscope plots with the label PGA. This a 12V referenced signal.

    We should discuss:

    1. Is the pattern 0xF0, 0xF8, 0xFC correct to set the PGA460 in the UART mode?

    2. What is currently wrong in the communication with the PGA460?

    Best regards,

    Jochen

  • Hi Jochen,

    Is the pattern 0xF0, 0xF8, 0xFC correct to set the PGA460 in the UART mode?

    The pattern above is correct. Is it possible to collect the timing information for the capture in your initial post of the above sequence?

    Best,

    ~Alicia

  • Hi Alicia,

    the pattern 0xF0, 0xF8, 0xFC fits perfect to the required timing, see attached plot.

    Still I don't have a response from the PGA460. In a second frame I write 0x80 in the register adress 0x1E (P1).

    But without any effect. Do you have any idea?

    Best regards,

    Jochen

  • Hi Jochen,

    As a sanity check, would it be possible for you to communicate to the device via the PGA460's Tx and Rx pins instead of the IO pin just to make sure that the device is responding to commands?

    Best,

    ~Alicia

  • Hello Alicia,

    we have 5 sensors which are all working. We use for the debugging purposes the BOOSTXL-PGA460.

    Are you able to build up a similar system? It seens that the GUI in ervery 5th or 10th attempt enters the OWU mode.

    If I record 20s of the communication after the GUI reinitializes to OWU I can see that the controller sends a lot of data but the PGA460 does not respond. If the PGA responds it is simply not possible to trigger on the event when the PGA starts to respond.

    I have cheked the sourcecode of the EVM. We do now the same.

    1. Pattern 0xF0, 0F8, 0xFC

    2. 0x55, 0x0A, 0x1E, 0x80, CS

    3. Read any register

    Still we get no answer fromt the PGA460.

    Is it pssible to organize an online meeting on next Wednesday?

    Best regards,

    Jochen

  • Hi Jochen,

    I am working to try to replicate what you are seeing. To clarify, when you mention that you are not able to trigger on the event when the PGA responds, this is with reference to getting a waveform capture, correct? Could you share the results/screenshots that you are seeing from the GUI?

    Best,

    ~Alicia

  • tek0000CH1.csv

    Hi Alicia,

    I am not sure if the csv file is helpful. This was a positive atempt to communicate witht the PG460 by OWU. Please come back to me if you the data in any other format.

    Best regards,

    Jochen

  • HI Jochen,

    Thank you for the data. Would you be able to send similar data for a failed communication attempt?

    I have a few questions regarding your system. You mentioned having 5 sensors, are the sensors all on the same OWU communication bus, or are they separate? Would you be able to share a block diagram of this? Do each of the sensors, if using multiple, have their own unique address?

    Best,

    ~Alicia

  • Hello Alicia,

    yes, all of the sensors are of the same type. We use a 4 channel PCB, see attached picture.

    For debugging purposes we use the BoostXL-PGA460 EVM.

    You see in the captured data that the controllers tries to establish a communication in the first few seconds without any response of the PGA460. Later in the captured data the communications seems to work. I still do not know if the cause for that is a magic pattern.

    Best r  egards,

    Jochen

  • Hi Jochen,

    yes, all of the sensors are of the same type. We use a 4 channel PCB, see attached picture.

    Based on this statement, it seems as though you are having a similar problem to what was described in the following E2E thread: PGA460-Q1: I/O communication issue with 5 sensors. The issue described comes from using OWU on the IO pin of the PGA460 when the pin is connected to multiple different PGA460 devices. The reason being that all of the sensors on the OWU bus recognize the command given as valid and attempt to respond which can cause them to not respond at all.

    Assuming that this is the issue you are observing, the following workaround may be able to help solve the problem:

    1. Send a single address One-Wire UART (OWU) command to change the targeted PGA460 into TCI mode.
    2. Broadcast the IO toggle pattern (see Section 7.3.6.3 of the datasheet for details) to switch the non-targeted PGA460s from OWU and TCI mode (and the targeted PGA460 from TCI to OWU). This would then allow the targeted PGA460 to receive and respond with whatever OWU data, and the non-targeted PGA460s would ignore the OWU data because they’d be in TCI mode.
    3. Send the desired communication packet that is intended for the targeted PGA460.
    4. After the exchange is done with the targeted PGA460, send that device a OWU command to change into TCI mode. By doing this, all the devices would now be in TCI mode.
    5. Broadcast the IO toggle pattern to switch all the devices to OWU mode.

    Best,

    ~Alicia

  • Hi Alicia,

    you can close the case. The system works now. Many thanks for the perfect support!

    Best regards,

    Jochen

  • Hi Jochen,

    I am glad your system is working now, I will go ahead and mark this thread as closed. 

    Best,

    ~Alicia