Page 8 of 10 FirstFirst ... 345678910 LastLast
Results 106 to 120 of 148

Thread: OBD2 LT1 XDF $EE EEX creation

  1. #106
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    Why don`t just make a bootstrap flash mode in flashhack and collaborate the effort with Tom H for easy recovery.

    It is still serial comm and the same ftdi adapters can be used. The bootstrap flashing will use very slightly modified version of 94-95 flashing routines and it will be just uploading the code in bootstrap and flash in bootstrap.

    The only addition to existing code will be entering bootstrap mode and wiring the cable to the pcm board.

    So Steveo had the high level program interface and Tom H has the low level code and bootstrap sequence. That way it can work for 96-97 too without bothering with vpw communication.

  2. #107
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    i am just reading about bootstrap mode and it's really interesting, i think i can help get this working.... and might be way easier than i thought

    is this correct?

    - ground MODB to enter bootstram rom on reset
    - power up the whole rig
    - set the SCI baud rate with a byte of 1s or 0s. FF=low baud 00=high baud (should be 8192 with this processor, right?)
    - transmit your code from 0 offset
    - handle the echo (actually i think we'll get a double echo if we've tied tx/rx together, not sure how that'll look).
    - wait for timeout and it'll execute from 0x0000

    there are a few trivial things i'm curious about after looking at bootstrap mode

    it seems that in bootstrap mode the onboard EEPROM is forcibly relocated to 0xFE00 to 0xFFFF and there's not much that can be done about it. i guess that wont affect writing...? but that'll give us a nonsense reset vector. i do have functions in my flash tool that expect to be able to read the onboard eeprom at 0x0E00, but that's ok, they'll just read zilch from RAM and no harm done.

    is the COP timer available during bootstrap mode...? if it does crash what reset vector does it use? does it use 0xFFFE like normal, so in actuality it's going to use whatever is in the onboard eeprom? it'll try to jump to FFFF which contains FF and will probably just lock up. the existing method we use for rebooting the ECM is just tripping the COP timer so obviously it wont reboot successfully but that's no big deal.

    does anyone know what happens if you un-ground MODB while the processor is running?

  3. #108
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    Quote Originally Posted by kur4o View Post
    The bootstrap flashing will use very slightly modified version of 94-95 flashing routines and it will be just uploading the code in bootstrap and flash in bootstrap.
    modified in what way?

  4. #109
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by kur4o View Post
    That brings a good point. The vpp is applied by tside only, I guess the relay transistor is wired there and the voltage goes to both sides. Now can we apply vpp from tside, while flashing eside. I guess we need to bootstrap both sides and than do the flashing.
    I believe that the VPP is generated on the ESide by the small 8pin part center just below the heat spreader bar. I have not yet done a schematic for the Eside and do not know the part number for that VPP regulator. I believe it is a buck configuration and makes use of at least one of the transistors next to it. I need to trace it. In my case, the ribbon cable is cut and I just applied vpp through a resistor. That's how I tested the a/d function and replies of the code. I thought (hoped?) that the control for the regulator was or tied between T&Esides. I need to look at this more.

    -Tom

  5. #110
    Fuel Injected!
    Join Date
    Nov 2017
    Location
    Californiacation
    Age
    57
    Posts
    811
    Quote Originally Posted by kur4o View Post
    Why don`t just make a bootstrap flash mode in flashhack and collaborate the effort with Tom H for easy recovery.

    It is still serial comm and the same ftdi adapters can be used. The bootstrap flashing will use very slightly modified version of 94-95 flashing routines and it will be just uploading the code in bootstrap and flash in bootstrap.

    The only addition to existing code will be entering bootstrap mode and wiring the cable to the pcm board.

    So Steveo had the high level program interface and Tom H has the low level code and bootstrap sequence. That way it can work for 96-97 too without bothering with vpw communication.
    Yes please,Steveo, if you can whip me/us up a quick test version we might have an answer shortly before I head to the shop today or I will do some testing when I get home, I only have a '96 here to test on though.

    Quote Originally Posted by steveo View Post
    does anyone know what happens if you un-ground MODB while the processor is running?
    There was a reason I was asking someone to test the pin for flashing CEL and it wasn't for checking codes
    -Carl

  6. #111
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by steveo View Post
    yeah you cant apply vpp from the eside at all
    back to my original thought
    bootstrap the dead side with the entire kernel then just let flashhack do its normal thing over aldl. no need to bootstrap both sides
    the chances of both sides being bricked are near zero
    Please confirm... You think the Tside turns on VPP through the port replacement part port a bit 7?

  7. #112
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by steveo View Post
    just out of curiosity, is there any way to bootstrap the chip over the regular ttl serial pin that aldl uses? or is it a different pin entirely

    in other words can you upload the bootstrap program from the aldl port?
    Can't use ALDL i/o in bootstrap. The internal rom echos received data this would get looped back and mess the load. One concern I have is making sure that the aldl driver chip doesn't mess things when turned off.

    definitely would need a tweak on the tool side of things, but otherwise looks harmless. i'd just put ignition voltage in there, since if that's out of range, that is something the user is able to solve. knowing the vpp voltage might be academic, as good battery voltage should mean good vpp voltage unless there's damage to the ECM itself. the only person that's ever reported the vpp voltage out of range error to me opened his ECM and found it full of moisture damage.
    Agree, but it does tell you that & more info is always better in my estimation. Cost is one byte = no time.

  8. #113
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by kur4o View Post
    That way it can work for 96-97 too without bothering with vpw communication.
    Yes that is what I think will work easy.

  9. #114
    Fuel Injected!
    Join Date
    Nov 2017
    Location
    Californiacation
    Age
    57
    Posts
    811
    Steveo,
    I have never used your program and this error popped up when I ran it in WinXP.
    Attached Images Attached Images
    -Carl

  10. #115
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I have traced the vpp pin and it is common for the 2 sides. When it is turned on both sides get the voltage and the trigger pin is commanded by tside. Also the tside reads the voltage.

    An easy solution is dual bootstrap or external supply of vpp it must be filtered in a a narrow 12v range.

  11. #116
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by steveo View Post
    i am just reading about bootstrap mode and it's really interesting, i think i can help get this working.... and might be way easier than i thought

    is this correct?

    - ground MODB to enter bootstram rom on reset
    - power up the whole rig
    - set the SCI baud rate with a byte of 1s or 0s. FF=low baud 00=high baud (should be 8192 with this processor, right?)
    - transmit your code from 0 offset
    - handle the echo (actually i think we'll get a double echo if we've tied tx/rx together, not sure how that'll look).
    - wait for timeout and it'll execute from 0x0000
    In my setup, i ground both mode pins
    First byte is $FF. In my case that is all that works but again I suspect the problem is my (*(*&^6 serial cable
    No ht high baud isn't 8192. I can tell you what it is, just don't have the number right now.
    Transmit code starts at 0
    I separate the tx & rx you can;t connect them for a single wire
    Time out and execute -Yes. I have done all this for a while and built tools to produce the file with a prepended FF. I just send the binary to my terminal program and it loads.


    Quote Originally Posted by steveo View Post
    there are a few trivial things i'm curious about after looking at bootstrap mode

    it seems that in bootstrap mode the onboard EEPROM is forcibly relocated to 0xFE00 to 0xFFFF and there's not much that can be done about it. i guess that wont affect writing...? but that'll give us a nonsense reset vector. i do have functions in my flash tool that expect to be able to read the onboard eeprom at 0x0E00, but that's ok, they'll just read zilch from RAM and no harm done.

    is the COP timer available during bootstrap mode...? if it does crash what reset vector does it use? does it use 0xFFFE like normal, so in actuality it's going to use whatever is in the onboard eeprom? it'll try to jump to FFFF which contains FF and will probably just lock up. the existing method we use for rebooting the ECM is just tripping the COP timer so obviously it wont reboot successfully but that's no big deal.

    does anyone know what happens if you un-ground MODB while the processor is running?
    Turn off the eeprom, change modes after boot. things like that. Remember also to turn off the bootstrap ROM. Also once booted you need to program all the chip selects and what not. A/d function needs to be enabled. At the start the PRU will not show in the memory. Again chip select program will light it up. My plan was to use the internal mem for loader function and the PRU ram as a sort of transient program area.

    COP is available. If the boot rom is on, vectors are replaced with those in the rom. search the reference manual for pseudo vectors. Mode pins are sampled at power up.

    -Tom

  12. #117
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    Quote Originally Posted by In-Tech View Post
    Steveo,
    I have never used your program and this error popped up when I ran it in WinXP.
    I have a version that will work on xp sp3. Just need to compile the latest source and will post it.

  13. #118
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by In-Tech View Post
    Steveo,
    I have never used your program and this error popped up when I ran it in WinXP.
    Not happy w that. can you try messing with the "compatibility mode" setting. It's the same code I sent before compiled for x86 under visual studio.

  14. #119
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by kur4o View Post
    I have traced the vpp pin and it is common for the 2 sides. When it is turned on both sides get the voltage and the trigger pin is commanded by tside. Also the tside reads the voltage.

    An easy solution is dual bootstrap or external supply of vpp it must be filtered in a a narrow 12v range.
    I agree, VPP is common through the ribbon cable. What about enable for the chip?? I don't know which pin, but it must also be across the ribbon. My guess is that there is a multidrop and that the Eside can enable somehow...

  15. #120
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    Quote Originally Posted by In-Tech View Post
    Steveo,
    I have never used your program and this error popped up when I ran it in WinXP.
    not exactly the right thread for this but flashhack and eehack are written with modern QT libraries and XP is 20 years old. QT no longer supports XP, so neither do i. you will find most software does not run on XP including mine.

    kur4o compiles with an older version of QT and you're welcome to do that, that's what open source is for, but if any bugs come up related to that i honestly don't really want to know, and i reserve the right to use modern QT features that may not work on your older versions so it may break at any time, leaving you high and dry.

    from flashhack's page:

    It’s open source and will run on Windows 7, Windows 10, and Linux.

Similar Threads

  1. XDF Creation / Editing - How To????
    By B52Bombardier1 in forum OBDII Tuning
    Replies: 5
    Last Post: 02-28-2020, 02:04 AM
  2. new to obd2
    By myburb in forum OBDII Tuning
    Replies: 0
    Last Post: 05-28-2018, 05:54 AM
  3. DHP/AVT-852-002 Rev L OBD2 programmer $250
    By SappySE107 in forum Buy - Sell - Trade - Wanted
    Replies: 2
    Last Post: 02-03-2018, 09:25 AM
  4. flashing OBD2 ECU?
    By vwnut8392 in forum OBDII Tuning
    Replies: 4
    Last Post: 11-25-2017, 01:43 AM
  5. WTB TunerCats II (OBD2)
    By XRelapse13 in forum Buy - Sell - Trade - Wanted
    Replies: 0
    Last Post: 12-16-2014, 08:26 PM

Tags for this Thread

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
  •