Battery firmware

[notsolowki]

i notice the battery firmware is not encrypted. i wonder what could be done to the battery controller so aftermarket batteries could be connected

[ferraript]

what FW version are you talking about?

edit: I guess you mean 1.7 as I found at phantompilots forum people complaining about how FW 1.7 disabled aftermarket batteries

but that's very strange, because on 1.6, those batteries were allowed and there is no update of battery module firmware in 1.7 (at least with P3A) so either battery module firmware was updated for P3P only or (most likely) this restriction is included in another firmware module

[mefistotelis]

There already are 3rd party batteries. And some people are disconnecting the lipo cells and connecting their own packets to the board. I don't see much benefit in looking at this firmware.

But id someone wanted to, first step would be to look at the battery board and identify microcontroller used.

Then a proper disassembler can be used to take a look at the code.

[notsolowki]

i thought it was a different processor. im not good at disassembly OR assembly. but i know alot more about it now since ive been using your tools. thanks and @ferraript. i will always be talking about fw 1.7.6 because i dont think i would ever use any other version.

[notsolowki]

@mefistotelis. when i cranked up the speed settings the drone would go between 45-60 mph per hour, about 20-25 mps. only thing is the person i have running the firmware gets battery errors about the current. i dont get these errors at all. this persons gimbal has been moved to the front of the drone and they think that might be the problem, but i dont think it is. also it is 1 degree F where this person is flying.

[mefistotelis]

i thought it was a different processor

It is. Processors which are not focused on computational power but on driving another hardware are called microcontrollers (uC).

also it is 1 degree F where this person is flying

I'm pretty sure that was the issue. If the battery had time to cool down below zero, it would definitely act strange. There is a thermal sensor which usually blocks the drone from starting in such case.

[GlovePuppet]

It's a TI MSP430 IIRC. I guess they are authenticating the battery via a handshake on the I2C bus.

[pawelsky]

Communication with the battery is done via serial at 115200 baud and I've managed to simulate most of the communication (enough to start the motors) using an Arduino board. https://www.youtube.com/watch?v=inKlEuTi9cA

But I agree with mefistotelis that it is not wroth spending much time on the battery firmware as the 3rd party alternatives are easily available and cheap enough.

[notsolowki]

Pawelsky can you share the code for the arduino please. Thanks!!

[pawelsky]

No, as I said I don't want to spend time on it to make it "shareable", sorry. The 3rd party replacements are good and cheap enough now.

[notsolowki]

Yea okay your helpful. Why even open your mouth then.

[pawelsky]

I was just about to start translating the description of the battery communication protocol into English, but seeing the attitude above I've really lost my motivation :(

Maybe some other time...

[notsolowki]

Lost your motivation?

"No, as I said I don't want to spend time on it to make it "shareable", sorry."

OKAY

[pawelsky]

You do understand a difference between "Arduino code" and "description of the communication protocol" right?

You are really not making yoursef any favours with that attitude...

[notsolowki]

Honestly im not sure how the handshake process works

[notsolowki]

But i do have an arduino and it sounds like somthing i want to do. I want to see how it behaves when it dont detect the load on the battery.

[pawelsky]

It is not just a handshake. It is continuous exchange of vital battery parameters (including voltages, discharge current, temperature, charge level, errors, etc.)

[notsolowki]

Well if you still willing to shRe the project with me that would be great. I think it would be alot of fun. I setup my battery to 115200 and was getting somthing but not sure what to make of it. Were you able to get any english fro. The console? Thanks

[ruckusman]

@pawelsky I'm late to this party, however I do have some questions you may be able to answer easily.

I'm looking to re-use Inspire battery boards with higher capacity cells, so need to reset the discharge counter as well as the capacity reductions that the processor calculates and stores, just wondering if you've succeeded in any communications with the TI MSP430 microcontroller via the TX/RX pads, not the I2C communications between the battery and controller.

Or if that's not the place to be looking for communication to acess the usage logs, can you suggest if I should access the I2C comms instead

[pawelsky]

Never had Inspire battery in my hands. PH3 batteries communicate via UART, not I2C.

[ITANOSYS]

Sorry for digging up the post! But: Same problem here. I have connected a 7000 mAh battery to the TB47 board. It would be nice if I could "teach" the battery controller the new capacity. Is there a solution for this by now?

[0r10nV]

@ITANOSYS If that still to the point, you fisrt need to figure out which gauge IC is your Intelligent Flight Battery equipped with. For Phantom 3 and Mavic Pro it's bq30z55, for Mavic Air and Spark it's bq9000 with proprietary firmware. Both could be reprogrammed using ev2300 and bqEVSW of bqStudio software after unsealing and getting full access to IC programming interface.

[pawelsky]

TB47 has BQ76930 + BQ78350

[0r10nV]

Do you know which firmware version of bq78350? bqStudio supports v0.05, v0.06 and v1.03 only in default setup.

[pawelsky]

Unfortunately not :(

[0r10nV]

Do you have good quality pictures of TB47 battery board? If have, send me please to orionv76(at)gmail.com Thanks!

[pawelsky]

Here http://i.imgur.com/bjeAfxz.jpg

[0r10nV]

Thanks! Do you have any i2c or smbus adapters to read basic information from bq78350?

чт, 25 апр. 2019 г. в 12:45, Pawelsky notifications@github.com:

Here http://i.imgur.com/bjeAfxz.jpg

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/o-gs/dji-firmware-tools/issues/17#issuecomment-486603894, or mute the thread https://github.com/notifications/unsubscribe-auth/AJHZPA6WXF6E5DDHQZIV4XDPSF4UXANCNFSM4C7QHINQ .

[pawelsky]

Well, I do have EV2300, but...

...I don't have the TB47 board (the picture was found somewhere in the internet) :)

[0r10nV]

pawelsky, did you emulate SHA1-HMAC authentication sequence over UART between arduino board and P3 drone when experimented in your lab setup without genuine smart battery? Is it battery autentication involved in P3 anyway?

[pawelsky]

No, it was not needed.

[0r10nV]

Which FW version your P3 has at the moment of experiment? 'cause DJI introduced 'challenge-responese' batery check in newer revisions

[pawelsky]

Don't know as I've sold it long time ago :), but despite the fact that the challenge-response also existed back then the authentication could simply be ignored.

[vmiceli]

Ok lads, I bought a bunch of TB47 or TB48 PCBs as the cells were removed and I hooked one of them up with a regular 22.2 5000mah LiPo and to a PC running bqstudio. The PCB has test points for the SMBus that connects the bq78530 to the MSP530 so the software can talk to the battery manager IC. I can read the registers and I can tell it is a TB48 as the Max cell capacity is larger than a TB47. The question is, will I be able to UNSEAL it and edit the params? I need to read the bq78350 pdfs and the bqstudio docs to understand how to do that...

.

[0r10nV]

From what I see device was not autodetected by bqStudio, due to strange "fffffa5" at the left side near IC icon. Can you read firmware version through Manufacture Access? This could be done in Sealed State too.

To UNSEAL bq78350 first you should have valid Unseal Key. To edit params, firmware should be supported by software, otherwise they could be changed in Hex Dump with some reversing of Eeprom structure.

сб, 13 июл. 2019 г. в 15:31, vmiceli notifications@github.com:

Ok lads, I bought a bunch of TB47 or TB48 PCBs as the cells were removed and I hooked one of them up with a regular 22.2 5000mah LiPo and to a PC running bqstudio. The PCB has test points for the SMBus that connects the bq78530 to the MSP530 so the software can talk to the battery manager IC. I can read the registers and I can tell it is a TB48 as the Max cell capacity is larger than a TB47. The question is, will I be able to UNSEAL it and edit the params? I need to read the bq78350 pdfs and the bqstudio docs to understand how to do that... [image: Capture] https://user-images.githubusercontent.com/15876027/61171608-03cafc00-a572-11e9-9636-c8ffa1607bf6.JPG [image: Capture1] https://user-images.githubusercontent.com/15876027/61171626-3a087b80-a572-11e9-8825-7c20bdaa6799.JPG

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/o-gs/dji-firmware-tools/issues/17?email_source=notifications&email_token=AJHZPA4AEALXEHTLPREYBH3P7HDLRA5CNFSM4C7QHIN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3QZWA#issuecomment-511118552, or mute the thread https://github.com/notifications/unsubscribe-auth/AJHZPA5SRESAQ2PU7ZBLXULP7HDLRANCNFSM4C7QHINQ .

[vmiceli]

You are right, bqstudio didn't autodetect it. I just used one of the two predefined bq78350 profiles there. I need to understand what Manufacturer access means and how do I request a FW version thru it. What I did is push the FW_Version button on the right side and the result came in below. Does that mean anything to you? I have no experience with this stuff but I'm willing to learn and share. Anything specific you guys want to test just let me know and I'll execute it and share the results.

[0r10nV]

Yea, it's useful information!

DeviceNumber: 0x1e9b = 7835 ; i.e bq78350 FW Version: 0x0006; i.e. v0.06 FW Build: 0x0010 = 16 Chem Id: 0x3283 = 3283 (value transposed); ATL custom HVHC LiPo Cells.

Now what we can see in the bqStudio config directory

bqStudio/config/1E9B_0_06-bq78350.bqz ... targetinfo.xml ... "bqMaximus v0.06 build 16"

This is exactly what you need! Have you select correct profile?

[0r10nV]

regarding Manufacture Access, it is multifunctional SMBUS command 0x44 (and/or 0x00) through which could be performed variuos tasks like Sealing/Unsealing, Reading&Writing Eeprom, Conrolling FETs and so on, all described in datasheet well enough.

[vmiceli]

Great stuff 0r10nV! Now bqStudio is automatically detecting the chip, see screen shot below. The funny thing is that if I leave the auto refresh ON it will change the device ID near the chip picture to the fffffa5 that I had in my previous screencap that you highlighted. If I keep auto refresh to off, the chip ID won't change.

on a side note I pushed that UNSEAL button, but there was no acknowledgment from the chip (I used the default TI unseal keyword. Is it possible that this is not the correct way to UNSEAL it? I hope that the UNSEAL procedure is different and that with the right method the default TI string will unlock this battery, I'll go read the Manufacturer Access details, as it is porbably needed for UNSEALing it.

[0r10nV]

Following conditions should be met for successfull unsealing:

1. Parameter scanning (autorefresh) should be OFF.
2. At least 4s should be exposed from last MAC SMBUS transaction before start unsealing.
3. Valid UnsealKey should be used and correct endianess used for sending.
4. If done in manual mode, Unsealing should be carried out within 4s.

Normally Unseal procedure is split into 2 steps which means 32bit Key is split into 16bit halves and each sent separately within 4s time window to Manufacture Access 0x44 blockwise command in Little Endian order. For backward compatibility with older devices some newer generation TI Gas Gauges has also Manufacture Access 0x00 word-wise command with Big Endian byte order.

Tool buttons at the right panel is just a predefined wrappers for appropriate action, they should work. Alternatively you can use 'Advanced Comm SMB' Tab at the top of programm window.

P.S.

From screenshot provided, FCC = 5450mAh and CycleCount = 0 tell me the battery was just brand new. Any reason to disassemble $200 pack just for LiPo cells? Think someone who did it, is very rich man!))

[vmiceli]

Thanks 0r10nV, I bought 5 PCBs with top cover and no cells and judging from their status I think these batteries were never used and just self discharged below the threshold to turn them on. What I don't understand is that there should be a permanent fail flag for cell undervoltage, but the PCB I wired is not in a permanent fail state (I think) as I plugged it in the Inspire 1 with the 5000mAh LiPo and the Inspire worked, and armed the motors. I didn't fly it though and in the battery history there was a cell failure event (in DJI GO) so maybe there is some flag already set in it. Anayway I practised the use of the Manufacturer Access and I can get info as per the 78350 technical manual. I also tried to unseal using the command button that uses a key that comes up by default but there was no acknowledgement, and nothing happened. I wonder if I should authenticate the chi? on TI forum somebody requested a customized bzq file for the 78350-R1 chip that would show an authenticate menu item... not quite clear yet. I also found this pdf, that I don't fully understand yet... BQ78350 Authentication and unseal Key.pdf autentication config for bqstudio_1E9B_1_03-bq78350_R1.zip

[0r10nV]

Cell Undervoltage PF event was not set because PF was not configured at all (see Green PF_EN flag in Manufacture Status) in this battery model. So all that was needed to recover the packs after long storage is just to precharge the cells! (imho)

May be DJI has changed his battery policy due to numerous recall because in PH3, PH4 battery packs PF is enabled for sure.

About Battery history fail events, they just for history and should not effect Drone being.

Authentication. Not concerns Unseal at all. This is for host to check if battery is genuine (DJI or non-DJI). And you can configure bqz by yourself by editing "bqz/toolscustomization/plugins.xml".

[vmiceli]

Cool, the bqz is just a zip file with those config xmls in it. Having a genuine PCB then is no concern for authentication. I haven't been able to unseal the battery yet using the unseal command button. I'll have to try in manual mode, but the 4secs limit is very short. In the case that the unseal key is not the default one, I wonder if that key could be located in the battery firmware? May be a battery firmware update includes the ability of the MPS430 to change some of the params in the 78350 hence the need to unseal. That would need some battery firmware digging and would make that effort worthwhile if it would enable full access to battery edits...

[0r10nV]

Your assumptions make sense! At least this requires logic analyzer to sniff update process of MSP430, to reconstruct its firmware. Because update file not ready to load in IDA Pro. It has some overhead or even encryption that prevent parsing it in disassembler. May be me wrong here but this is my understanding. Sometime ago me play with it a little (for P3 battery firmware), me have used raw binary battery firmware update module extracted from full update image, but disassembly in IDA had failed. But me have very little experiense with IDA and zero experience with msp430)((

[mefistotelis]

The battery modules from P3X (m1100 and m1101) do not seem to be encrypted in any way. m1101 even has some readable stings inside.

I assume one of these is for MPS430, the other is for a battery variant with different chip. Don't know which is which, but this should be detecatable by looking at MPS430 programmers guide.

So does 78350 have its own firmware? Can it be built with bqStudio? If so, we can get its structure from there.

[pawelsky]

I assume one of these is for MPS430, the other is for a battery variant with different chip. Don't know which is which, but this should be detecatable by looking at MPS430 programmers guide.

Or by searching for the default unseal code string in it :)

[mefistotelis]

Didn't got the sting directly, but there is a variation of it in m1101:

$ hexdump -C P3X_FW_V01.11.0020_m1101.bin | grep -B1 "\(67[ ]*45[ ]*23[ ]*01\|76[ ]*54[ ]*32[ ]*10\|01[ ]*23[ ]*45[ ]*67\)"
000058f0  54 e6 10 03 5c 13 5c 13  5a 13 5a 13 5a 13 5a 13  |T...\.\.Z.Z.Z.Z.|
00005900  08 ef cd ab 89 67 45 23  01 47 08 10 32 54 76 98  |.....gE#.G..2Tv.|
00005910  ba dc fe f8 08 10 32 54  76 98 ba dc fe 40 ef cd  |......2Tv....@..|
00005920  ab 89 67 45 23 01 11 22  33 44 55 66 77 00 cc cc  |..gE#.."3DUfw...|

[pawelsky]

Looks like this is it.

[vmiceli]

Ok. This is getting very interesting. The board I have is for the Inspire 1 i.e. WM610. Should we look into that specifically or is the firmware portion relative to the battery shared between WM610 and P3X? I would think they'd be different as different battery chips are used. For what I have found, the default for the bq78350 are: default Unseal key is 04143672, and the Full Access key is FFFFFFFF. Maybe we can look them up into the WM610 battery FW if it is not encrypted?

[0r10nV]

Think we should focus on WM610 because P3X as you noticed has different gauge IC and different design. Perhaps both would be originated from one basic reference design which developed by TI. Who knows.

Meanwhile have opened WM610_FW_V01.08.00.92_m1100.bin and it looks like really unencrypted binaries!) Below some blocks

Offset . . . . . 0 1 2 3 4 5 6 7 8 9 A B C D E F

000000E0 ... 31 00 DA 03 4E 56 54 00 07 62 71 37 36 39 33 30 . . . . . // 1 U NVT bq76930 000000F0 ... 00 04 4C 49 4F 4E 00 62 62 91 0A 41 54 4C 20 20 . . . . . // LION bb‘ ATL
00000100 ... 4E 56 54 20 20 00 08 00 81 00 00 00 00 06 02 00 . . . . . // NVT ?

So file most probably contains both Data and Code segments and my mistake from post above was attempt to load both of them into IDA. Correct way should be to extract Code first!

[GlovePuppet]

The question is, will I be able to UNSEAL it and edit the params?

I'm confused, why do you think the unseal secret is in the battery controller firmware? Does the PH3/4 need to unseal the device to use the battery?