|
vwaudiguy
|
 |
« Reply #45 on: September 24, 2015, 09:44:06 AM »
|
|
|
|
|
|
|
|
Logged
|
"If you have a chinese turbo, that you are worried is going to blow up when you floor it, then LOL."
|
|
|
|
mister t
|
|
« Reply #46 on: September 24, 2015, 12:08:46 PM »
|
|
|
So now that I have a day off I've been doing some homework. I had a look at the processor type and searched out the datasheets for the AMD AM29F800BB series EEPROM and found this online. http://www.datasheet.hk/view_download.php?id=1730503&file=0366\am29f800bb-120ee_3262036.pdfNOTE there was a supplementary publication added with respect to unprotecting and writing data sections http://www.spansion.com/Support/Datasheets/Am29F800B_prog.pdf NOTE, as Nyet posted, PIN 44 HAS NOTHING TO DO WITH BOOTMODE. I'm just leaving this up in case someone finds a use for the info. The Am29F800B is an 8 Mbit, 5.0 volt-only Flash memory organized as 1,048,576 bytes or 524,288 words, designed to be programmed in-system with the standard system 5.0 volt VCC supply.PIN LAYOUT AND CONFIGURATION  Pin layout cont...  DEVICE PROGRAMMINGDevice programming occurs by executing the program command sequence. This initiates the Embedded Program algorithm—an internal algorithm that automatically
times the program pulse widths and verifies proper cell margin.DEVICE ERASUREDevice erasure occurs by executing the erase command sequence. This initiates the Embedded Erase algorithm—an internal algorithm that automatically
preprograms the array (if it is not already programmed) before executing the erase operation. After a program or erase cycle has been completed, the device is ready to read array data or accept another command.DATA PROTECTION MEASURESHardware data protection measures include a low VCC detector that automatically inhibits write operations during power transitionsREADING ARRAY DATATo read array data from the outputs, the system must drive the CE# and OE# pins to VIL. CE# is the power control and selects the device. OE# is the output control
and gates array data to the output pins. WE# should remain at VIH.WRITING COMMAND SEQUENCETo write a command or command sequence (which includes programming data to the device and erasing sectors of memory), the system must drive WE# and CE# to VIL, and OE# to VIH.HARDWARE RESET PINThe hardware RESET# pin terminates any operation in progress and resets the internal state machine to reading array data. The RESET# pin may be tied to the system reset circuitry. A system reset would thus also reset the device, enabling the system microprocessor to read the boot-up firmware from the Flash memory. The RESET# pin provides a hardware method of resetting the device to reading array data. When the system drives the RESET# pin low for at least a period of tRP, the device immediately terminates any operation in progress, tristates all data output pins, and ignores all read/write attempts for the duration of the RESET# pulse. The device also resets the internal state machine to reading array data. The operation that was interrupted should be reinitiated once the device is ready to accept another command sequence, to ensure data integrity.
Current is reduced for the duration of the RESET# pulse. When RESET# is held at VIL, the device enters the TTL standby mode; if RESET# is held at VSS ± 0.5 V, the device enters the CMOS standby mode.
The RESET# pin may be tied to the system reset circuitry. A system reset would thus also reset the Flash memory, enabling the system to read the boot-up firmware
from the Flash memory.
If RESET# is asserted during a program or erase operation, the RY/BY# pin remains a “0” (busy) until the internal reset operation is complete, which requires a time of tREADY (during Embedded Algorithms). The system can thus monitor RY/BY# to determine whether the reset operation is complete. If RESET# is asserted when a program or erase operation is not executing (RY/BY# pin is “1”), the reset operation is completed within a time of tREADY (not during Embedded Algorithms). The system can read data tRH after the RESET# pin returns to VIH. When the system drives the RESET# pin low for at least a period of tRP, the device immediately terminates any operation in progress, tristates all data output pins, and ignores all read/write attempts for the duration of the RESET# pulse.SECTOR PROTECTION/UNPROTECTION The hardware sector protection feature disables both program and erase operations in any sector. The hardware sector unprotection feature re-enables both
program and erase operations in previously protected sectors.
Sector protection/unprotection must be implemented using programming equipment. The procedure requires a high voltage (VID) on address pin A9 and the control pins.TEMPORARY SECTOR UNPROTECTThis feature allows temporary unprotection of previously protected sectors to change data in-system. The Sector Unprotect mode is activated by setting the RESET# pin to VID. During this mode, formerly protected sectors can be programmed or erased by selecting the sector addresses. Once VID is removed from the RESET# pin, all the previously protected sectors are protected again. Figure 1 shows the algorithm, and the Temporary Sector Unprotect diagram shows the timing waveforms, for this feature.HARDWARE DATA PROTECTIONThe command sequence requirement of unlock cycles for programming or erasing provides data protection against inadvertent writes (refer to the Command Definitions table).
In addition, the following hardware data protection measures prevent accidental erasure or programming, which might otherwise be caused by spurious system level signals during VCC power-up and power-down transitions, or from system noise.Low VCC Write InhibitWhen VCC is less than VLKO, the device does not accept any write cycles. This protects data during VCC power-up and power-down. The command register and all internal program/erase circuits are disabled, and the device resets. Subsequent writes are ignored until VCC is greater than VLKO. The system must provide the proper signals to the control pins to prevent unintentional writes when VCC is greater than VLKO.Write Pulse “Glitch” ProtectionNoise pulses of less than 5 ns (typical) on OE#, CE# or WE# do not initiate a write cycle. Logical InhibitWrite cycles are inhibited by holding any one of OE# = VIL, CE# = VIH or WE# = VIH. To initiate a write cycle, CE# and WE# must be a logical zero while OE# is a logical one.Power-Up Write InhibitIf WE# = CE# = VIL and OE# = VIH during power up, the device does not accept commands on the rising edge of WE#. The internal state machine is automatically reset to reading array data on power-up. |
|
|
|
« Last Edit: September 24, 2015, 01:01:29 PM by mister t »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #47 on: September 24, 2015, 12:12:09 PM »
|
|
|
The flash datasheet has nothing to do with boot mode.
The purpose to grounding DQ4 is to notify the CPU to start in boot mode.
The flash never sees it during boot.
If you want to know how bootmode works, consult the CPU datasheet.
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #48 on: September 24, 2015, 12:16:42 PM »
|
|
|
DATA PROTECTION MEASURES
Hardware data protection measures include a low VCC detector that automatically inhibits write operations during power transitions
I assume that's what Nyet was referring to when he said If the pin is still low after the CPU is booted, bad things will happen, the CPU will not be able to communicate with the flash chip, as now that signal pin is stuck at 0V.
No. Now here's where I get a little puzzled
***NOTE: THE FOLLOWING COMMENTS HAVE NOT BEEN PEER REVIEWED AT THIS TIME AND SHOULD NOT BE TAKEN TO MEAN THAT PIN 44 IS THE ONE THAT PUTS THE EEPROM INTO BOOT MODE****
HARDWARE RESET PIN (#44)
The hardware RESET# pin terminates any operation in progress and resets the internal state machine to reading array data. The RESET# pin may be tied to the system reset circuitry. A system reset would thus also reset the device, enabling the system microprocessor to read the boot-up firmware from the Flash memory.
I will assume that this is referring to boot mode.
No. OK, so on one hand, the datasheet states that When the system drives the RESET# pin low for at least a period of tRP, the device immediately terminates any operation in progress, tristates all data output pins, and ignores all read/write attempts for the duration of the RESET# pulse.
That suggests to me that the RESET# pin will interfere with a read/write attempt as it states that the device will ignore all read/write attempts. But then it goes on to state that it is for the duration of the RESET# pulse
So does that mean that the RESET# pulse is a momentary interruption, after which the device will accept read/write commands? Hopefully someone with some knowledge in the area can clarify this.
Has nothing to do with boot mode. What's worth noting is that there appears to be some sort of high voltage (VID) requirement for the RESET# pin during the sector unprotect mode. Since it's my understanding that you only need to externally change the voltage to the EEPROM for a few seconds when you ground pin 24 and power it on, not for the entire write sequence does that mean that the voltage change to the RESET# pin is taken care of by functions elsewhere in the ECU and that we're not supposed to touch pin 44 at all?
I'm going to speculate that's the case and we shouldn't be touching pin 44 as it would be odd to design an EEPROM that would require you to manually alter the voltages during a write sequence. Again, if someone can comment on that, I would appreciate it.
No. Pin 44 has nothing to do with boot mode. |
|
|
|
|
Logged
|
|
|
|
|
mister t
|
|
« Reply #49 on: September 24, 2015, 12:27:10 PM »
|
|
|
Well, glad I didn't waste 3 hours of my life making that post...  No biggie though, I always end up learning something from these kind of exercises. I'll retract my comments so as not to confuse matters. Not sure if you want me to pull the entire post lest anyone gets confused, let me know either way. Cheers |
|
|
|
« Last Edit: September 24, 2015, 12:32:20 PM by mister t »
|
Logged
|
|
|
|
|
mister t
|
|
« Reply #50 on: September 24, 2015, 12:38:51 PM »
|
|
|
Edited out commentary and just left summary
Now, do you happen to know of any links to the CPU datasheet?
EDIT: nevermind, found it in the S4wiki
|
|
|
|
« Last Edit: September 24, 2015, 12:53:26 PM by mister t »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #51 on: September 24, 2015, 01:09:02 PM »
|
|
|
You're looking for page 16
"The PORT0 configuration is treated as if it were a hardware reset. In particular, the
bootstrap loader may be activated when P0L.4 is low."
Flash pin DQ4 is connected to CPU pin P0L.4 (port 0, bit 4).
|
|
|
|
|
Logged
|
|
|
|
|
adam-
|
|
« Reply #52 on: September 24, 2015, 01:25:55 PM »
|
|
|
I feel this thread is getting way too complicated.
1. Everything connected, power switch on the +12V wire coming to bench harness in off position
2. Ground pin24 to ecu board edge
3. Flick power switch on
4. Keep pin24 grounded for a second or two
5. Remove pin24 ground wire
6. Get boot-mode
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #53 on: September 24, 2015, 01:33:07 PM »
|
|
|
I feel this thread is getting way too complicated.
1. Everything connected, power switch on the +12V wire coming to bench harness in off position
2. Ground pin24 to ecu board edge
3. Flick power switch on
4. Keep pin24 grounded for a second or two
5. Remove pin24 ground wire
6. Get boot-mode
I think the point here is that the original poster wants the why, not just the instructions how. I think that is a good thing. |
|
|
|
|
Logged
|
|
|
|
|
mister t
|
|
« Reply #54 on: September 24, 2015, 02:46:26 PM »
|
|
|
Thanks Nyet  You're correct. While I definitely appreciate all the responses to my immediate concerns about how to re-flash on the bench, I feel that it's way more useful to learn the ins and outs of an area rather than just expecting others to spoon feed me answers every time something goes wrong. I also get a real sense of satisfaction if I can contribute back to any community that I'm a part of. Unfortunately I'm in a position where I'm starting from scratch here, but thanks to people like yourself, NOTORIOUS VR, etc... at least I have an opportunity to actually learn some of the how's and why's of tuning and electronics. I'm also mindful of the fact that you and the other mods/admins take a lot of time to make sure that this site doesn't get polluted with a bunch of misinformation and speculation. I'm also mindful that it takes time out of your schedule to read through everyone's posts to screen that info, so I'll try not to flail out too hard (well any harder than I've already been flailing out lol.  ) On a bit of a side note, I found it incredibly frustrating just how little GOOD and RELIABLE information there has been about Bosch tuning until this forum started up. So I'm hoping that by getting myself up to speed on this stuff I can make my own contributions back to this forum. So at the risk of sounding like a broken record, big up to everyone here on this forum who has and will take the time to educate myself and others. *thumb up* PS: To Nyet and others, I can't remember if I told you that my alter ego on Audizine is Zimbuthemonkey. If not then, well... Hiya |
|
|
|
« Last Edit: September 24, 2015, 02:57:10 PM by mister t »
|
Logged
|
|
|
|
|
mister t
|
|
« Reply #55 on: September 27, 2015, 02:44:30 AM »
|
|
|
So, update time:
I managed to exchange the ME7.1 ECU I fried for another ME7.5 ECU I pulled out of a 2004 A4
Using the method explained (grounding to the strip on the side of the ECU) I managed to get the ECU into bootmode successfuly.
Using an Ebay VAG-COM cable (and my genuine ROSSTECH one) I confirmed that ECU was working by connecting to it with VAG-COM. It connected fine.
I should add that I've been using the Galletto software from this site, re-coded with the correct serial number for any Galletto related flashing. I also use Argdub's software for any immobilizer related flashing and reading
Then, I put the ECU into bootmode and used Galletto to 1) get a read of the EEPROM, 2) to get a read of the immo coding and 3) and to flash my stock 559E file to the new ECU.
It read and re-flashed the EEPROM fine as well as reading and flashing an immo off 95040 file.
The issue that concerns me is that, much like all the other ECU's. I couldn't connect back to it with VAG-COM or the Nefmoto flashing software after I did the bootmode related stuff.
I should also note that my cable has been set to work in 'dumb mode', just to rule that out.
Any thoughts on this? Like I said, it reads fine in bootmode, but it won't connect otherwise. I'm hoping it's just a byproduct of flashing an ME7.1.1 file to an ME7.5 ECU and something that I did to wreck the ECU,
I want to get this resolved before I get my replacement ECU on Monday. Honestly, after weeks of dicking around with this, I just want my bloody car back :p
PS: this seems to be a common thread between all the ECU's I've been experimenting on. Is there any possibility that this is just a 1) communication/flashing issue or 2) immobilizer issue and that the hardware on my other ECU's may be recoverable?
|
|
|
|
« Last Edit: September 27, 2015, 02:49:27 AM by mister t »
|
Logged
|
|
|
|
hopsis
Full Member
Karma: +13/-4
 Offline
Posts: 174
|
|
« Reply #56 on: September 27, 2015, 02:56:57 AM »
|
|
|
You can't just swap different ecus, they aren't compatible. Hell, You can flash a picture of Your neighbours dog to the ecu in bootmode but it won't communicate with the car or read with Nefmoto or VCDS afterwards.
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #57 on: September 27, 2015, 09:02:46 AM »
|
|
|
ME7.1.1 file to an ME7.5 ECU
This is never possible. Even ECUs of the same ME version aren't always cross flashable. |
|
|
|
|
Logged
|
|
|
|
|
mister t
|
|
« Reply #58 on: September 27, 2015, 12:14:42 PM »
|
|
|
Just to clarify, I wasn't intending to use the ME 7.5 ECU in my car lol.
It was the only other good ME7x ECU that I could exchange with the one I bricked (Pick and pull doesn't give refunds, just exchange for the same part).
This purpose of this exercise was simply to confirm that my flashing process isn't frying anything.
Given that I can still access the ECU multiple times over, I'll take that as a good start.
However, back to my other question. Interestingly enough, I can still read the EEPROM contents on my original A4 and S4 ECU's as well as flashing the 95040 contents.
What I cannot seem to do is write to them. Again, I'm going to assume that I must have fried something downstream of the EEPROM which has damaged ECU's abiliity to function. That said, I just want to rule out a memory related issue (i.e. immobilizer and the like).
Would I be correct in my assumption that even though the ECU's can be read, that I have probably damaged the CPU with my previous boot mode attempts?
|
|
|
|
|
Logged
|
|
|
|
|
ddillenger
|
|
« Reply #59 on: September 27, 2015, 12:35:40 PM »
|
|
|
I have a big box of dead ecus from bad boot attempts that still will run in bootmode, read and write. Just no comms.
|
|
|
|
|
Logged
|
Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience!
Email/Google chat:
DDillenger84(at)gmail(dot)com
Email>PM
|
|
|
|
