MC68376BGVFT25 won't communicate anymore

[GA_TLM]

Hi,

I have been given a strange problem to resolve which looked like a wiring issue in a Lamborghini that didn't want to start. Which has now become something completely different.

In short what I think I have managed to work out, is that a certain ECU flashing company has just released a very new and fancy piece of hardware. But I suspect that the database in the backend containing the map registers for the this MCU are incorrect, and in turn I have 4 ECUs that have had their internal registers over written.

I have a 5th ECU that I know is working using an older ECU flashing module I was provided, I am able to read and write to it. When I measure the voltages on the 10 pin programming header on the board, which is in spec of the of the recommended BDM connection as per section 4.10.10 of MC documentation. When I measured the voltage on the DSO and DSI ports I had approx 3.3 volts. On the non working ECU I had a measurement of 5 volts. This is what led me to the final conclusion that the internal registers, specifically $YFFC00 to $YFFE00 had been over written. Which in turn may have turned these pins into I/O pins from what I can gather from the documentation, and has also changed some of the other pin assignments, which is now pushing 2.7 volts to some of the onboard transistors instead of ground, which is showing up in the car wiring loom and relay distribution boards.

1. I guess my first questions is, is this assumption plausible? I have worked with a few different MCU's, but not this one in particular.

2. If 1 = Yes, the next question is, is there anyway of communicating with the processor in order to recover it whilst in place. The BDM header 'seems' unusable in its current state. At least using the 3rd party flasher. I do have a PE Multilink Universal, but not the FX version so I am unable to use that to talk to the MCU. So, is there an alternate way to communicate with that MCU in order to recover it, possibly via the serial connections or by pulling a certain low, in order to interrupt it the boot before it loads. If it is possible then I will order an FX multilink if required, I would like to try and check whether there is some chance of success before doing so.

Thanks in advance

Gerry

[GA_TLM · Accepted solution]

Hi Tom,

So, the final update. One of the team from PE created a new 'programming algorithm'. Which in turn allowed me to erase and program the flash module. So after a bit of comparison of a few different flash files and some adjusting. I managed to resurrect the original ECU's which went back into the car about an hour ago and started the first time.

So again, thank you for your thoughts and input. We got there in the end.

Take care and I hope you have an awesome christmas.

Gerry

[TomE]

My previous reply isn't visible here yet. I've got your next post in email, but it isn't here yet.

You can read the flash. It doesn't need a matching algorithm to do that. It needs some sort of match, at least to tell it what the port width is (8 or 16 bit Flash). Have you got that right at least?

It is possible that ECU is using some form of "Write Protect" on that Flash to protect against accidental (or deliberate) writing. That chip doesn't have an external "write protect" pin (some do). They may be gating the "/WE" pin via another GPIO pin. They may have programmed the "Block Protect Bits" in the Flash so the blocks can't be written without the program deliberately unlocking those sectors. That needs 12V on the Flash Reset pin to be able to override. You hope they're not doing that. None of this is P&E's problem. The company that made the device that can re-flash these ECUs would know about that.

[GA_TLM]

I had the same issue, but this set of replies is toward the top of the post. Not at the end.

Yes, there is a match for it being an 8-bit flash. As well, as turning off the watchdog timer. 

;version 1.05, 11/24/1999, Copyright P&E Microcomputer Systems, www.pemicro.com [Am29_400b_b]
;device AMD, 29F400-B, 1x8x512k
;begin_cs device=$00000000, length=$00080000, ram=$00080000
WRITE_WORD=7F00/00FFFA04/ ;Double clock speed 16MHz w 32KHz Xtal
WRITE_BYTE=00/00FFFA21/ ;Turn off watchdog timer
;end_cs
NO_TIMING_TEST
USER=BE Block Erase 2Block > /00000000/0000000A/
;

However, this is quite sparse in comparison to some of their other algorithms. 

WRITE_WORD=7F00/00FFFA04/ ;Double clock speed 16MHz w 32KHz Xtal
WRITE_BYTE=00/00FFFA21/ ;Turn off watchdog timer
WRITE_WORD=0001/00FFFA38/ ;Place chip in TEST MODE
WRITE_WORD=8000/00FFF7E0/ ;Turn off 32K module
WRITE_WORD=8000/00FFF7E0/
WRITE_WORD=8000/00FFF800/ ;Turn off 16K module
WRITE_WORD=8000/00FFF800/
WRITE_WORD=0000/00FFFA4A/ ;Turn off CSBOOT
WRITE_WORD=0001/00FFF7E4/ ;Module address to feebah
WRITE_WORD=0000/00FFF7E6/ ;Module address to feebal
WRITE_WORD=0000/00FFF7E0/ ;Turn off stop bit in feemcr
WRITE_WORD=0000/00FFF7E8/ ;Clear control register feectl

There is a write enable pin on the flash which is connected to the CPU. These are part of the details that PE wants for the creation of an algorithm, which I supplied this morning.

WE# connected to pin 114 BR / CS0
CE# connected to GND
OE# connected to pin 113 CSBOOT

 
Anyway, we will see how it goes over the next day or so.

Cheers

[TomE]

That Flash chip can be used 8 bits wide or 16 bits wide. There's a pin on the chip that is strapped high or low to make it act one way or the other. 8-bit mode is usually used with 8-bit CPUs. The MC68376 is a 32-bit CPU, and the usual way to use it is 16 bits wide. I'd suggest you check that pin on the Flash chip with a miltimeter, and see if it is high or low. You've selected an 8-bit setup, and that could be wrong. If you're reading the Flash the way you expect to, It might be right.

That setup also seems (7F00/00FFFA04) to assume a 32kHz (watch crystal type) oscillator. I can see a 16MHz crystal on that board. But the SIM manual says the crystal should be between 1MHz and 6MHz. But I think that's when using the PLL. It can use an external clock, controlled by the MODCLK signal up to 20MHz. So that's what it is doing. It is running from a 16MHz external clock. The programming code has to be told this so it can get its timing right.

That file you've quoted is not "the programming algorithm". That's only the initial setup code to program the CPU to run. There's a separate binary file that is loaded into RAM that is the programming routine.

"0001/00FFFA38/ ;Place chip in TEST MODE": That's "Factory Use Only!

"8000/00FFF7E0/ ;Turn off 32K module": '00FFF7E0" isn't listed in Table D1 Module Address Map. Neither is "00FFF800". Neither is "00FFF7E4".

Those registers (searching for FEEBAH and FEEBAL) are in the 68F333 which has internal Flash. So I think you've got the file there for the wrong chip. It is might be trying to program the internal flash that is in the 68F333 that doesn't exist in the MC68376. Or maybe that file can control both chips, and writing the 68F333 registers doesn't cause any problems for an MC68376.

I guess you used a multimeter to work out which pin on the CPU the /WE signal connected to? It would normally be expected to connect to "R/W". Having it connect to "/CS0" is unusual, but would certainly explain why you can't program it without the code being changed to handle that.

[TomE]

Now you need to convert a hex of binary file to S19.

You can just type that into Google and see what you come up with. Or you can go to P&E's Forums as lots of people have had the same problem. Just search for "S19" in the PC Software Forum and you'll find stuff going back 13 years with solutions. Even better, P&E have a "bin2s19" program (and others) here:

https://www.pemicro.com/support/download_processor.cfm?type=5

There are lots of utilities for Linux systems that can do this, and there are probably other ones for Windows.

[GA_TLM]

Hi Tom,

Thanks again.

I managed to convert the file. But now for the life of me, I cannot get the programmer to program or erase. 

It reads no problem, but to try and erase or program, it says it is doing it, but never does, nor does it give an error.

I have been using this algorithm from PE - AMD_29F400-B_1x8x512k.32P. But I have now put in a request for a new algorithm to specifically match that processor and flash. In the hope that may change the outcome.

[TomE]

I assume that is with the Multilink and the other programmer disconnected. Read the "C4CPU" manual to see what those signals are. "FREEZE" doesn't have a bar over it so that implies FREEZE is high-true. So if it is low then it isn't asserted. The /RESET pin suggests to me a watchdog is running and continuously resetting the CPU because it isn't being serviced. There might be a hardware watchdog on that unit or it might be the internal one. Read the SIM chapter for details on the internal watchdog.

As for the P&E Software, nothing explicitly says it supports MC68376. However the MC68376 uses a "CPU32 core", and "PROG-HL-32Z" might be the one. The following Forum Post says "The Cyclones do not support the 683xx/CPU32 architecture. The only interface that supports it is the USB-ML-UNIVERSAL-FX". That both tells you that "683xx" and "CPU32" are the same thing, and that as long as your "Multilink FX" is another name for the "USB-ML-UNIVERSAL-FX" then you just need to buy a $199 license for "PROG-HL-32Z".

https://www.pemicro.com/forums/forum.cfm?forum_id=7&forum_topic_id=6523#c18506

The manual for "PROG-HL-32Z" says "PROG32Z is PEmicro’s programming software for Flash/EEPROM modules that are
attached to a 683xx processor." So that says it is the right one.

https://www.pemicro.com/downloads/download_file.cfm?download_id=585

[TomE]

> But I suspect that the database in the backend containing the map registers for the this
> MCU are incorrect, and in turn I have 4 ECUs that have had their internal registers over written.

I don't think so. There are no "internal registers that can be overwritten". There is no storage inside this CPU. There is no internal Flash or EEPROM. The only Flash memory is in chips external to the CPU. It is not possible to "overwrite the internal registers". What IS possible is to replace the external firmware in the Flash so it is now wrong for that hardware, or wrong in some other way.

It is also possible that the Flash memory is partitioned into the Firmware which is never meant to be overwritten and some "Calibration and Engine Mapping Tables" that are meant to be changed to "Tune" the engine. If these have been corrupted or written with something that is wrong for the engine, or so bad that the Firmware can't run properly, then that might explain your problem. There may be external EEPROM on the board that may have been altered, causing a problem.

Concerning the "voltages on the debug pins", they can't be programmed to voltages like you're measuring. They are digital pins. Also, this CPU is so old (1997) that it is 5 Volt Only. There's no 3.3V or 1.2V supplies like newer CPUs use. You can't "measure the voltages with a multimeter", but have to use an oscilloscope. That would probably show you the "bad" ones are stuck at 5V while the "good" ones are oscillating and generating signals that show what the CPU is doing.

In order to "Recover" the CPU you need to know what went wrong. Whether the firmware is OK or not. Whether the calibrations have been changed. In order to load new firmware, you need both a debug pod that can talk to the CPU, AS WELL AS Flash Programming Software. That needs a detailed configuration file that tells that software which Flash chips are on the board, how to program them and how they're connected to the CPU (which chip-selects they're using). If you didn't design the board or don't have the detailed schematics, then you're unlikely to be able to get or create this information. You'll also need Firmware images that can be programmed as well as some default calibration tables.

The Debug Pod can't read the external Flash chips without first programming the Chip Select Registers inside the CPU to access those chips, and it doesn't know which ones to program to what values without being told (via someone looking at the schematics).

There may be licensing or security stuff in there that is designed to prevent people from doing this as well.

This is a problem for the "ECU Flashing Company" to sort out. They're the only ones likely to have enough information to fix this.

Which section of the manual makes you think the DSO and DSI pins are reprogrammable? Table 3.1 shows them as dedicated pins. 4.10.3 tells you what the pins are and how they're enabled to be BDM pins.

This stuff dates from 1997. Debugging wasn't done the way it is now with ARM and Atmel and other chips.

Tom

[GA_TLM]

Hi Tom,

Thank you very much for taking the time to reply, I do appreciate it.

I will need to go through and review in more detail tonight.

At the time I hadn't had the time to go through the manual in detail. So, I had taken the info from a table in section 3 and saw that IPIPE/DSO had an O in the I/O table, which I then incorrectly pieced with a section regarding the QSM having dual function I/O. Not seeing at that time that they were not part of the same system. Rushed reading to to try and understand / support a theory.

This is an example of the flashing software that I was given last week as a known working version. That is what I used to read the 'Good' ECU. But it cannot communicate to non-working version.

This however, is not the actual version that did the damage in the first place. There has been a very new upgrade of a hardware and software based tool that is used quite heavily in that industry. The person that did that job has only recently received it, and this was the first Campi based ECU that he had done with this machine. Hence why I suspect their database containing the addresses for each ECU, is incorrect for this one. Forcing the wrong information into the wrong places. 

The person that originally did the job was able to read it correctly. He then changed 2 options on the map, and then wrote it back to the ECU. Then it couldn't be read again.

So, I am attempting to help mechanics, and the person who did the ECU job for them, work out what happened, as they are very confused. In the hope that they can take that back to the hardware company so they at least have a look at the issue, instead of shrugging the guys off assuming that they did something wrong. These aren't cheap ECU's to replace.

Again, thank you for your time and reply. It has given me enough to mull over and revisit.

Take care,

Gerry

[TomE]

That screenshot says the Micro is an MPC561/562. That's a completely different CPU to the one you're looking at. I hope that's just an "example" showing a different ECU. It would be worth posting the screenshot with it set up to the actual ECU, just to check. Note it is smart enough to know the Micro, the external Flash and EEPROM part numbers. That Bosch ECU (EDC16C39) is used all over the place (Saab, Kia, Fiat, Alfa, Hyundai, Opel).

But that's what I'd expect to see a Flash programmer show. Compare the part numbers it lists for the Campi with the ones you can read from the board for the Flash and EEPROM chips. It may have got that wrong.

For CPUs of that age, the process for reprogramming the Flash should be as follows. The Debug/Programming (same thing) pod asserts the BKPT signal (low) and then cycles the RESET pin. That puts the CPU into the Debug mode. The Debug pod then sends commands to read and write memory locations, which includes the I/O registers. It writes to registers to set up the CPU for normal access to peripherals, and to run the CPU clock at the right speed. Then it downloads a "Programming Kernel" into the on-chip Static RAM (or off-chip SRAM if the board has it). Then it communicates with that code (via in-memory command and data buffers) to erase and program the external Flash.

You said they could "read it correctly" but after reprogramming, couldn't. That tells me the "reading" isn't done by the above method, as it really can't fail. Reading is probably done with some other interface talking to the running code. If that's not working, then the "running code" either isn't running or is configured wrong so it won't or can't communicate. The fact that the debug pins are at a different "voltage" implies the CPU is halted, has executed a halt instruction (after a software problem) or has had a "hardware crash".

Tom

 

[GA_TLM]

Hi Tom,

As always, thank you again, for your time and response.

Here is a screenshot of the the laptop and flashing hardware that I was given by the person who originally did the job. However, this is not the unit that did the flashing. This is his old one, which he was happy to lend to me in order to try and figure out what has been happening. It is the new 12K one that did the damage, and I have not seen. 

I can confirm that the 'EXTFLASH' and 'EEPROM' as identified in this screenshot are correct.

The screenshot above, is of a working ECU provided to me as an example. 

Using this particular hardware and software, I can read and write to the working ECU. But when connecting this hardware and software to the ECU flashed by the other hardware, it gives me an exception error and says that it can't communicate. Both whilst trying to use the read or write options.

With the first process and the other hardware. As I am led to believe, the person doing the ECU job, using the other new hardware, read the data from the ECU. Once downloaded, he then used the software to change the option that is supposed to disable the reading of 2 sensors that are located after the catalytic converters. He then used that same software and hardware to write back the adjusted options. He then handed the ECU's back. They were then put into the car, but the car was unable to start. So, the ECUs were taken back, the programmer 'plugged' them in, but was unable to read them. So, he suggested to the mechanics that they had done something to the wiring that 'fried' the ECUs. At which stage we have 2 dead ECU's. He then provided the mechanics with 2 non-flashed ECU's from the same model car he had at this premises. Those ECU's were placed in the car and seemed to be doing the right thing. Due to the incorrect Lamborghini chassis code being in the ECU software the car wouldn't start. So the mechanics took the ECUs back, said that they looked ok, so the programmer wrote the adjusted software maps to these donor ECU's. They were taken back and placed into the car, then same thing happened, the car wouldn't start, and upon return, couldn't be read by the programmer.

So hence the very tricky part of where and which point. One of the issues being is the ECU's in both cases, were not read back after they had be written. Had this of been done, the programmer may have seen the issue the first time round. However, now at this point, because the ECU's cost 9K each, everyone is extremely hesitant about plugging any ECU into either the programmer in question, or the car in question.

The car has now had all of the wiring tested and it is all fine. All of the incorrect voltages (2.7 and 2.54 volts) that were being seen at different sensors and relay points, were all originating from the 2 ECUs.

Which has made this challenging so far, as details are important, but trying to extract the right ones and trust they are correct. Difficult.

In reading your last 2 paragraphs. It seems that this process has created, at best 4 new 'Door Stops'. I am assuming now, that regardless of the use of the correct hardware such as a PE Multilink FX, there is no fixing this as we don't have, and won't be able to get the original software. At best is the ability to read something from a new ECU flash, in order to try and resurrect the other 4. But, anything read from the new ECU won't complete enough to resurrect the others.

Again, thank you. I do truly appreciate the time you have gifted to me in trying to help me clarify this .

Thanks

Gerry

[TomE]

You could buy the correct P&E Multilink for the CPU together with their "PROG Flash Programming Software". You might be able to read the Flash from a good unit and then try to program one of the bad ones. If it can read the good ones, but can't even talk to the bad ones, then you know the CPU has been damaged.

Here's a "universal test". Are chips on the bad boards getting hotter than the good ones? Or running colder?

How does that KTAG connect to the ECU? Does it connect using the debug port, or does it connect to a communications port on the main connector and in the vehicle loom? I gather it provides options to do both. Which one were you using?

If it connects via the loom, then it needs working firmware to read the Flash. If it only connects to that (and not the debug port), then it must be able to program the Flash via that comms port. If it only connects via the debug port, then it may have damaged the chips somehow if it can't then talk to the CPU to read the Flash. The only way I could see that happening is if it supplied out-of-spec voltages (over 5V) to the debug port.

Some Motorola/NXP/Freescale (name changes and company purchases) chips that have Flash inside the CPU need 8V or 9V applied to one of the debug port pins in order to program the part. Some of the MC6808 variants do this. It is possible the programmer did this when trying to program (applied a high voltage) which could have damaged the CPUs.

If you can buy those CPUs, then it should be possible to get them replaced on those boards.

> All of the incorrect voltages (2.7 and 2.54 volts) that were being seen at different
> sensors and relay points, were all originating from the 2 ECUs

With a meter or an oscilloscope? If they are programmed as outputs and are generating 2.5V and not oscillating, then that indicates the CPU has been damaged. If they're oscillating (you can only see on an oscilloscope, although the AC or Frequency range of a meter might show this) then the CPU may be rapidly running and resetting resulting in those outputs doing that.

> pushing 2.7 volts to some of the onboard transistors instead of ground

That's a valid way to drive transistors. You can have resistors on the board generating 2.7V and have the CPU drive the output to ground when it wants the transistors of. That's unlikely as the transistors would be on during power-on and reset, so there's a problem. Or the 5V output could go through a resistor to turn the transistor on, and after that resistor you might get 2.7V. But don't make too many assumptions.

You should have enough information (or hints as to how to get it) to know if the new hardware damaged the ECUs. If that's the case it shouldn't be your problem now.

For those interested, here's what it looks like. An MC68376 in its natural environment:

https://ecu.design/ecu-pinout/pinout-campi-29f400bb-lamborghini/

Tom

[GA_TLM]

Hi Tom,

I hope you had a great weekend.

Just as an FYI, here is a quick update. Last week I put a scope on various pins around the board and noted that some of the voltages were being oscillated. 

I also noted that the current draw when the board was powered up was around 113 ma which rose to around 172 ma when I tried to communicate with it using the Ktag device.

The CPU was not hot either. 

I have ordered the Multilink FX from Element 14 and am hoping to see that toward the end of the week. Their product page states that it includes software, however, I think they have advertised that incorrectly, so I will cross that bridge once it arrives.

Also, as an additional test as I figured I was in a no-lose position, I removed the flash from the board and tried to communicate with the K-Tag hardware. It changed the outcome from an almost immediate exception to about 5 seconds of communication and a 'Hardware no supported' message instead. So, I took this as another sign that the CPU is still alive.

Again, thank you. I will give you another update just to close the loop once I receive the multilink and attempt to bring one of the ECUs back to life.

Take care,

 Gerry

[TomE]

Oscillating? MHz? kHz? Hz? Different frequencies mean different things.

Is the FREEZE signal on the debug connector asserting or oscillating? Is the RESET signal oscillating? There is a Watchdog Timer in the SIM. That might be programmed and might be continuously resetting the CPU. You should be able to see that (or not) on the RESET pin on the debug connector.

I agree with you that the CPU looks OK. That delay before it said "Hardware not supported" implies it loaded code and was trying to verify that the FLASH chips were the correct type at least.

Tom

[GA_TLM]

Hi Tom,

Update.

I received the Multilink, but as suspected it is just the hardware. I am trying to get in touch with PE to ascertain which version of their Prog32 software is applicable to this processor, as I cannot work out their system.

The reset pin is oscillating at 61Hz.

The freeze pin is asserted low.

Thanks

Gerry

[TomE]

I replied to this days ago, but the reply hasn't shown up. I'll try again.

The "FREEZE" pin doesn't have a slash on it, so it is "high true". So it it is low it means it isn't asserted. Read the CPU chapter in the manual for details. The SIM chapter might give details as well.

The "/RESET" signal (slash over it, represented by a slash before here) means it is low-true. So something is going wrong and it is resetting every 16ms or so. That is likely to be the watchdog, either the internal one or possibly an external one. That suggests the firmware isn't "happy". At least it isn't patting the watchdog! Read up on that in the SIM chapter.

THe version of PROG to use is clear as long as you know that the "683xx" chips use the "CPU32" core. If you download the PROG32Z Manual it says it programs "MC683xx/CPU32" so that's the one. THis also mentions it, and the required pod:

https://www.pemicro.com/forums/forum.cfm?forum_topic_id=5980

Tom

[GA_TLM]

Hi Tom,

Again thanks for the response and info.

I purchased the 32z versions of the Prog and ICD programs and was able to read the ECU and see data, with some of that data indicating that, whilst not the best terminology, the ECU is still intact and resembles what it should.

One of the companies involved from the UK came to the party and decrypted the original file that was read from the ECU at the beginning of the process and has sent that through. 

Which in part shows similar data other than the fact it is in different spots. 

The best example is the beginning of the original file sent from the UK. 

And what is in the ECU.

Which pretty much says it all. 

So, from what I can gather from the PE Prog software I need to convert that original file into an s19 file before I can attempt to push the original back in. It was about 8 years ago that I used code warrior to change some code and fix an air conditioning controller, which was a completely different CPU, and I only used Code Warrior with no need for anything else.

So that's on my learning list for today.

Not sure where about's on the globe you are, but at any rate, happy Friday and I hope you have a great end to the week.

Thanks again and take care,

Gerry