I hadn't even looked at the schematic other than to identify you were using a transistor pair to drive the output, etc. It's hard to read, is that rail voltage 6.2 or 8.2 volts? I should have a 7806 and maybe even a 7808 3 pin regulator in my parts bin.
Regardless, if this bus is electrically similar to the older 8192 baud ALDL, I have to wonder (and will experiment with) a simple resistor and diode arrangement as I used on my data logger.
I am posting a few things that are duplicated from the PCM thread because they belong together.
In order to read out the FLASH content of the '97 Camaro PCM, you need to be able to access both banks of the TSide and also the Eside. I have put together a couple of command line apps that permit both TSide banks to be uploaded. I have found that GM did not implement mode $35. This mode would regularly be used as suggested by SAE J2190. The first task I undertook was to find a way to support mode $35. I did this by downloading a very small program into low memory. Using the Home Brew Cable (HBC) I first download the image to ram and execute it. This is done as follows:
Download Mode35_T.s19 /P9194 /C3 /V00
In this command line: Download.exe is the command, Mode35_T.s19 is the module I wish to install, /Pxxxx is the PCMs password, /C3 indicates HBC is installed on COM3 and /V00 just suppresses many of the comments placed in the code (if you want to see, try /VFF )
Once this command is accepted by the PCM, it is ready to upload from any address in the PCM.
I have a command line app that uses the PCM conditioned with the Mode35_T.s19 module to upload. The application is run using command line switches and generates an SRecord output file. This format is an often used way to store binary information along with addressing. It can easily be converted to a binary ( .bin file). This is done as follows:
Upload Output.S29 /C3 /B0 /S0E00 /L0200 /V00
In this command line: Upload .exe is the command, /C3 selects the serial port to use, /Bx selects which bank to upload (0 or 1 only), /Sxxxx sets the starting address of the upload in hex, /Lxxxx sets the length in hex, and /V00 just suppresses many of the comments placed in the code (if you want to see, try /VFF )
I am enclosing a sample output file named TSideEEPROM.s29 along with the various executables mentioned above.
-Tom
The objective is to send 6.25 - 8V when the output is active and high impedance when it is passive. The rest of the symbol info is in the timing of transitions. Any 8V regulator will allow for the drop in your output stage and should work a treat and you won't need a zener diode to regulate. You could avoid transistors and so on by using a 1488 rs2323 driver and a resistor. While you might not be in spec with the J1850 (rise time/fall time issues) it will work fine. When I did the circuit, I just went to my parts drawer and used what I have. Looking at it with the scope I see no problems.Originally Posted by spfautsch
-Tom
Thanks for the clarification.
Out of curiosity, did you test with TTL levels? I know it wouldn't be within spec but the 328P will happily sink 20ma per pin at 5V with no issues driving the outputs active high. When not driving the pin it could be toggled to an input / high impedance state.
I did try 5V, didn't work for me. Interested if you test.
Didn't understand the 2nd bit... No need to sink any current. Passive state is high Z. Active state sources current. Issue I had is that 5V doesn't seem to be enough to toggle the input stage. If you can get it to work, all the resistors & transistors involved with the TX can be removed with just a small bit of software change. I power the NANO through USB. There are some voltage losses through the chip and also a diode to permit other power schemes. Powering with the NANO regulator might be enough to make it work. So there might be a way, but I didn't look too hard. I also needed to buy the zener. Can't just buy one on the 'zon so i have a bag full.
-T
Just so we're speaking to the same semantics, when I say sinking current that to me implies an output pin on the AVR pulled positive sinking current supplied by an external ground. Sourcing current would be the same output switched to ground / negative. This was the terminology I was schooled with, with the underlying theory that current flows towards a positive charge. Not that important, just semantics.
I'm still playing catch-up so haven't looked at any of the source code. But if you're using any of the Arduino PWM libraries, changing a pin's state during operation may not be feasible.
While you are absolutely correct in what you write, however conventional current flow is the standard in use almost everywhere today. When looking at data sheets for ICs and so on, the reference is to ground. Specifications for sourcing of current are above that potential. This is somewhat of an abstraction from what we want to get to here. I will try not to use source/sink to describe current flow. I believe you should have no trouble adapting the circuit given to the parts you have on hand.
To get rid of the need for an 8V supply, I thought for a moment about using an output of the micro to toggle and building a switch capacitor boost circuit. This took too many parts, i discarded the notion.
I will be interested to see what you come up with. There is no use of PWM libraries in my design. You can do practically whatever you need WRT control of the outputs.
-Tom
There being no opinions on this, here is the conversion tool that meets my needs. I just zipped the whole visual studio project file but it is too big or ?? so here is the exe.
Usage: Srec2Bin <Input_File_Name> <Output_File_Name> /L<Hex_Fill_Length> /F<Hex_Fill_Character>
<Input_File_Name> File extension .S29 (S2 addressing)
<Output_File_Name> File extension .bin (unformatted binary)
/L???? Fill length at file start. Four hex digits
/F?? Fill character used. Two hex digits
For those working with other cables or ?, source is available, just ask.
-Tom
Hello Tom - Just catching up after some time away and though late still wanted to chime in on bin format.
One fairly common format I have seen is 144kb. This format has been simply and clearly described by kur4o in the xdf thread:
So to answer your questions for this bin format:96-97 files are 0-56 kb tside bank0. 56-88kb bank1 tside. 88-144kb eside.
Q- If binary format is wanted for your tool (tool name?):
A- Tunerpro, perhaps others
Q- Does the TSide bank 0 binary start from $0 or $2000?
A- Starts from $2000 (makes up 1st 56k)
Q- Is there a separate file for TSide bank 1?
A- No, immediately follows Bank 0 in same file
Q- If yes, how is the bank 1 gap between $0 and $8000 handled?
A- No gap in bin; presumably this is handled by binconverter utility or pcmprogramming software
Q- If no, does bank 1 address $8000 follow bank 0 $FFFF or is there padding there?
A- Bank 1 immediately follows Bank 0 in same file with no padding (makes up next 32k)
Q- Does the ESide binary start from $0 or $2000?
A- Starts from $2000 and immediately follows TSide Bank 1 (makes up last 56k)
Hope this helps, and thanks for all you're doing with these tools!
Jim
1995 Caprice 9C1 LT1 - 4.10s, Dynomax Catback, K&N Cold Air Kit, Other Little Stuff
1996 Caprice 9C1 LT1 - 3.73s, Stock
Hi Jim,
Going by your answers, I think you have all the needed tools already.
The first Tside bank is dumped separately, let's say we place it in <file1>, length is $E000 starting at $2000. Second bank is placed in <file2> and has a length of $8000 starting at $8000. In a batch file or cmd window, use the following:
"TYPE FILE1 FILE2 > FILE3"
Now file 3 is a concatenation of both files, no gaps. Then use Srec2Bin as follows:
"SREC2BIN FILE3 144KB.BIN
Take the output file and you should be good to go. If someone has the tool that uses this format, give it a go and let me know how it works.
I am now working through the spi and will post some info soon. Turns out to be interesting/tricky how it was done. Each transfer switches mastership of the spi after the first transfer. Still a bit of head scratching to go but once done, dumping the Eside should be easy. BTW looking through earlier posts in the ECM thread, dzidaV8 in post #77 indicates he has all this working! You might want to speak with him to see if what he has done is better for your needs...
-Tom
Hi,
I have come to the end of another of my sub-projects. I spent the last few months learning some of the details of windows programming. I have built software that works in conjunction with the Home Brew Cable (HBC) that was written earlier. This tool gives the user the ability to exercise the J1850 port. All commands can be supported with the exception of the 4X mode... still working on that.
This system breaks down into three main sections.
The first section is the cable hardware. This was detailed earlier, but two small changes have been made to enhance the operation. There is a new JPEG of the interface. The Arduino Nano is used for it's low cost. This whole interface fits on a small perforated board. The costs of parts is way up, but it is still under $20 to build.
The second section is the cable software. This software runs on the Nano and essentially translates between the J1850 and standard NRZ serial over USB. Small changes to this code have been made to prevent overrun of the TX. To prevent this overrun, XON/XOFF protocol has been added to the PC --> PCM link. This change permits the cable to throttle data coming to it from the PC.
Last section is the PC software. I wrote an app that the user can issue the J1850 commands. Once the app is booted, the user selects the Com port that the cable is on and connects. There are 20 configurable keys that allow the user to issue commands. There is also a command line entry for the commands that are entered once. This is an interface that I find flexible. Another feature is the repeat "tester present" timer. This ensures that once the security password is issued, it does not time out.
I wrote this for the 1997 Z28 Camaro PCM that I am working on but is should work fine on GM cars 1996 through about 2003.
Interface.jpg
The interface has a dozen parts or so and should be easy to build.
J1850_VPW_3-220620a.zip
The software that resides on the Nano is provided in the archived sketch. By running the Arduino software tool, the sketch can be uploaded in less than a minute.
UInterface.jpg
Here is a shot of the user interface. The buttons down the left screen are programmable to any J1850 command you need. Details of this software will be in another post following soon.
-Tom
The app that works with HBC is written in C++. People with other cables that would like to port the software, feel free to ask and I will get you my source code. Please if you do use the source, understand that I am self taught and some conventions that you might be used to I might not follow. I tried to write the code in classes that make it easy for me to port them to other apps.
The C++ IDE I use is Microsoft visual studio 2015. It is free, fairly complete and easy to use. One small disadvantage is that a microsoft runtime DLL must be installed. You can get the module needed at this URL:
https://www.microsoft.com/en-us/down....aspx?id=48145
Just follow MS's install instructions and you are done.
OK, so now to the app...
UInterface.jpg
The app has a simple menu structure at the top. There is help available if you forget some detail, but fairly terse. The repeat menu permits you to turn on/off the tester present messages. Once connected, if you enable this timer, the app will send a "tester present" message periodically to prevent the tester from exiting the security disabled state.
The taskbar just under the menus contains a few controls. In the combo box, select the port your Nano is connected to. Not sure which port? --> run device manager and look at the available serial ports, pick out the one associated with your Nano. Once the app port select combo is set, hit the connect button. This lets system start and you should see an OK come up in the transcript.
At this point the app is ready to send commands. The user can enter them into the "line entry" edit control as follows. Permitted characters are hex (that is 0-9, a-f or A-F). User may enter spaces to make it more readable. Once the command is entered, hit the enter key and the command will be sent. The transcript will show both the command and the response. The transcript is always looking at the bus. This gets away from the ELM327 type command response. This permits commands that have multiple responses to be correctly monitored. Yes GM does use this sort of one request multiple response format.
The command buttons down the left side are configurable. To do this click the button with shift key down. You can then change the key name and the content to be sent.
Here is the app with the name changed with an appended .TXT.
CarCom_1.exe.txt
I hope this is of use to someone.
That looks amazing. Great work so far.
Can I ask what is the communication between cable and pc. Does it use some header or is pure passive passthrough mode that the cable just relays the command to bus, without any processing.
On the x4 mode. If the hardware is capable you can implement the switching to a hardware level, listening for some mode a1 and mode a0 being issued on bus or from pc for x4 mode trigger. Switch back to x1 mode should also be on hardware level, when sensing some weird signalling.
Hi kur4o,
The format of data over the NRZ link is:
Standard serial at 115200 baud 8N1. The Nano board detects when communication is valid and resets the microcontroller. There is a delay here, so when booted the Nano returns "OK\r\n". Till the OK comes, don't send a pile of stuff. In cases where stuff is sent before OK, it will be lost or some weird thing will happen. This case has not been tested although I believe software will recover it.
Talking about receive or transmit is confusing. Receive for the HBC is transmit for the PC and again transmit for the J1850. I will use "Outbound" for the data path PC -> HBC -> PCM.
The outbound is transmitted to the HBC from the PC and the following characters are recognized:
Character Hex value
'0'-'9' 0x30 through 0x39
'A'-'F' 0x41 through 0x46
'a'-'f' 0x61 through 0x66
' ' (space) 0x20
'I' 0x49
'i' 0x69
NL (linefeed) 0x0A
Other characters are discarded.
Hex values are sent in pairs. They can be sent with a space ' ' character between pairs. Given that:
"4C10F050\n" is exactly the same as "4C 10 F0 50 \n" but "4 C 1 0 F 0 5 0 \n" won't work... no pairs.
The inbound is received by the PC from the HBC and the following characters are used:
Character Hex value
'0'-'9' 0x30 through 0x39
'A'-'F' 0x41 through 0x46
'O' 0x4F
'K' 0x4B
' ' (space) 0x20
CR (return) 0x0D
NL (linefeed) 0x0A
DC1 (XON) 0x11
DC3 (XOFF) 0x13
You should not see other characters
!!Edit!! I added a detection for BREAK. This adds the characters 'B' and 'R' to the list!!
Inbound frame data is sent in pairs of hex characters with space between them. Lines are terminated with NL. The HBC sends XOFF to suspend the outbound side and XON to resume it.
-----------------------------------------------------------------------
The explanation is quite wordie so to make it easy, here is an example
Outbound: 4C 10 F0 28 00 \n sends 34 43 20 31 30 20 46 30 20 32 38 20 30 30 20 0A
Inbound: 4C F0 10 68 00 5E receives 34 43 20 46 30 20 31 30 20 36 38 20 30 30 20 35 45 20 0A
I have removed the XON/OFF characters from above. If you don't need them, just filter them out.
Note that the HBC generates the CRC on the outbound. On the Inbound I check CRC in the PC app.
Above is confusing & hard to read through. If you have question, don't hesitate to ask.
- Tom
The 4x has been back burner for a while. Switching can be accomplished as you suggest, but with some care. The data transfer (think it's mode$36) automatically enters 4X. When it sees a 1x character it falls back. Main thing not tested is the capability of the HBC hardware. Initial tests suggest yes but still a bunch to do. Should be as simple as switching the table of constants, but things are usually not that simple.
With the interface I have, the calcs look like the speeds work out OK...
Some back of the napkin calculations:
J1850 shortest pulse 49us
Ignoring frame overhead, shortest word is 392us
NRZ at 115200 8N1 results in a word time of 87us
3 words are generated from each receive: 261us
Now let's ask if the PC can keep up or if I need to improve on the efficiency of my code
or worse redo the interface to get rid of space between hex pairs <sigh>
-Tom
Posting Permissions
Reply With Quote
Bookmarks