• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 196 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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:

BQ79616-Q1: EMI problem on daisy chain communication

BQ79616-Q1: Sleep2Active tone not working

Guillaume Degroote
Prodigy 90 points
Part Number: BQ79616-Q1
Other Parts Discussed in Thread: BQ79616

Hi,

I am trying to implement the sleep to active ping. but it doesn't seem to work, it shows some weird behavior. I use a ring architecture with heardbeat and fault tone. I already checked and this works perfectly in sleep (no fault tone in sleep only when fault happens). Now I masked the FAULT_COMM1 to avoid that the fault pin would get low when sleep to active tone is detected. But still with  275us Tx pin low and the dummy read writes the OTP_ECC_DATAIN1 register. The fault pin gets low and i am not able to do any reads, so i can't read the fault registers (looks like it still is in sleep but puts the fault pin low). Is this a know issue is there a solution?

  • 0
    TI__Intellectual 2710 points

    Hi Guillaume,

    How does your system look like? You say that you are using ring architecture does that mean that you have multiple BQ79616 devices? Do you also use a BQ79600 device as a base device?

    When you issue a Sleep2Active this will only wake up the device that is considered base (the device that you are talking through UART with). In order to wake all other devices you need to do a register write to register CONTROL1 bit SEND_SLPTOACT (register 0x0309, data 0x10).

    If you can please measure the supply current to each device, you can see that when entering SLEEP mode the current of the devices will go lower when in sleep mode and also higher when back in active mode.

    Regards,

    Viktor.

  • 0 in reply to Viktor Tasevski
    Prodigy 90 points

    Hi thank you for the response.

    I indeed use multiple devices but as base device i use another BQ79616. 

    I will try that and let you know. But do you recommend then doing a single write/read on OTP_ECC_DATAIN1 (Sync to dll) to the base device after the SLEEP2ACTIVE and then again a broadcast the write/read on OTP_ECC_DATAIN1 (Sync to dll) after you write to CONTROL1?

  • 0 in reply to Guillaume Degroote
    TI__Intellectual 2710 points

    Once you wake up all devices, you can do a Sync to dll.

    Regards,

    Viktor.

  • 0 in reply to Viktor Tasevski
    Prodigy 90 points

    I had the time to test it. But no luck. I checked the current and it drops when in sleep en goes back up when out of sleep. But still, when I try sleep to active my nfault pin goes low and The data I get when i try to read fault/voltage registers is not right anymore. So i am still able to read frames but the data i receive is not correct. I also tested with not writing the control1 0x10 on just sending the ping and that also puts all the devices out of sleep but the same as with sending the tone + sending control1 to the stack.

  • 0 in reply to Guillaume Degroote
    TI__Intellectual 2710 points

    Hi Guillaume,

    I still don't understand why do you loose communication to the device after you exit sleep mode. I just tried your configuration here on an EVM and was able to enter / exit sleep mode correctly and communicate afterwards.

    In my case, the NFAULT pin went low while in sleep mode, because I have HB_EN = 1 but no heartbeat pulses on the daisy-chain interface. When I issue sleep2active I go to the fault registers and read the following faults:

    - HB_FAIL - due to missing heartbeat while in sleep

    - COMMCLR_DET - This one is normal and it will always be set when exiting sleep mode. I am assuming that this is what is triggering your NFAULT pin. The reason why this fault is getting set is because the sleep2active ping is longer than the COMM CLR ping in time, therefore both are being detected. This is described in the device datasheet under the "COMM CLEAR" chapter.

    Please keep in mind that when sleep2active signal is detected the device requires 230us in order to recover from sleep and get ready to accept commands. I wonder if you have a race condition where you send the communication frames too soon after issuing a sleep2active ping.

    Can you please try to issue a COMM CLEAR ping after you recover from sleep mode and see if this recovers your data communication.

    Regards,

    Viktor.

  • 0 in reply to Viktor Tasevski
    Prodigy 90 points

    I solved the issue. i played around with the timeout when reading the otc_ECC_DATAIN and it worked suddenly.