Page 2 of 7 FirstFirst 1234567 LastLast
Results 16 to 30 of 103

Thread: Next EEHack update

  1. #16

  2. #17
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    test bench is alive and better than ever! only t-side is socketed.... my heat gun bit the dust so i decided to use a torch. do not recommend it!! lost not only the original chip but also two traces for address lines and had to do a bit of totally unorthodox stuff under that socket to restore contact.

    stay tuned!

    IMG_1329.jpg

  3. #18
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    It is getting interesting. Glad you didn`t cripple the pcm permanently.

    Since you are still on the file conversion I think that adding support for the 96-97 lt1 tside files to convert between raw dump and good bin will be the awesome.

    Some one will have to upload raw dumps. It have bank switching. The first 32kb are constant and than you have 2 32kb parts that can be switched over.
    It is something like this

    32kb[0] + 32kb[1] +32kb[2]

    the processor can see
    32kb[0] + 32kb[1]
    or
    32kb[0] + 32kb[2]

  4. #19
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    you can always fix a trace. i wouldn't use it in a car again.

    i'll do anything for any bin converter you want, just need the right data

    ... but i have other priorities
    .... like these crazy obd-ii ecms that showed up at my workplace that i think i'm expected to make an awesome flash tool for (and will)

    stay tuned

  5. #20
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    one thing i did today is test how eehack behaves if the serial interface becomes unstable (basically i grounded the hell of out the serial interface) and it's not good.

    i am really excited to work on failure logic like 'if flash fails, we can keep retrying until it's better as long as ecm does not get powered down'.

    but i started thinking

    one thing that came to mind though is we have this 512 byte onboard programmable rom just sitting there (you know, 0x0E00 to 0x1000)... basically unused on the e-side and used really for the vin number and cal id on the t-side.. and if anything bad happens to it, it still runs.

    i'm thinking it might be cool to abuse it as part of the flash routine? i'm trying to figure out if there's a clever way to do that..

    maybe the first thing we do is write a mini-kernel to that area. then we sneak a jump from our normal bin's entry point in there...

    when the routine is finished we write that jump so it goes back to whatever is after the ordinary entry point... the idea is if the ECM powers off during a flash before it's complete, it immediately jumps back there to the onboard eeprom, and we can then recover the routine and try again...

    basically we guarantee that either successful flash executes our normal eeprom, and unsuccessful flash executes that 512b area.. so no matter what, we end up with an ECM that communicates enough to reflash.

    what do you think?

  6. #21
    Fuel Injected!
    Join Date
    Sep 2012
    Location
    Huntsville, AL
    Posts
    237
    Great idea... but can you flash only that ROM first without flashing the rest of it? And what forces it to go looking in that particular ROM for instructions if the rest of the memory is blank?

  7. #22
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    The last 2 bytes of the bin are the pointer that is executed at reset or at power on. We can leave the last 2 bytes programmed at the very end of the flash process.

    Too bad these 2 bytes can`t be erased or programmed on their own. There is no way to be overwritten either. The only usage that I can think of is to load some basic code at eeprom area and if something is not allowing the flash to complete, write the last 2 bytes will pointer to the eeprom code. Than on reset only the code from eeprom will be runned and the pcm can be recovered. Now programming to eeprom is a little weird and needs some specific sequence to do it.

    I am not sure how much free space we have there. the eside use some part of it for oil change data. And we have to put some processor initializing code to configure registers and ram.

    I think the first step is make the flash routine run indefinite and the write application can pick the flash routine on some form of recovery mode, and when the flash is interrupted by pc or cable failure we can continue the flash with new cable and new PC.

  8. #23
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    Great idea... but can you flash only that ROM first without flashing the rest of it? And what forces it to go looking in that particular ROM for instructions if the rest of the memory is blank?
    interesting question. i have a few ideas about that.

    Too bad these 2 bytes can`t be erased or programmed on their own.
    i knew you'd say that. i have two theories for having a safety switch via the reset vector and maybe using the onboard eeprom

    after the erase, we can temporarily use 0xFF?? or 0x??FF as our reset pointer. then when finished we write those FF bytes to complete the sequence. i wouldn't be afraid to patch an extra JMP 0x7E in the uploaded bin to make all this work, so we have two execution loops. one for failure during flash, then we set it back to normal with our last instruction.

    idea two.....the location of the onboard EEPROM can be remapped when it's reprogrammed. it contains a 4 bit config register specifying its location as 0x?E00 to 0x?FFF on init. setting that nibble to F relocates the onboard eeprom to 0xFE00-0xFFFF which then, on reboot, contain the reset vector so you can boot in 'single chip mode' independent of the external eeprom. if we could then restore its contents, and reboot, it would move back where it belongs.

    it's a bit scary to test. if it does work, but we end up with no way to change the config register back, it's in a bad state. you can't de-socket and reflash the cpu onboard eeprom to fix that config register (you can snip some pins and get it into bootstrap/serial mode but that's not something you want your users to do). but if it did work out, we'd have an ecu that boots on its own, temporarily, without relying on the flash chip or the temporary kernel in ram, like our own bootstrap mode, which would be incredibly safe - we could make the ECU rebootable, THEN flash.

    might not be necessary, but fun to think about, and it would be nice to recover from ECM power failure in most states.

    all of this would require downloading the contents of the onboard eeprom, saving them in the program, and putting them back after (worst case is you lose your vin and cal ID,which isn't very important anyway)

    I think the first step is make the flash routine run indefinite and the write application can pick the flash routine on some form of recovery mode, and when the flash is interrupted by pc or cable failure we can continue the flash with new cable and new PC.
    i agree that should be the priority and that's what i'm working on now.

  9. #24
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    The eeprom hack will be too much work with no clear end. Tside also have some data there that should be reconfigured. Otherwise boot loader in the eeprom area will make the pcm bulletproof. I am no sure we can squeeze there all the needed data.

    Now base on your ideas I figured the most efficient way to do it. It will take writing some small area before the flash fails to make it recoverable.

    The plan is to make a jump at the beginning of the reset routine, after the initialization is done, that will check 2 secret bytes for integrity the 2 secret bytes will be the last thing the flash routine will write, If they don`t much[the flash failed] I will make the code jump straight to the mode 5 upload loop. That way you can upload the flash routine and nothing else will run on the pcm.

    To do this we will need to write selective areas of the flash first, some small portion of the reset code, and the scssi code. and some small patch for the check. No other stuff is needed and will be really easy to work with.

  10. #25
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    yeah... i was also looking at the routine again last night and trying to fit it into the onboard eeprom might not be possible considering all the extra init code that we don't have to deal with in the flash kernel. i wasn't realizing that because cpu is already initialized, and all we're really doing is executing a new loop, there's way more than just a kilobyte of kernel there if we have to start from a cold boot. so i am also scrapping the idea.

    your solution sounds great. my original idea was to map out areas of executable code and write all the code first. if we can use a switch we'll be in really good shape and can probably make the ECM recoverable in only a few write commands. i'll need your help with init as i don't know much about it.

    my testing so far seems to show that the biggest failure point is the erase cycle. as long as we can erase the chip, we can probably manage to succeed with writing at least long enough to keep trying. right now if erase fails, something in eehack or the kernel seems to screw up and it fails to retry as intended and i'm not sure why yet. i plan to force erase errors by removing VPP halfway or something and make sure it continues to retry. if it can't re-erase while still booted, no recovery will work.

    i plan to work on checksum logic to ensure that the kernel to tool logic is correct in all cases, to ensure a corrupt packet is never actually written and always retries. that way even with a noisy aldl bus, flash should succeed but be very slow.

    i am thinking that this could lead to recovery without re-erasing. maybe we do a READ first to compare with the bin, and if it matches, we can CONTINUE rather than RETRY... ? i will have a map of written and unwritten bytes to help with logic like this (1 bit per byte) but not sure if it'll work.

    i'm just going to throw this out there too....... and if this doesn't give you ideas about how we can flash faster, something is wrong with you.

    https://www.bigmessowires.com/2016/0...decompression/

  11. #26
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    So we have to focus on 2 things. Make erasing much safer, now if it gets an error during erase it is usually fatal. I haven`t looked deeper in the erase code but it might freeze the processor if anything goes wrong.

    The 1 reason for write failure is the load on the cable at max size message. When it switches to low speed I managed to flash without issues with bad cable. A logic to implement variable length message will save a lot of pcms. It will be relatively safe to load the recovery portion at really low speed and than bump the speed and if errors occur progressively cut it down, when it recovers, progressively increase it. The rule should be as simple as possible of flashing. A write config file with opcode steps might prove flexible enough so you don`t have to hardbuilt it and add flexible support for any future improvements.

    I will make you a test tside bin with only recovery code to start experiments.

  12. #27
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    awesome. i will only work with the tside for testing anyway (i don't feel like doing a second socket with my MAP gas torch)

    im going to start writing a proper 'debugging' flash routine and rewrite the communication layer for my new flash tool for testing.. i need it to be a bit simpler but also more object oriented so we can reuse some of the advanced logic and data structures i'm planning for other platforms.

    i already have the code to control the flash block write size in EE and it already does reduces the block size on failures, as i figured the same thing out years ago when we both worked on this, but im not sure it works too well. on a checksum failure i want to both decrease the packet size, and increase the delay.

    to be honest the biggest problem is i had all these ideas on how to handle failures, but i never did test many of them since my car and my bench harness never had a lot of failures. i should have SIMULATED failures, then code around them. that's what i'm planning to do a lot of now.

    i want it to be fast, but if the bus is unstable, go slowly and succeed, and it fails, keep the loop running so the person just has to keep ECM power until they figure out what's wrong with their cable and laptop.

  13. #28
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    i've made a bit of progress on the design side, i planned to copy some of eehack, but is too much of a mess and the code is not built in effective layers.. in fact there are parts that make no sense even to me (and i wrote them).

    this new tool will have a much better async interface with callbacks and proper request tracking, more like a network layer than a serial communication one. it'll have one 'interface' layer for managing the physical communication with the bus that deals with connection states and request/reply/timeout stuff on its own

    then we'll have a data class for messaging that's really basic but can contain abstract device ids and callbacks.

    so from the programmer's perspective we can make a 'message' which also contains instructions on what to do when the reply is received (usually another function call) and that receiving function will have access to (via the reply message) the original message, the reply, and a flag indicating success.

    i'll have another data class for vehicle types to help match up vehicles to interfaces, and the interface can use that vehicle info to modify its connection type, since every damn vehicle is a bit different.

    if you haven't got the idea yet, i'm building this to support more than just 8051 ecms and 8192 baud comms, and don't want to have to keep writing similar code over and over

    it might be a bit overkill but i expect to have it working soon-ish

  14. #29
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    this is the region to write to tside

    4269-4314
    b7e4-be89
    ee96-eed0
    ff86-ffff

    patch to apply to bin before writing


    [4311]
    bd ff 86

    [ff86]
    15 02 40 fc ff 84 27 03 7e b9 fa 39


    That should be enough for the tside to boot to mode 5 loop and can accept flash routine upload.
    The checkword that should be written last is at ff84 and should be $0000

    If ff84 is $0000 the pcm will boot to normal mode
    If ff84 is not $0000 it will boot to mode5 loop.

  15. #30

Similar Threads

  1. EEHack 5.0 2020 update
    By steveo in forum GM EFI Systems
    Replies: 9
    Last Post: 09-30-2022, 06:37 AM
  2. EEHack 2019 update
    By steveo in forum GM EFI Systems
    Replies: 154
    Last Post: 02-20-2020, 05:31 PM
  3. $4D update
    By steveo in forum GM EFI Systems
    Replies: 4
    Last Post: 07-19-2014, 09:33 PM
  4. Tables won't update
    By POZE in forum TunerPro Tuning Talk
    Replies: 2
    Last Post: 02-17-2013, 09:48 AM
  5. TunerPro V5 update!
    By EagleMark in forum TunerPro Tuning Talk
    Replies: 27
    Last Post: 07-16-2012, 02:42 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •