[retepsnikrep]

Now we have lots of projects ongoing, but I thought we could discuss this wild idea.

The OEM BCM is very rugged, proven, and has all the peripheral psu/signal conditioning stuff on board.
But the fly in the ointment is the ancient 112 pin QFP Hitachi H8 processor, it's years old and cannot be programmed by us.
It's seems rather a waste to discard the pcb when it contains so much good stuff .....

The million dollar question, can we replace the oem processor with one of our own using some sort of QFP adapter daughterboard etc?

Assuming we can desolder the H8 and solder in our board, it would only need to carry a small number of parts.

A straight lift from the basic BCM Replacer design would mean we only need..

1) PIC18F66K80 cpu
2) Mega 88 Video chip
3) CAN interface chip. (optional)
4) A few supporting crystals and caps/resistors etc.

We could leave the BCM connectors completely OEM, no adding pins etc.

Our daughter board could have a little independent micro header connector for video/keypad/can bla bla.
A little hole drilled in the case and external breakout box with rugged full size rca connectors etc.

Now we are currently full steam ahead with the full BCM Replacer, but if people want to thrash this about then it would be interesting.
We won't be diverting resources time / into this soon but it might be worth exploring in this discussion.. :?



So the difficulties I see.

1) Unsoldering H8 CPU without damaging board.

2) Soldering an new adapter riser board in place to the old 112 pin QFP CPU pads.

3) Decrypting all the H8 CPU pin functions and relating them to the on board functions.
(With the H8 data sheet and some basic visual inspection and electrical testing I think we can work out what goes where)
Temp sensor input, current sensor inputs, voltage taps etc etc

There is quite a bit of real estate round the cpu on the OEM pcb.
We can cut the alloy strengthening bar out of the old case if needed.



This is one idea for getting something attached to the OEM pcb. ..

Advanced Interconnections | QFP Adapters

Advanced Interconnections' patented Solder Sphere Interface streamlines package conversion for use on PC boards with existing QFP pads.

www.advanced.com

Ideas welcome. Over to you...

Here's a couple of old YT videos of me looking at the CPU and voltage tap modules..

 

[*sean*]

Rather than unsolder it, maybe you can hold it in RESET and cause all its outputs to float??? Then you can solder just the wires you need to places more convenient, like chip resistors. Not sure if the RESET trick would work.

I was thinking of doing this to a spare BCM so that I can use the ADC isolation modules to monitor charging current and balance while grid charging with this:

HiLetgo ESP-WROOM-32 ESP32 ESP-32S Development Board 2.4GHz Dual-Mode WiFi + Bluetooth Dual Cores Microcontroller Processor Integrated with Antenna RF AMP Filter AP STA for Arduino IDE

I think it has 12 12-bit ADC inputs. I am fabricating a plastic case like the one @Eli sent a photo of the other day. It's a project that could be done in a day...

As for making a full BCM replacement, yeah, I think you would NOT want to use an ESP32 (it would be easy, but I would not trust it to be reliable particularly with wireless capability) but instead go with an automotive-grade processor. It would be great if it had CAN bus.

 

[*sean*]

But the fly in the ointment is the ancient 112 pin QFP Hitachi H8 processor, it's years old and cannot be programmed by us.

I was looking into this the other day. Isn't that particular H8 version the flashable one rather than mask ROM?

Of course, we would probably have to build our own programmer (I did check EBay for programming tools, and there seems to be something that might work.) Then there is the H8 toolchain. I think I saw some open source thing someone had.

I was more interested in trying to read its code to see how it works, but programming it to fix problems or provide more information via the data buses (like the voltages of individual cells, so that we can observe imbalance during hard regen or assist) would be the next step.

 

[retepsnikrep]

Sean 8+ Years ago I looked at reprogramming the H8 (ours is flashable) and even spoke to Hitachi who basically said everyone who worked with it is either dead or retired and they were unable to help with any form of info or programming devices beyond the data sheet etc.

I couldn't find any other info on Google/e-bay re programming the H8 at the time.
If you have now please post the links etc so we can revisit the idea and look at the possibilities.

The holy grail of monitoring individual voltage taps has been a thorn for years..

EDIT Just googling around now does provide more info and datasheets which i'm downloading.. The BCM does have a programming port on board..

 

[rmay635703]

H8S programming - H8 - Forum - H8 - RenesasRulz

I am looking for a hardware/software tool to read/write to an H8S/2623 mcu. I realize this chip was discontinued in 2014 but I hope to find a lead to a toolkit

renesasrulz.com

Have you ever bothered the “programming” folks (some of which are Russian) about tools for the original h8?

I think that microcontroller was used in other unrelated applications, once a rom image is dumped the rest becomes easier.

I’m in the same boat.
I have been looking for years for information on a robust tianjin battery 2/3 stage charger that came in a car I have, it is fully programmable and could work with lithium, sadly there is no info in English on the device to adjust its voltage cut points

 

[rmay635703]

https://www.renesas.com/us/en/doc/products/tool/tu/tnfps003ae.pdf

Mr Ito is still alive, wonder how we would find the software for writing/ reading on the bench?

 

[*sean*]

... everyone who worked with it is either dead or retired and they were unable to help with any form of info or programming devices beyond the data sheet etc...

I think it was the section on programming which describes a couple of different programmers. You don't happen to have one of those? I looked on Ebay and they were rare. The third party programmer (I don't have my notes here) had several different versions. The newer ones seemed less rare and probably are compatible.

For all the reasons you stated it makes no sense to try to resurrect the H8 except for two.

One is to understand how the code works for diagnostic purposes and better understanding why the BCM is doing what it is doing. For example, what condition triggers a negative recalibration? The H8 toolchain can help with this process.

Second is to improve system monitoring without the burden of modding a bunch of hardware. For example, creating a new bus message that provides individual stick voltages or even an "imbalance" message. You could then do things like provide a "time to grid charge" message, or let an owner know of a weakening stick.

Having more information about how the system works in order to be able to better diagnose and repair it, and being able to add small features, would be hugely valuable.

What if your daughterboard that replaces the H8 is ARM based? You could copy the Raspberry Pi schematic and add the needed A/D converters and RS-485 ports and BAM you're done. You could have a full Linux environment for testing new ideas, while implementing your code as a driver that is started in the first few seconds of the boot process. It would permit the eventual creation of an H8 emulator which could be used to understand how the original code works, thus eliminating the need for any of the H8 programming toolchain at all.

 

[rmay635703]

The r7000 emulator is included with the h8 compiler / programming environment, no idea how you would find a copy of old software though.

 

[retepsnikrep]

I never found a compatible/suitable H8 programmer, but stopped looking 8 years ago after i first looked at the idea. They may be available now secondhand so time to start looking again.

If you could reprogram the H8 cpu then yes you could insert another packet into the BATTSCI data stream containing the 10 tap voltages, but the MCM might not like a foreign packet on the bus and throw errors if it kept getting one on a regular basis. You would have to test that with a BCM interceptor and dummy packet inserted into the stream before you launched into the project. If you can insert a packet then that can easily be read by a 'BCM Gauge' type device. (The 'BCM Gauge' was the first monitoring device I built for listening to those battery packets over ten years ago now.)

The H8 Chip of course might well be write protected, or more likely at least read protected, so we could not extract the code anyway and maybe not even overwrite it.

If I replaced the H8 chip with a daughterboard it would not be with an ARM/Raspberry PI device as I know nothing about them or C or anything else..

My solution would be a pic based as mentioned, and probably re use 50% of the code already written for the BCM replacer.

I'm busy with loads of stuff but will keep an eye out, hopefully one of you will make some progress on an H8 programmer and can try and read the chip.

 

[retepsnikrep]

Farnell UK still seem to have some NOS H8 Emulator and programmers. £128

https://uk.farnell.com/renesas/r0e00008akce00/e8a-on-chip-debugging-emulator/dp/2946866

 

[retepsnikrep]

Not sure of the product I linked above allows reading of the H8 flash memory as well as writing... :? Anyone..

 

[*sean*]

Not sure of the product I linked above allows reading of the H8 flash memory as well as writing... :? Anyone..

Bitbang with an Arduino Mega?

 

[retepsnikrep]

Good luck..

 

[hurricos]

I was looking into this the other day. Isn't that particular H8 version the flashable one rather than mask ROM?

@*sean*: Correct. On the MCM (and I assume the BCM), the H8/538 is silkscreened as 'HD64F5388F16':

http://www.solarvan.co.uk/insight/mcm.jpg

Compare this spreadsheet ('HD64F5388'):

https://datasheet.ciiva.com/26936/getdatasheetpartid-391023-26936943.pdf

The process of dumping the firmware was done on at least an H8/539F used as a Mitsubishi ECU, here:

openecu.org • View topic - Mitsubishi H8/539F(MH7202)reading/flashing research started.

Online Disassembler supports h8500; I've gone ahead and grabbed the ECU firmware from another H8/500 -- 33920-79E50 -- and dropped it into ODA: ODA - The Online Disassembler

Folks at OpenECU have gotten a kernel working for Mitsubishi ECUs on the H8/539F ("OpenEcu Mitsubishi H8/539F Kernel") -- that should be, a runtime-loadable program which can dump flash for you. I do not know where the source for that lives.

The kernel implements (I'm sure) the work described in Section 16 of HD64F5388 Hardware Manual, attached.

Since the owner of OZVR4 has some interest in reverse-engineering binaries for the H8/539F, I'm going to see if I can ask them how they dump firmware and if ECUFlash is really necessary there.

If we can't get a kernel working on the H8/538F -- it's got half the RAM -- then putting it into PROM mode (see 16.6, "PROM Mode") would also work, but it would much more likely require desoldering.

 

[hurricos]

@retepsnikrep: I skimmed https://www.renesas.com/us/en/document/mat/e8a-emulator-users-manual and came to the conclusion that the E8A does not support H8/500, only H8/300 etc.

I know the Lauterbach ICEH8 supports most of the H8/500 family (though it doesn't explicitly mention the H8/538 or H8/539).

I think we should follow the trail of using a kernel to do the reading/writing for us. We ultimately can dump the PROM, disassemble it, modify it, and rewrite it without an ICE or BDM, but instead with some really delicate soldering; but for a final product we need a way to do it in-system.

Ancient versions of GDB had code to interact with the ROM monitors on these chips, c.f. these links:

• Index of /freebsd/head/contrib/gdb/gdb
• Debugging with GDB - H8/300

I imagine that I will have some FoMoCo packs and my LiBCM in-hand before I get to testing any of this, to be honest. Still, I wanted the thought to be finished.

 

[hurricos]

Oh, here's a post on Club4VR about how EcuFlash actually rigs up debugging on the H8/539F:

https://www.clubvr4.com/forum/archive/index.php/t-80688.html

I imagine the H8/538F is very similar.

Edit: And from the link above, we get this Google Doc which shows the breakout process on the Mitsubishi ECU boards: VR-4 ECU CON2 Pinout

 

[hurricos]

One more thing: Looks like this is all part of Renesas' F-ZTAT (Flexible zero turn-around-time) design, whereby ICs can be reprogrammed in-the-field using a special adapter:

https://www.renesas.com/us/en/document/mat/flash-programming-adapter-board-hs0008eauf1h-users-manual?language=en&r=1169906

I think someone should go and trace that 5x2 pin connector. Who knows what it could be? :^)

 

[hurricos]

Specifically, look for what is continuous with pins 102 and 103 of the MCM's H8. These are the SCI lines for serial programming; if they lead nowhere then the board was not programmed in the field this way.

 

[mudder]

Thanks for looking into this information. At this point I don't see much reason to dig into the OEM BCM's hardware/firmware... LiBCM replaces it entirely, and is 100% open source. Obviously I'm a bit biased because I designed LiBCM, but I'm just not sure it's worth the effort, since at the end of the day even the best firmware running on an OEM BCM is only ever going to be able to monitor the NiMH cells... obviously this could be useful to all those cars still running the OEM BCM, but the firmware effort would be tremendous so it would need to be a true labor of love.

If the OEM MCM uses the same CPU, then that could reduce the time required to develop replacement MCM firmware (since I haven't started designing LiMCM yet). However, the modern motor control algorithms I intend to use require considerably more processing power than the old busted H8 CPU family can deliver.

 

[hurricos]

Yeah. I only dug into the H8/538F to close off some loose ends. I know folks here enjoy exploring how the stock system works, and if there are convenient ways to get at it, more power to them. I hope that that crowd gets far down that path, because where available, examining source (or disassembled binaries) is the best way to understand the OEM FW's behavior -- we can stop guessing about what it does.

Ultimately, the stock system is the problem. The BCM and its firmware are designed the way they are because they have to manage flawed hardware.

I would not suggest re-using the MCM, not only because the H8 is slow, but also because it's ancient CISC-y crap that will never see the light of day again. More immediately, there's an unexplored OKI IC on the same board whose functionality is not known ... given that the TCU and ECU are also both pre-ARM OKIs, as are the same parts on other same-generation Honda vehicles, I'm guessing it's communication with those.