ATMEGA325PV - Solar battery - Complete noob help

Go To Last Post
43 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all. First post here and I have zero knowledge in this field.

 

I have a solar battery made by Sony (Sony Fortelion IJ1001M) which has an ATMEGA325PV microcontroller on the circuit board.

 

The issue I wish to resolve is a convoluted one, but entails how a solar inverter interacts with this battery based on a serial number stored in the ATMEGA EEPROM. If I can change the serial number in the EEPROM, the problem will be resolved.

 

I assume there might be some sort of checksum in the EEPROM, so I probably can't just write to the serial number and change it as needed (I'm guessing?). To that end, I have access to an identical battery that differs only in the serial number. I wish to duplicate the code from one battery to the other so the serial numbers match.

 

Things I've worked out -

 

1. The chip has ATMEL ATMEGA 325PV 10AU 1509 written on it.

2. The Atmel website doesn't list anything ending with 325PV (it does have 325, 325A, 325P & 325PA).

3. The battery management system has a COMM OFF MODE for maintenance. I assume this is for either flashing the firmware on the BMS or the battery modules.

4. Each battery has a 10pin JTAG plug.

 

Some questions -

 

1. Is this problem likely to be solveable?

2. What sort of equipment do I need?

3. What is a good starting point to learn the required steps?

 

Thanks in advance for any pointers.

Last Edited: Mon. Sep 18, 2017 - 04:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have a look at the datasheet, specifically the ordering information: http://www.atmel.com/images/doc8...

 

The PV is the 10MHz version that works down to 1.8V.

 

This device has protection that can prevent further programming/reading of the EEPROM and flash memory. If Sony enabled them, you might have to try de-capping the chip and erasing that bit with UV light.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Inappropriate: trying to circumvent product security

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Meh, he owns it, he can do what he likes with it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like he own one - but is trying to get a second one for free ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How will changing a value in EEPROM magically conjure a 1.2kWh battery out of thin air?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can assure you I own all the modules and have spent a small fortune on them (hopefully not unnecessarily).

 

The background to the problem I'm trying to resolve -

 

The system is a Fronius Energy Package that is designed to support only 8 battery modules behind the BMS. Unfortunately, 8 modules is insufficient for my needs. I wish to expand the system with another 8 modules.

 

I have purchased the additional modules and designed a switching mechanism that alternates the two banks of 8 battery modules behind the BMS. From the perspective of the inverter, the system looks like a normal 8 module system at any given time.

 

Unfortunately, the inverter has some logic that picks up the serial numbers of the battery modules. If a given module is changed for whatever maintenance reason, the system is designed to conduct a calibration charge to 100% to balance the new module with the old modules. This calibration charge phase is not conducive to normal use of the battery. It is also unnecessary in my circumstance where I'm switching in 8 'new' balanced modules. These new modules are all at an equivalent charge state.

 

By duplicating the serial numbers from the first bank of batteries to match the serial numbers of the second bank, the inverter will be unaware of the switchover. Normal charge/discharge of the battery bank will then be possible.

 

So, I hope you might appreciate I'm not trying to circumvent product security. The issue is how a downstream 3rd party device (the Fronius Hybrid inverter) interprets those changing serial numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting idea. I suggest:

 

1. Try to read the EEPROM, see if it is protected. It might not be, you might be lucky.

 

2. Rather than attack the EEPROM, man-in-the-middle the comms system. The battery units seem to have CAN bus and RS232. Which are you using? In either case, you can build something that sits between the batteries and the BMS and translates the serial numbers on the fly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tim_C wrote:
By duplicating the serial numbers from the first bank of batteries to match the serial numbers of the second bank, the inverter will be unaware of the switchover. Normal charge/discharge of the battery bank will then be possible.

But the batteries are not identical!

 

And, when the switch-over occurs, they will be in different states of charge.

 

Trying to fool the control system that they are identical is potentially dangerous and/or may damage the batteries - by over- or under-charging.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Is there some reason why you can't have a second BMS? I don't know much about this but it seems like there must be some kind of official solution for people who want more than 10kWh.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the help.

 

Agreed. The man-in-the-middle intercept of the comms system is one I had considered. The system has a device that sits between the inverter and the BMS called a Unigate CL-RS. It translates RS232 (native to the BMS) to Modbus RTU (native to the inverter).

My knowledge is deficient on how to achieve a comms intercept though.

 

So changing the EEPROM seems the simplest option assuming there's no protection (and that's a big assumption given the maturity of a company like Sony).

 

@Raving Lunatic - The aspects of the switching logic are handled off-board by a Loxone Home Automation system. That system handles SoC and depth of discharge based on memory flags from when the given bank was connected to the BMS. Plus further buffers have been added to ensure the system doesn't deep discharge.

 

Using another BMS would be a very attractive option except it's not supported by the inverter. Maximum output from the Hybrid is 16A and the single BMS uses all that at 6.6kW charge rate.

 

I've explored all options through the chief engineer of Fronius Australia, with correspondence flying between Head Office in Austria and here. I've also asked them to explore software triggers to disable the calibration charge. This work-around seems the most likely path to achieve expansion of the system.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should also add the comms path is also switched along with the battery modules (4 x DPDT relays) for the 8 core cable. So when a given bank is switched in, it has full comms with the BMS.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doing a MITM attack on the comms isn't too hard. MODBUS is likely to be RS485, and the protocol is fairly simple. However, the RS232 is likely to be even easier.

 

You could just get a laptop would a couple of RS232 to USB converters and something like this: https://www.compuphase.com/softw...

 

You can then have a look at the traffic, it's likely to be a fairly simple protocol and you could probably use something like a Raspberry Pi and to simply forward all data, only changing serial numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've attached a few of photos of the project. The left and right banks of modules operate independently but sequentially behind the single BMS. All aspects of connectivity between the respective bank of modules and the BMS  are switched (Comms, Power flow). The daisy-chained comm link between each module is of unknown protocol. The one known protocol is RS232 that exits the BMS to the translation device (RS232 to Modbus RTU) before going to the inverter.

 

This system would work fine except for the 'calibration charge' issue. Because of that, the battery banks can't be sequenced as a continuous supply with a switch-over on completion of each bank discharge.

 

I've had a read through the "ATmega325P/3250P" document you linked to earlier. Thankyou.

 

It looks fairly complex from my perspective but I've never used AVR Studio or used a JTAG device. If I've read correctly, it seems like you need to completely erase the EEPROM then re-write it. I was hoping to be able to identify just the serial number that needs changing amongst other data and alter that. ie. to avoid the significant risk of bricking the module (although it would make a very effective doorstop at 17kgs....).

 

On balance, recognising I've got a steep learning curve for either option (MITM or EEPROM hack), I think I'll try at-least reading the EEPROM. That path appeals for it's clean-ness.

 

Is there any particular JTAG device you would recommend for use with the ATMEGA325PV?

Or anything else worth considering before heading down this path?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may be able to read the EEPROM via JTAG. If you can't, it's because Sony remembered to set the protection bits. It's possible to get around that, but not at all easy or reliable.

 

The best device for the JTAG effort is probably an AtmelICE. They are not cheap any more unfortunately, but they are supported by Atmel Studio.

 

I think MITM attack is by far the best option. Relatively easy, low risk. If you start with that software I linked to you should be able to see the data being transmitted on your screen. If it looks readable to a human being (quite likely) then modifying it will be fairly easy too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll bite:  Why are we discussing ATmega325PV in the Xmega forum?

 

Indeed, I've participated in reverse-engineering AVR-based "gadgets" over the years.  But these were indeed gadgets and the intent would be to re-purpose the entire unit rather than trying to hack operation of the units.  (remember "Funcards", and the spate of threads to hack paintball guns to make them fire faster?)

 

I'm a bit confused...if the Sony battery+controller with the AVR is a unit, then why doesn't the substitute battery also have a controller?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Why are we discussing ATmega325PV
Tim_C wrote:
1. The chip has ATMEL ATMEGA 325PV 10AU 1509 written on it.

Interesting.  There was indeed Mega165P/V and Mega325P/V circa 2004 to 2006.  The V tag seems to have disappeared with the omnibus datasheets for the family which came out a few years later.  The only mystery for me is the 1509 date code -- perhaps they >>were<< still produced?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tim_C wrote:
Things I've worked out - 1. The chip has ATMEL ATMEGA 325PV 10AU 1509 written on it. 2. The Atmel website doesn't list anything ending with 325PV (it does have 325, 325A, 325P & 325PA).

Yet they are stocked at distributors?  [which explains the modern date code...]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

NB:  There may be more than one reason to embed a serial number in EEPROM or elsewhere.  Besides any possible security function, that complete system may be calibrated/tuned/specified for the combination of components.  A off-the-cuff scenario:  The system is married to a battery that is only happy at 1/2C or lower charging rate, and the embedded parameters are used to embrace and enforce that.  If you then marry to a battery that is only happy with a lower charge rate, you can suffer damage to components/surroundings/personnel.

SIGNAL WORDS

The signal words “

Danger

”, ”

Warning

” and

Caution

” used in this manual indicate the

degree of hazard that may be encountered

by the user. These words are defined as:

Danger

- Indicates death or serious injury will

result if proper precautions are not taken.

Warning

- Indicates death, serious injury or

property damage can result if proper precau-

tions are not taken.

Caution

- Indicates some injury or property

damage may result if proper precautions are

not taken.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
I'll bite: Why are we discussing ATmega325PV in the Xmega forum?
Not any more ;-)

 

(I just moved it to "tiny/mega" - hope that was the right place).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
 If you then marry to a battery that is only happy with a lower charge rate, you can suffer damage to components/surroundings/personnel.

Yes - that was my point in #9.

 

From the photos, this appears to be quite a substantial undertaking, and the OP reports high-level interactions with suppliers - so it seems bizarre to be relying upon hacks like this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Maybe I just need more sleep, or more caffeine, but a nice block diagram of the system would be helpful...

 

The Mega has "lock bits", and if those are set, then you can't read the micro's code, or the EEPROM, even with the JTAG.

 

It would be very unusual for the manufacturer of a commercial product to not set the Lock Bits, certainly possible, just unlikely.

 

That means that if the lock bits are set, you can do a master chip erase, and then reprogram the system.

But the Master Erase is just that, the code, and EEPROM data are all erased, you can't read / upload a copy of the original code.

 

Next comment:

Although the Man in the middle converter sounds conceptually easy, the devil is in the details.

IF one had a developer's package for the systems, and knew ALL of the possible transmission codes / packets / messages, etc., then the MITM converter is a "simple" project.

Two interrupt driver, ring buffered I/O systems with some converter logic gluing them together.

 

The issue, of course, is what does the MITM system do when it is sent a previously unknown data packet, perhaps a system failure message, emergent shutdown message, etc., that contains a battery identifier as part of the error tracking system. 

 

If the system is just "blindly" looking for a list of known battery serial numbers, and replacing X with Y, that might work 99% of the time.

 

But the system would have at least two possible failure modes, Battery 3 in bank A fails, and the system decides to switch to bank B right as the failure process is being dealt with.

A system critical race occurs.  Does the Master Controller really know which bank has a bad battery, and what steps did it take, and to which bank were those actions actually applied?

 

Error two, of course, is that if the Master controller doesn't know about the two "identical" banks, then how does the system know which "battery #3" failed?

 

Error three, is that a blind string replacement of serial number X for Y only works if one can guarantee that that data string can not possible occur elsewhere, at another time, when not referring to the battery.

Safe bet?  Not if you don't have the developer's manual and know each and every data packet that can be sent down the line.

 

Finally, the data packets are likely sent with a checksum or more likely a CRC data packet integrity validator.

Again, you could see the packets sent by the system, but what about the possible packets that you don't happen to capture during your monitoring and decoding test phase?

It can be very challenging to decode a CRC methodology, so that you can implement it in some unknown packet in the future.

 

Are either failures likely to occur?  Probably not.

But what is the worst case scenario when the system goes to hell and a catastrophic system failure occurs?

 

One tries to design nuclear plant controllers, fly-by-wire controllers, internal defibrillators, and similar such devices such that they can't fail, not just so that it is unlikely.

 

So, could one hack the system for a proof of concept, short term usage prototype?

Yes, doable.

 

Could one certify the safety and reliability of such a system?

Doubtful, without a lot of input from the system manufacturer ( s ), and testing.

 

When I see the term "noobie" within the Thread title for what I think is a rather complex project, with a potentially significant downside, I start to do probability of long term success calculations...

 

JC