Some info requested about VR, VS, VT and VX PCMs

[robertisaar]

never thought i would be posting in this section of the forum.... but curiosity demands it.

i'm very comfortable with 6811 code and terrified looking at assembly for the 68332 let alone trying to write custom programs for them. unfortunately for me, almost all north american GM OBD2 PCMs used the 68332 when the OBD2 transition happened. there are some small exceptions, but they're pretty few.

anyways, all of this stems from my need for a need for a large program space and preferably a lot of I/O to play with as well. with my nAst1 project, i really quickly ran into the 32KB limit that the P4 processor is setup for. the PCB is actually setup so that what would normally be the A15 pin on a 64KB PROM is permanantly connected to +5V. i've gotten creative and removed the connection and rerouted the pin's connection to A15 by way of the edgecard connector. now that signal at least makes it into the MEMCAL connector, though i'm not sure if the processor will drive the CS and OE circuits for the PROM when addressing the below $8000 range. looking into use some 74138s to decode the address bus and force the processor to read the PROM in nearly every location that isn't occupied by some internal register. this isn't a very fun project, but it needs done.

but i started looking here:

http://pcmhacking.net/forums/viewtopic.php?f=7&t=655

and noticed that from VR-VX at least, the aussie PCMs were using the 6811 with some larger than usual programs. north america received some units like this, in passenger cars, the 94-95 3800s and in trucks the 93ish-95 applications using automatics. those were all 64KB, using a 68HC11F1. i've considered using them but they seem to be pretty light on I/O(especially A/D channels), less than the 1227730 variants that i'm used to playing with. so i'm curious what kind of hardware is inside of the VR-VX PCMs. with a 7730, there are 6 PWM outputs, 8 digital outputs, 14 digital inputs and 17 A/D channels as-is. a couple more can be made usable with some internal modifications.

in addition to running out of program space, i've also ran into a problem with lack of outputs...

so, if anyone has documented what all exists in the VR-VX units, would you care to shed some light or link me to some info to mull over?

[VL400]

We were pretty lucky to keep the HC11 based ECU/PCMs until the early 2000s, but from the mid 90s became a little more difficult in terms of writing code using standard tools with 128k bins that used bank switching to give a common code area and a switchable area.

Our '808 (which is almost identical to the US '165) was used in the VN and VP, then in VR V6/V8 and VS V8 manual we got something that was pretty much the '165. It has the same limitation of 32k with the A15 line tied to 5V, but has a heap of spare I/O as it does not control an electronic auto. In the OSE 12P bin every spare pin is used, the biggest issue is a lack of RAM now to add anything else (GM left 0 bytes free so had to remove factory functions to get some back to add new functions, there are now 3 bytes free!). Only issue is lots of the fuel and spark stuff is handled by a ASIC so you dont get full control over some things.

The 16176424 PCM (VR V6/V8 auto, VS V8 auto) uses a 64K bin and a P6 processor that is close to the 68HC11F1. It controls electronic auto transmissions and off the shelf tools can disassemble and compile the bin. There is not much in the way of spare I/O though, almost every pin of both harness connectors is used from factory. There is room to add code (with code mods can have 0x1000-0xFFFF, with 0x3000-0x3FFF reserved for CPU regs) and it does have some free RAM so not too bad to mod these. This is the function of every pin on the VR Auto PCM...

VR Auto Pinout.txt

(11.95 KiB) Downloaded 276 times

And then with the VS V6 we got 128K bins, this has made it much harder to disassemble and then compile a bin so we are limited to code patches for now. VX and VY moved to the last generation HC11 PCM using a flash IC and faster clock speed. This is pretty much the limit of the venerable HC11 and really is a credit to the GM engineers to get the code throughput which such limited processing power.

[robertisaar]

DAMN!

wrote out a reply twice and either closed the tab or accidentally clicked a link and lost my text.

i guess now the super short version:

seems like the 808 and 16176424 would both be a step backwards compared to what i'm currently using.

VS V6.... really depends on I/O. if there are enough to play around with, i imagine i could deal with it.

VX and VY, similar situation.

since i'll probably be reusing only bare minimums of code that GM had already written, it really wouldn't matter where i start, just so that i don't end up writing myself into a corner and needing to find yet another PCM that is more capable than what i am dealing with at the time.

[vlad01]

I have read this lack of free RAM on the 808, stupid question but can more RAM be added or is in internal to the CPU?

[antus]

internal to the cpu.

installing nvram does turn the memcal in to non-volatile ram, and that can be used (and is used for the 128 byte buffer for long write aldl messages) but if you go there then you can no longer run from memcal, which isnt so desirable.

[vlad01]

So I read a little just then on the 68Hc11. So its only 8 bit system.

I also read that the later 16 bit 68HC16 code is a compatible upgrade path from the 68HC11

http://www.freescale.com/webapp/sps/sit ... omPage=tax

[VL400]

VS V6.... really depends on I/O. if there are enough to play around with, i imagine i could deal with it.

VX and VY, similar situation.

since i'll probably be reusing only bare minimums of code that GM had already written, it really wouldn't matter where i start, just so that i don't end up writing myself into a corner and needing to find yet another PCM that is more capable than what i am dealing with at the time.

There are more spare i/o with these. They use 3 plugs instead of 2 so more pins to start with. I havnt gone through all the pins and put it in a nice table though.

You can compile a 64k bin to run on them and can then try and work out the bank switching with the assembler when you run out of room. A 128k bin is not actually 128k of code space though as there is a common bank and you switch in two or three 32K banks. On a VS and VT PCM its only two 32k banks plus the common (which is 32k of space but has all the CPU regs, RAM etc mapped in there). The VX and VY PCM goes closer to 128K but you still lose a fair bit of that to registers and RAM.

[robertisaar]

is there a location where i could find pinout diagrams to see what at least the factory utilized for those 3(or is it 4?) PCMs? i'm used to being able to look these types of diagrams myself via alldata, but that only really helps for US/canadian market vehicles.

with a lot of I/O, having access to most of the 64KB map would probably be more than sufficient, at least for a while. enough 17X17 tables can eat up room pretty quickly. i'm still not 100% on bank switching, but it sounds like the 0000-7FFF range is persistent regardless of which bank is being used, while as far as the processor is concerned, 8000-FFFF can be swapped out for a different "map" as needed?

it would seem like all interrupt related code would need to be within the 0000-7FFF range. seems like it would also be a good space saving method to locate subroutines that are used in more than one bank situation in there as well, otherwise the same subroutines would be taking up space unnecessarily.

am i close?

[delcowizzid]

http://memcals.com/rcc_info_wiring.html pdf wiring diagrams

[VL400]

is there a location where i could find pinout diagrams to see what at least the factory utilized for those 3(or is it 4?) PCMs? i'm used to being able to look these types of diagrams myself via alldata, but that only really helps for US/canadian market vehicles.

In the wiring section there should also be diagrams for each PCM to know what the factory used.. http://pcmhacking.net/forums/viewforum.php?f=32

As for the spare pins would need to go through some code and work them out. We have some pins being used for wideband input using new code on these.

with a lot of I/O, having access to most of the 64KB map would probably be more than sufficient, at least for a while. enough 17X17 tables can eat up room pretty quickly. i'm still not 100% on bank switching, but it sounds like the 0000-7FFF range is persistent regardless of which bank is being used, while as far as the processor is concerned, 8000-FFFF can be swapped out for a different "map" as needed?

Correct, so the upper 32K becomes 2 or 3 32K banks in the 8000-FFFF range when switched in using a processor output pin/pins.

it would seem like all interrupt related code would need to be within the 0000-7FFF range. seems like it would also be a good space saving method to locate subroutines that are used in more than one bank situation in there as well, otherwise the same subroutines would be taking up space unnecessarily.

am i close?

Very, with a few exceptions due to code space they split the switched banks in to engine for one and trans for the other. The common code contains all the cal data as well as interrupts and all the usual state machine code your used to.