Acer battery clear pf flag using raspberry pi

[Smb]

Hello everyone,

I changed the 5v  powersupply ic on a dead Acer laptop, works fine now but doesnt charge.

The guy I got it from  thought the battery ( Ac14B18J ) dead so purchased new battery. Both the original good and new battery sat a bit without getting charged.

Boosted the cells to the rated voltage still not taking charge.
 I guess the permanent failure flag is  set by the Bms.

Came across a post here by  mefistotelis where he communicates with i2c with the bms.


https://github.com/o-gs/dji-firmware-tools

Sure enough his amazing tools worked on the aftermarket battery but it is lacking support for the chip in the battery pack which is a sn8765 seems to use BQ3050 as a base device.

I used the bq30z544.py
Some commands work  like device info.
Gives correct info.

But manufactureraccess does not give me anything.
After comparing the technical reference  of the bq3050
https://www.ti.com/lit/ug/sluu485a/sluu485a.pdf?ts=1616851769302
and bq30z554
https://www.ti.com/lit/ug/sluua79/sluua79.pdf?ts=1616950132055&ref_url=https%253A%252F%252Fwww.google.com%252F
 seem to use the same address for the pf status  0x53 and manufacturer access 0x00

Some of the sub commands are different but those that are the same should give a correct response no?
But all the polls are returning the same response .

Does anyone know how to fix the manufacturer access command ?
Also the technical ref of the bq3050 doesnt mention a unseal command address only a seal vommand address while the bq30z554 does.

Surely I could just get a new battery but things that could be solved easy a few years ago now are locked down, plus I got a new battery here which just sat for a bit and now needt to be dumped on the landfill for 200 years.

Thanks a bunch for the legend who knows this.

[mefistotelis]

BQ3050 reference:

The results of these commands need to be read from ManufacturerAccess after a write with the command
word to ManufacturerAccess.

BQ30z554 ref doesn't explain things that clearly, but description of each command follows the same scheme:

0x0001 to ManufacturerAccess()
Returns the IC part number on subsequent read on ManufacturerData()

0x0002 to ManufacturerAccess()
Returns the firmware revision on ManufacturerData()

So in Python terms, you need to update 'resp_location' in the definitions of MA commands.

Also, the way of clearing PF flags is different for that chip, so you'll have to read that part of the spec as well.

[Smb]

Thanks a lot for replying,

I updated resp location to sbs_command.manufactureraccess that gives a bunch of pec checksum errors.

Reading the spec it says on the 3050 the pec is turned off by default.
No idea where the operation cfg register is so ican set that hpf flag.
Also not sure if it is because of the pec or the responses im getting are wrong because i set it to the wrong location.

At least the data is different for each command. From what i get it should be 2 bytes .
On pf status i get 00 00 cd cd cd cd as response seems not 2 bytes.

I only have a little time after work to do this but wish to understand it so i will try and update this post with my progress so it can maybe be a reference forsomeone else even if i fail which is likely given my current state of understanding. Cheers.

[mefistotelis]

When data ends and you continue reading, you get the last byte (usually PEC) repeated.

[Smb]

After looking at it some more I didn’t manage to figure it out.

Tried to change expect_len in smbus_read_block_for_basecmd
Tried turning off pec by setting  bus.pec to 0

Commented out pec valueerror

Tried raw read and raw write which also didn’t give me anything
Tried hex to ascii hex to binary on the responses
Tried changing the

BqstatusbitsMa have 0x07 as address maybe that is also wrong for my device.
The code is well written but I cant make sense of it, if it was c maybe but not in python on a slow rpi1. Searches take forever.


You must be a professional to write 6000 lines of code just for a battery, its amazing.

Thanks for the help this tool is amazing i feel ashamed to ask for more help so l’m considering buying an ev 2300.

[mefistotelis]

Language becomes less relevant with each year you spend programming.
Focus on the data transfer. Everything the tool does is just a wrapper for that.

The response you got on OperationalStatus is "00 04 d1 ...". Which means:
- this is not an answer using block protocol - there is no length in first byte
- the value returned is in 2 first bytes - so it's 16-bit integer
- the last byte is just pec

In command definition within Python file, you define that value 'type' as 32-bit block. This does not match the data.

[Smb]

Funny is I did try changing the datatypes even searched google what kind of datatype uint16_blk is and found nothing so I thought this is just a normal unsigned int in python.
So blk means block, i never heared of that datatype. I will search if i can find a definition in the code.


Anyways I changed the datatype to int16 then changed the smbus_read_by_writing_ subcmd_first  function to include the read word function  before it only read blocks.

Still not getting my two bytes.
Byte to type str   for 01 14 b4  returns  5121 which seems correct on little endian but i guess what i need is a function that makes one byte from 01 and one byte from 14.
Is that correct?

Because I’m getting the: byte must be in range 0-256 error  or str cannot be interpreted as integer errors.

Also str should mean string so byte to str is maybe not the correct function.
I’m aware that not all responses should be int16 but I’m just hoping to get a startingpoint.
Also why can’t I just convert  01 14 directly from hex to binary? Is there a reason to make it into an integer?

[camila]

Check out the Voltage Ratings

The B+ has an under-voltage detect trigger which results in the power led going off when voltage drops below about 4.65V.
The signal is also available on a gpio line (GPIO35).

Latest firmware update will display a warning symbol in top right of display when this is detected.
It will also disable turbo mode while the warning is displayed to try to reduce the chances of crashing.

I've also added a warning symbol to the existing over-temperature condition (> 85'C), which also disabled turbo mode.

Currently the symbols are:
Red square: over-temperature
Rainbow square: under-voltage

As usual you can override the behaviour in config.txt if you understand the risks:
avoid_warnings=1 removes the warning overlay.
avoid_warnings=2 additionally allows turbo when low-voltage is present.

For testing you can make the temperature warning trigger more easily with "temp_limit=50".
You can probably trigger the under-voltage check by using an insufficient power supply (perhaps USB socket from PC), or a dodgy micro-usb cable from ebay.

Run rpi-update and report back if it behaves as expected.
You will need a B+ to test the under-voltage state. The over-temperature should work on any Pi.

[mefistotelis]

> Funny is I did try changing the datatypes even searched google what kind of datatype uint16_blk is and found nothing so I thought this is just a normal unsigned int in python.
> So blk means block, i never heared of that datatype. I will search if i can find a definition in the code.

Yeah, this is my own "invention". Maybe I should have implemented a separate "is_block" flag instead of mixing it it with the type.