BQ76PL455A-Q1: Auto-Addressing procedure does not always work

Hi Lukasz,

Can you describe your setup? Are you using the EVM and GUI to communicate to the stack or custom hw/sw?

Can you measure the waveform for the wake tone to the second device and see if it matches the datasheet criteria?

Regards,

Taylor

Hi Taylor, thank you for the answer.

I am using both custom HW and SW on the master side. For your request I will need a while to hook up the scope- I understand you need me to attach the probes at the input of the second device (between the caps and the IC pins)?

In the meanwhile, I have noticed the following: So far I have been always recognizing 2 devices correctly after removing this step:

"1.2.5 Disable High-Side Receiver on Differential Interface on Top of Stack".

This I have checked on the scope and the data I send is the same as in the given example:

In theory, it should disable the high side interface for the second slave. Since nothing is behind it, there should be no issues...

I will come back with the waveforms once I setup them.

Hi Lukasz,

Can you clarify - why do you wish to disable the high side communications if you are having issues?

Regards,

Taylor

Hi Taylor,

I am disaing the high side comm in the top module just because it is suggested in the doc. I have noticed that this step is causing issues only later.

Hi Lukasz,

Ok, in that case ensure you are disabling the topmost device rather than one in the middle which could cause an issue.

Regards,

Taylor

This is something I though maybe happened. I have 2 slaves connected, my by error during the development it was only the 1st one who was discovered and the high side communication was disabled for him. For a while now I have added a routine that disables the high side communication in the last slave only, if the discovered amount of slaves is equal to the expected one. During 2 days of tests, I have not experienced invalid discovery issues, so it must be related.

In practice, what does one have to do (besides power recycle, so the whole battery pack disconnection) to reset a device, that cannot be communicated? Also, is the BQ device being reset after it falls asleep? It would be a useful functionality if the device could reset itself or fall asleep (if it resets itself then) after programmed amount of time without communication (i.e. 1 second).

Hi Taylor, thanks for the answer. So if I understood correctly, before the auto address procedure starts, I should broadcast a COMM_CLEAR setting in the STATUS register?

Also, regarding the CTO register and COMM_PD_PER bits- that's exactly what I needed!