Intermittent power up fail on the BC127

[biomurph]

Every so often at start up the BC127 LEDs don't flash, indicating that it has not booted up correctly. Since this is intermittent, it seems to be a result of the power supply. There is a related issue here. The recommendation from the BC127 datasheet is on page 26 of this document.

There's room on the board to add the RC circuit in the next hardware revision.

[eyuan-creare]

Here is the boot sequence required by the BC127. Note that VReg needs pulled high 5ms after VBat goes high. RST# needs pulled high the entire time.

Datasheet

Here is what the existing code does under Tympan.h. I believe this sequence needs updated. I also recommend adding error checking, where the BT127 is reset if there is a problem (BT_nReset = LOW for >20ms). @chipaudette let me know if you want me to start a feature branch to try this out.

@biomurph: The device should power on with BT_REGEN = LOW and BT_nRESET = HIGH. Can you change the pull-down/up resistors so it starts this way?

Existing boot sequence

1. Upon setupPins(), set BT_REGEN = HIGH; wait 10ms
2. Set BT_REGEN = LOW
3. Set BT_nReset = LOW; wait 10ms
4. Set BT_nReset = HIGH
5. Configure BT_PIO0, as input

	//get the comm pins and setup the regen and reset pins
	USB_Serial = pins.getUSBSerial();
	BT_Serial = pins.getBTSerial();
	if (pins.BT_REGEN != NOT_A_FEATURE) {
		pinMode(pins.BT_REGEN,OUTPUT);digitalWrite(pins.BT_REGEN,HIGH); //pull high for normal operation
		delay(10);  digitalWrite(pins.BT_REGEN,LOW); //hold at least 5 msec, then return low

	}
	if (pins.BT_nReset != NOT_A_FEATURE) {
		pinMode(pins.BT_nReset,OUTPUT);
		digitalWrite(pins.BT_nReset,LOW);delay(10); //reset the device
		digitalWrite(pins.BT_nReset,HIGH);  //normal operation.
	}
	if (pins.BT_PIO0 != NOT_A_FEATURE) {
		pinMode(pins.BT_PIO0,INPUT);
	}

	forceBTtoDataMode(true);

As of commit: b927b227a25902c28c43c8ed1745633a7fbc59a0

Recommended boot sequence:

1. Upon setupPins(), configure BT_REGEN as input with pull-down, and BT_nReset with pull-up (or just rely on the external resistors to do this);
2. Set BT_REGEN = LOW; set BT_nReset = HIGH
3. Wait 5ms; set BT_REGEN = HIGH
4. Test communication to BC127. If it fails set BT_nReset = LOW for >20ms, then begin boot process again.

[eyuan-creare]

I would also recommend putting a scope on the BC127's VCHG during the boot up process. Look for it to dip below 3.1V. This pin is what initiates the boot sequence. This measurement will help set what the filter should be. It should be easy to tack on their recommended RC and take a measurement. This should be tested to see how low the V-Bus can go without causing a dip that restarts the BC127, during bootup and communication. This will help inform whether the buck boost is sufficient and where we should set our brown out point (if that's incorporated into the next design).
@chipaudette : Let me know if you would like me to tackle this. (Or Raistlin)

[eyuan-creare]

Quick note... Attached is the most recent technical manual for the BC127
41110693 AirPrime BC127 Product Technical Specification r2.pdf

Here are the reset conditions we are looking for. Note: you can reset, or power down the BC127 depending on how long you hold it LOW.

The AirPrime BC127 can be reset intentionally by two methods:
· Hardware reset via RST# pin
· Reset—Pull the RST# low for > 5 ms to reset the module.
· **Power down—Pull RST# low for > 2.4 s** to power down. A rising edge on VCHG
or VREGEN is required to restart the module.
· Software reset via AT command—Send the AT command RESET over the UART
interface to reset the module.

[biomurph]

@eyuan-creare
I have the VREGEN pin pulled low in the hardware.
BT_nRESET is not pulled anywhere.

I will try the latest notes on toggling the VREGEN. Good to know that the thing will power down after 2 seconds! That's convenient!

I will also watch the VCHG and compare notes.

[biomurph]

I have the reset pin for the BC127 pulled HIGH as per your suggestion.

[eyuan-creare]

@biomurph Did we address this in the design of the Rev-E, or were you considering a change in the firmware? I don't remember what we settled on for a course of action.

[biomurph]

On the Rev E, I have the BT_nRESET (RST#) pulled up with a 10K.
The Rev D does not have this pullup installed.

Both Rev E and Rev D have pull down resistors on the VREGEN pins.
This should allow for the Rev E to power up with pins pulled in the right directions.
The Rev D, however, would need some software to manipulate the RST# pin correctly.

[eyuan-creare]

Great! I'll take a look at implementing the change in firmware.

[eyuan-creare]

@chipaudette It looks like the boot sequence has been corrected. I think we can close this out.

The one caveat is that we are not filtering the power supply input to VCHG. This is the kind of thing that could cause intermitted behavior.

--short version of existing firmware booting up the BC127--
https://github.com/Tympan/Tympan_Library/blob/0247190d9da8d58e457f77e4b671b1f5fa128797/src/Tympan.cpp#L41

(Note: BT_nRESET is pulled high)
pinMode(pins.BT_REGEN,OUTPUT);digitalWrite(pins.BT_REGEN, LOW);
delay(10);
digitalWrite(pins.BT_REGEN,HIGH); //pull high for normal operation
		
delay(100);
digitalWrite(pins.BT_REGEN,LOW); //then return low
	
pinMode(pins.BT_nReset,OUTPUT);
digitalWrite(pins.BT_nReset,LOW);

delay(50);  
digitalWrite(pins.BT_nReset,HIGH);  //normal operation.

[eyuan-creare]

@chipaudette Perhaps I stumbled on something...

VREGEN not only is critical in the boot process, but it is used to put the BC127 in discoverable mode. In the current firmware, VREGEN is pulled high for 10ms to put in indiscoverable mode. However, Melody 7 states that a "short" press is 50ms, whereas we only pull it high for 10ms. Also, we pull the nRESET pin low then high after this short press of VREGEN. So perhaps this timing is preventing the BT module from being placed in discoverable mode?

Melody 7.x

In a previous Tympan commit, VREGEN is brought high for 10ms then brought low.

if (pins.BT_REGEN != NOT_A_FEATURE) {
		pinMode(pins.BT_REGEN,OUTPUT);digitalWrite(pins.BT_REGEN,HIGH); //pull high for normal operation
		delay(10);  digitalWrite(pins.BT_REGEN,LOW); //hold at least 5 msec, then return low

[eyuan-creare]

@chipaudette Also note the difference between Melody 7(above) and Melody 5 (below). The duration for a short press changed from <999ms to 50ms (probably to provide debouncing as their dev board uses a momentary switch). Also, note that a long press has a different function.

Melody 5.0 Rev-D

[eyuan-creare]

@chipaudette: so while the Medody5 boots up as a discoverable device (under default settings)...

---

Melody 7 states that it is not discoverable on bootup.

So my recommendation is to leave VREGEN high and use the BT_STATE command to make it connectable and discoverable.

[chipaudette]

@eyuan-creare thanks for the additional research on the startup process and on the GPIO.

Two observations that would be helpful for you to comment on:

• I believe that the word "Discoverable" is only meaningful for making BT Classic connections, not BLE. For BLE, it's the word "Advertising" that is relevant...and we have been explicitly enabling Advertising on the V7 units. In your discussion of short vs long pulses and their effect on Discoverable mode, do you expect your suggestions to affect my BLE connection problems or only my BT Classic (ie BT Audio) connection problems? [* See note re: BT Audio]

• For the short/long pulse discussion, the module has two GPIO control modes: (1) GPIO control "on" and (2) the badly-named GPIO control "off". [In truth, both modes still respond to the GPIO pins, they just respond in different ways.] Do your comments have to do with mode "on" or mode "off" or is it some GPIO mode specific to just the startup process?

[Note: In my recent attempts to make BT Audio function on V7, I have been using BT_STATE to make the unit discoverable for Classic (including Audio) connections. Manipulating BT_STATE does make my phone see the Tympan as a BT headset, which is great. But, when the phone starts sending audio, the Classic connections gets dumped. Every time. Makes me sad. Perhaps, though, my VREGEN is not in the right state and needs to be done better for V7 units? @ijenkins-creare , please note!]

[chipaudette]

@eyuan-creare In your comments above, you suggested that we have VREGEN be held low instead of our previous pattern of holding it high. I've now explored this.

On RevE with V7.3 HD firmware, I switched the code to keep holding the pin HIGH. There's no obvious difference in behavior either way. I command BT Classic behavior ("connectable" and "discoverable") through direct serial commands, as you suggested. The system seems fine...but, again, it's not obviously better either way. My conclusion: Whenever V7 firmware is specified, I have Tympan.h hold the pin HIGH forever, per your recommendation.

On RevD with V5.5 firmware, when I switched the code to keep holding VREGEN high, the module shuts off after ~2 seconds. Obviously, this is bad. My conclusion: Whenever V5 firmware is specified, I have Tympan.h return to the original behavior of staying HIGH for 100 msec and then switching LOW and staying LOW forever.

[eyuan-creare]

On RevD with V5.5 firmware, when I switched the code to keep holding VREGEN high, >>the module shuts off after ~2 seconds.

Yes that is expected behavior. It is supposed to SET CLASSIC_ROLE=1, SET AUTOCONN=1, then reset. I assume those are non-volatile and when it boots up again it should be held high. We might want to revert a Tympan to default settings if we think a "new" Tympan might act differently.

Otherwise I can close this out. The last remaining question is whether there is noise on the VBAT or VCHG supply lines that could cause an issue during startup.