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.

BQ79606A-Q1: BQ doesn't respond to SleepToActive signal

Expert 2025 points
Part Number: BQ79606A-Q1

I'm struggling to wake up the Bq chip after putting it into the Sleep state using GOTO_SLEEP command through CONTROL1.

It falls a sleep Ok (verified as it stops responding after the command), but it doesn't seem to come out of it using the process described for SLEEPtoACTIVE transition by holding the Bq' RX line low for specified time. (And the line is correct as I'm otherwise communicating fine with it).

Essentially, using sample code, or my own,  I don't get any replies from it after holding the RX line low for specified time, and , then only way I can wake it up / restore comm is by full wake up using WAKEUP line (which is destructive to the pre-configured settings, which I want to avoid).

I also make sure I write COMM_TO  just in case, I tested either completely settings all timeouts to 0 (no timeout), or  short time out  = 1 min and long to 1 hour before putting it to sleep.  Still same result.

The sample code to wake it up ( from the TI's provided sample code ) is essentially this:

void CommSleepToWake(void) {
	scilinREG->GCR1 &= ~(1U << 7U); // put SCI into reset
	scilinREG->PIO0 &= ~(1U << 2U); // disable transmit function - now a GPIO
	scilinREG->PIO3 &= ~(1U << 2U); // set output to low

	delayus(250); // 250us to 300us, same as wake
	sciInit();
	sciSetBaudrate(scilinREG, BAUDRATE);
}

Just to make clear, this is the full wake up method (excluding my custom init params after that ..) which does bring it back online :

void Wake79606() {
	// toggle wake signal
	gioSetBit(gioPORTA, 0, 0); // assert wake (active low)
	delayus(250); //250us to 300us
	gioToggleBit(gioPORTA, 0); // deassert wake

	//tSU(WAKE) transition time from shutdown to active - 7ms from wake receive to wake propagate for each device
	sleepms(8);
}

Any hints as to why this doesn't work ?  Or what am I missing?  I'm testing it's awake by trying few times read a register back (like DEV STAT or CONTROL1) which fails with just sleep to active method.

  • Hi vo1d,

    Can you please take sleep2active UART RX/TX waveform/logic analyzer that you generate from base device? How do you determine that the device does not recover to active mode? What command you send (and how long do you wait) after sending sleep2active commands? Can you monitor current consumed by devices to determine sleep vs active modes.

    Thanks,

    Taylor

  • Hello Taylor,

    Thank you very much for reply and the suggested troubleshooting steps.    ( I just thought about logic analyzer before reading this..)

    How I determine it doesn't recover : I try to read a register , specifically CONTROL2 one, right after the sleep to active procedure. I do it 3 times, then fail. I tried another register too, DEV_STAT.

    I will do more debugging / troubleshooting as per your suggestion, in particular try see the current consumed.

    I will report back with results.

  • Hi vo1d,

    Ok thank you, please post here when you have results.

    Taylor

  • Hello Taylor,

    It seems, reading documentation & putting it together from various pages was the issue. I think my problem was wrong delay.

    Sec 8.5.1.1.1.5, p50 :

    ..." ...Holding the RX line of the base device low for more than tUART(RST) will also cause the base to send Sleep to active tones and Communications clear (break). The sleep to active and communication clear are inclusive in the communication reset. "

    So I went by this, holding a generous amount, but, from the table with actual numbers on Timing Requirements, p16 :

    Actually the other way around, reset is the longer delay .

    I fixed that to hold just under 300 uS, and the device comes back, and I can talk to it as before.

    I see about 5mA difference between when I put it to sleep, and after doing sleep-to-active.

    Now, why I can't speak to with with longer timeout must be the baudrate difference, after comm reset which always resets it to default on Bq, and that most likely doens't match mine  That is something I will fix next when needed.

    It seems,  it's all good, I will test a bit more.

  • Hi vo1d,

    Glad to hear it, if you dont have a new issue arrive in the next couple days - can you please resolve this issue and open a new thread if something comes up down the line? 

    Thanks,

    Taylor

  • Thank you for help.

  • Hello,

    I'm going to close this thread. Feel free to create a new thread if you need further support.

    Best regards,

    Leslie