It would be best if it fit into your tool. I'm not sure how to do this... If you can give me a hand I will see if we can make this happen.Originally Posted by steveo
I have not yet tried the TSide. The parts I need from China are taking so long to get here. They are now in the hands of Canada Customs and will at some point move to Canada Post. Canada Post moves at a snail pace at the best of times. Hope I see this stuff some time before July. Other option is to wire wrap.
-Tom
While debugging the ESide routine for setting VPP to 12V, I decided to modify the result codes. Should the ignition voltage be out of range OR the VPP be out of range, an error message is generated. This all is of little use to the tech trying to re-flash. I added ignition voltage and VPP voltage to the reply. I am concerned how this will affect other code that might use the routine ??steveo??
Code works now. I made a bunch of changes to port it from the TSide example I was using to the ESide. Here is the code I am using now.
To convert the VPP voltage, divide result by 17.5.
-TomCode:************************************************* * APPLY VPP 12 VOLT ************************************************* VPP_12VOLT LDAA #$00 ; START A/D CONVERTER CH0 STAA CPU_ADCTL ; ASLD ; TIME DELAY TO A/D COMPLETE MUL ; MUL ; MUL ; LDAA CPU_ADR1 ; READ ESIDE PCM IGNITION VOLTAGE STAA @IGN_VOLTAGE ; CMPA #$66 ; 10.2 VOLTS BCS VPP_ERR_IVOOR ; IGNITION UNDER VOLTAGE CMPA #$A1 ; 16.1 VOLTS BLS VPP_IVIR ; IGNITION VOLTAGE IN RANGE VPP_ERR_IVOOR LDD #$0602 ; MODE 6 MESSAGE: IGNITION VOLTAGE OUT OF RANGE BRA VPP_SEND_MSG ; SEND MESSAGE VPP_IVIR LDAA PRU_PA ; PRU PORT A ORAA #$80 ; TURN ON VPP STAA PRU_PA ; UPDATE AND WAIT FOR VPP TO SETTLE JSR @D_RESET_COP ; RESET COP TIMERS JSR @D_D10MS_DELAY ; 10MS DELAY JSR @D_RESET_COP ; RESET COP TIMERS JSR @D_D10MS_DELAY ; 10MS DELAY LDAA #$01 ; START A/D CONVERTER CH1 STAA CPU_ADCTL ; ASLD ; TIME DELAY TO A/D COMPLETE MUL ; MUL ; MUL ; LDAA CPU_ADR1 ; READ VPP VOLTAGE STAA @VPP_VOLTAGE ; CMPA #$BC ; 10.5 VOLTS BCS VPP_ERR_PVOOR ; VPP UNDER VOLTAGE CMPA #$E9 ; 13.0 VOLTS BLS VPP_PVIR ; VPP IN RANGE VPP_ERR_PVOOR LDAA PRU_PA ; VPP UNDER/OVER VOLTAGE ANDA #$7F ; TURN OFF VPP STAA PRU_PA ; UPDATE LDD #$0603 ; MODE 6 MESSAGE: VPP 12V OUT OF RANGE BRA VPP_SEND_MSG ; SEND MESSAGE VPP_PVIR LDD #$06AA ; MODE 6 MESSAGE: APPLY VPP 12V SUCCESS VPP_SEND_MSG PSHX ; MAKE ROOM FOR MESSAGE CONTENT ON STACK PSHX ; TSX ; MESSAGE POINTER TO IX STD $00,X ; SET MESSAGE CONTENT LDAA @IGN_VOLTAGE ; LDAB @VPP_VOLTAGE ; STD $02,X ; SET MESSAGE CONTENT LDAB #$04 ; MESSAGE PAYLOAD 4 BYTES JSR @D_SEND_ALDL ; SEND MESSAGE PULX ; PULX ; RESTORE STACK POSITION RTS ; DONE
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.
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
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?
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.I am concerned how this will affect other code that might use the routine ??steveo??
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.
modified in what way?
Yes that is what I think will work easy.
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?
Last edited by steveo; 05-30-2020 at 05:51 PM.
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.
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
Looked it up for you... With our crystal frequency the two speeds are 1,890 and 12,288. As I previously mentioned, my serial cable does not work at 12,288.
User sends $FF and IF received correctly, baud rate is 12,288.
User sends $FF at slower rate, the start bit will be much wider and FF will not be received, probably a $07 or $0F. In this case code changes baud to 1890
User sends $00 or break and it jumps to EEPROM and runs whatever is there.
-Tom
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.
Agree, but it does tell you that & more info is always better in my estimation. Cost is one byte = no time.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.
Please confirm... You think the Tside turns on VPP through the port replacement part port a bit 7?
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
Posting Permissions
Reply With Quote
Bookmarks