Acer battery clear pf flag using raspberry pi  - Page 1
Forum section: electronics / general

author: Smb
author_rank: Newbie
timestamp: March 29, 2021, 04:58:21 pm
content: 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-toolsSure 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.pySome commands work like device info.Gives correct info.But manufactureraccess does not give me anything.After comparing the technical reference of the bq3050https://www.ti.com/lit/ug/sluu485a/sluu485a.pdf?ts=1616851769302and bq30z554https://www.ti.com/lit/ug/sluua79/sluua79.pdf?ts=1616950132055&ref_url=https%253A%252F%252Fwww.google.com%252Fseem to use the same address for the pf status 0x53 and manufacturer access 0x00Some 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.

author: mefistotelis
author_rank: Newbie
timestamp: March 29, 2021, 05:46:39 pm
content: BQ3050 reference:QuoteBQ30z554 ref doesn't explain things that clearly, but description of each command follows the same scheme:QuoteQuoteSo 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.

author: Smb
author_rank: Newbie
timestamp: March 30, 2021, 08:50:34 pm
content: 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.

author: mefistotelis
author_rank: Newbie
timestamp: March 30, 2021, 08:58:41 pm
content: When data ends and you continue reading, you get the last byte (usually PEC) repeated.

author: Smb
author_rank: Newbie
timestamp: April 04, 2021, 01:33:04 pm
content: After looking at it some more I didn’t manage to figure it out.Tried to change expect_len in smbus_read_block_for_basecmdTried turning off pec by setting bus.pec to 0Commented out pec valueerrorTried raw read and raw write which also didn’t give me anythingTried hex to ascii hex to binary on the responsesTried changing theBqstatusbitsMa 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.

author: mefistotelis
author_rank: Newbie
timestamp: April 04, 2021, 02:12:39 pm
content: 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 pecIn command definition within Python file, you define that value 'type' as 32-bit block. This does not match the data.

author: Smb
author_rank: Newbie
timestamp: April 08, 2021, 02:43:32 pm
content: 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?

author: camila
author_rank: Contributor
timestamp: April 08, 2021, 06:35:28 pm
content: Check out the Voltage RatingsThe 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-temperatureRainbow square: under-voltageAs 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.

author: mefistotelis
author_rank: Newbie
timestamp: April 13, 2021, 05:56:32 pm
content: > 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.