ffb0 = 7e f4 26 [jump to loc_f426]
Now I figured why it didn`t worked.
You need to execute here at ffbo. I was loading ffbo as an index and the jump was to 7ef4 instead of loading f426 and jump there.
Current code may work if you change ffb0 with ffb1, or change it and make it execute at ffb0.
You can try changing fe ff b0 to
1. CE FF B0
or
2. FE FF B1
Last edited by kur4o; 10-17-2021 at 11:03 AM.
makes sense thanks.
i disassembled that aldl message routine too, i had overlooked it before
im going to run some experiments writing the onboard eeprom on EE, wish me luck.
if successful we could relocate some tables there for "quick tuning" that would be safer/faster
my idea is to just write both eeproms as part of the regular flash procedure
might also be possible to bake this code into EE itself so we can update eeprom values over aldl for some true realtime tuning (since we cant run mode 6 with engine running) but not sure if anyone would be interested in that.
Realtime tuning through eeprom tables is very good idea, but I doubt we can write there while engine is running.
We can write some unique identifier on each flash to manage version of bins. I will think more about it how we can use it.
I already did some patches that will alocate some tables to ram, main ones are ve and maf, but there is a lack of good interface to update it. It will be awesome if you make some better interface. Now you need to select single cell in a row/column and put a value.
im thinking updating it while running will work im theory but some trickery might be necessary
if that doesn't work we can certainly have a good method for very quickly updating some relocated tables with zero risk without engine running. and those changes will be persistent
well, a bit of discovering my own bugs and i got this working really well on EE, and so it should only need a slight tweak to work with the CCM.
still need to fully implement it so it reads/compares the bin, but it's really cool to be able to program stuff to the onboard eeprom of the ECM
i think once we find a use case for it, WAY more cool than fixing a CCM, so this research has had a really positive side effect
proof of concept:
Code:DEBUG::Sending raw command: DEVICE=F4 COMMAND=2 DATA=0E90 Got reply to command: DEVICE=F4 COMMAND=2 DATA=BEEFBEEFBEEFBEEFBEEFBEEFBEEFBEEF
Last edited by steveo; 10-18-2021 at 01:05 AM.
Great work so far.
Adding tables to eeprom will be a matter of just changing table lookup address. so it will be a permanent setting. One drawback will be that writing bin will not update the table only eeprom write will do it. Anyway some good interface will be needed for the table update.
Really cool ideas.
I like your thinking and don't intend to rain on your parade, but...
Just "riffing", here are a few pitfalls I think you might run into in practice:
1) When the PPROG register is not cleared i.e. during erase / programming, the datasheet seems to indicate the eeprom cannot be read just like ROM. What will happen? Test it and find out?
2) Bad things could happen if during an erase + write procedure the PCM needs to read something from a cell of a relocated table for instance like spark advance, and does so immediately after an erase, but before the subsequent program (eeprom contains #$FF). Switching off the table relocation temporarily would remedy this and pitfall #1.
3) I know almost nothing about how the two $EE programs work, but to draw a parallel to my diy-ltcc firmware I'm almost certain bad things would happen if you blocked the main loop for 10 ms (a write or erase cycle) while the engine was running. You'd need access to a timer / counter here to prevent holding up time-sensitive processing (aka starvation).
All in all though, still not a bad idea in theory. I don't know what tables could functionally be relocated to eeprom, but tuning tables like VE and spark this way would certainly reduce the need for slower and slightly more hazardous flash erase + programming cycles. I use the qualifier "slightly" because it seems flashhack is nearly bullet and idiot proof.
Edit: After some more tuning oriented thought, there are probably a half to nearly a dozen different constants that would be incredibly useful to have control over and would likely be extremely benign if fed transiently anomalous data. Injector flow constant, cylinder volume, prime pulsewidth multiplier, probably four or five I haven't thought about in two years. If easily relocated, those would be very useful for injector swaps and extreme VE / displacement changes.
Last edited by spfautsch; 10-19-2021 at 05:06 AM.
i don't think we have to worry about anything reading from the eeprom while we are writing it , the big concern is interrupting things by 10 or 20 ms for sure. that delay probably needs to be reconciled and it might not be worth the effort. it could be done though. i do wonder what actually happens if you try to read while elat is set. i will experiment.
i think just being able to tune things on the eeprom would be cool enough. we could be doing spark table updates in a few seconds.
Does this mean you know what the missing parts of the $41 message represent? Specifically what each of the bits in the two status bit bytes are referring to, and what the last several bytes represent? I assume the last several bytes have something to do with the automatic transmission since they're missing on $DA2 and don't appear to do anything on manual $EE cars.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
does anyone have any arguments about bit level programming a probably flotox style eeprom
for example we have FF and program it to AA, obviously okay, but how about an AA to a 00?
my tests say okay but my hunch says "uncharted"
im a bit more familiar with block flash rather than this old single byte stuff.
im going to start to implement it. i cant make it fail in tests and ive run a few hundred iterations of erasing then zeroing a bit at a time and it seems to stick. i just hope there isnt some stuff electron level physics reason its a bad idea.
Bookmarks