The Z3 Diagnostics Thread: Instructions, Experiences, Discussions, Experimentation

[gmushial]

I tried to install INPA a couple three times about a year ago, and found myself running into questions/prompts that didn't match the documentation... and eventually gave up. This was on a WinXP laptop. I'm now in a position of needing to be able to use INPA to read some codes that the generic scanners can't.. so: my question is: what do I need to erase off the laptop before I try to install it again? Or, does the installer not look at what's there during the process? [I have the 20-pin to OBD converter likewise the OBD to USB converter with the right chip in it... so other than getting INPA installed and running, in theory I should be good to go... ].

[328 Power 04]

Yes you can just reinstall it again.

I usually take care to delete the following folders (if they exist) to clean up:
C:\EC-APPS
C:\EDIABAS
C:\INPA
C:\NFS-Backup
C:\NCSEXPER and related ones with $$$

[gmushial]

Yes you can just reinstall it again.

I usually take care to delete the following folders (if they exist) to clean up:
C:\EC-APPS
C:\EDIABAS
C:\INPA
C:\NFS-Backup
C:\NCSEXPER and related ones with $$$

Will do... thanks. let's see if the fifth try is the charm... ;-)

[rf900rkw]

UART = Universal Asynchronous Receiver/Transmitter . The name used to be synonymous with RS-232 serial communications... by the same people that call Microsoft Windows "windows" and MS-DOS "DOS" and think PC means a machine with a microsoft operating system. In truth, a UART does not imply RS232 compatibility. But if you are wiring your own board, do you really need to step from TTL to RS-232 levels and back?

[1215]

Will do... thanks. let's see if the fifth try is the charm... ;-)

I didn't try as any other user but I had no problems installing as Administrator. Not sure how you set up your user permissions but making whatever user you end up using an Administrator might help.

- - - Updated - - -

UART = Universal Asynchronous Receiver/Transmitter . The name used to be synonymous with RS-232 serial communications... by the same people that call Microsoft Windows "windows" and MS-DOS "DOS" and think PC means a machine with a microsoft operating system. In truth, a UART does not imply RS232 compatibility. But if you are wiring your own board, do you really need to step from TTL to RS-232 levels and back?

Can't you just pin coms over from the SPI bus and pull power for the TinyADS board from GPIO? What am I missing? (I'm more interested in how GBPatterson is going to physically put it all together and package it than the actual pinouts and coms.)

[328 Power 04]

If the UART on that minnowboard is anything like the Raspberry Pi, with GND, TX, RX, and 5V, or 3.3V in the case of the above, it will not work with TinyADS.

You need a dedicated DTR, RI, and DSR line as well (from looking at connections on the TinyADS board)
Or somebody to write custom drivers to handle it.

[gmushial]

Will do... thanks. let's see if the fifth try is the charm... ;-)

Got those deleted... have a stack of midterms to grade... but then will take one more shot at it... with fingers crossed :-)

[GBPaterson]

Hm, was out of town for a few days so did not get a chance to reply. I'll let you know once I get the board but it appears from what I can see that there are a total of 5 serial connections.

The following page gives more details (The Turbot matches the MAX in this regards)

http://wiki.minnowboard.org/MinnowBoard_MAX

Serial Console

On your host computer, configure your terminal emulation software with these settings:

• /dev/ttyS0
• Baud rate: 115200
• Hardware Flow Control: No
• Bits: 8
• Stop: 1

The serial console port (UART0), located near the SATA connector at the top of the board, uses a 3.3v FTDI serial cable with a 6-pin connector. This is a reasonably common cable, also used on the Arduino Pro, Arduino Pro Mini and Arduino Lilypad. The cable connector typically has a triangle marking pin 1 (black wire).

Pins and signal names are referenced from the cable: Pin 1: Ground (GND) (Closest to SATA connector) Pin 2: CTS* Pin 3: VCC* (3.3V) Pin 4: TXD Pin 5: RXD Pin 6: RTS*

Debugging MinnowBoard MAX with Olimex USB-Serial-Cable-FHigh Speed UART1

Available on the Low Speed Expansion this Uart is 16550 compatible and appears as /dev/ttyS4
CTS/RTS signaling is available
High Speed UART2

Available on the Low Speed Expansion this Uart is 16550 compatible and appears as /dev/ttyS5
CTS/RTS signaling is NOT available

And two more on the low speed connector

Low Speed Expansion Connector (Top)

The low speed expansion connector uses 0.1" (2.54 mm) male header pins in a 2 x 13 array, for a total of 26 pins. Pin 1 is in the row closest to the power connector, and closest to the board edge.
NOTE: All I/O on the Low Speed Expansion Connector is at 3.3V levels. THE PINS ARE NOT 5v TOLERANT
LSE Layout

The Linux GPIO base address changed (by adding 256) from Linux kernel versions 3.17 to 3.18, so you'll need to know which kernel version you're using to select the correct GPIO numbers. This table lists the GPIO number for both the 3.17 and earlier kernels, and 3.18 and later kernels, for each pin on the connector:

Description	Name	Pin	Linux GPIO# (≤3.17)	Linux GPIO# (≥3.18)	Linux GPIO# (≥3.18)	Linux GPIO# (≤3.17)	Pin	Name	Description
Ground	Gnd	1					2	Gnd	Ground
+5V Power	VCC	3					4	+3V3	+ 3.3V Power
SPI Chip Select 1	GPIO_SPI_CS#	5	220	476	481	225	6	GPIO_UART1_TXD	UART Transmit
Master In / Slave Out	GPIO_SPI_MISO	7	221	477	480	224	8	GPIO_UART1_RXD	UART Receive
Master Out / Slave In	GPIO_SPI_MOSI	9	222	478	483	227	10	GPIO_UART1_CTS	CTS / GPIO
SPI Clock	GPIO_SPI_CLK	11	223	479	482	226	12	GPIO_UART1_RTS	RTS / GPIO
Clock / GPIO	GPIO_I2C_SCL (I2C #5)	13	243	499	472	216	14	GPIO_I2S_CLK	Clock / GPIO
Data / GPIO	GPIO_I2C_SDA (I2C #5)	15	242	498	473	217	16	GPIO_I2S_FRM (* Note issue)	Frame / GPIO
UART Transmit / GPIO	GPIO_UART2_TXD	17	229	485	475	219	18	GPIO_I2S_DO	Data Out / GPIO
UART Receive / GPIO	GPIO_UART2_RXD	19	228	484	474	218	20	GPIO_I2S_DI	Data In / GPIO
GPIO / Wakeup	GPIO_S5_0	21	82	338	504	248	22	GPIO_PWM0	PWM / GPIO
GPIO / Wakeup	GPIO_S5_1	23	83	339	505	249	24	GPIO_PWM1	PWM / GPIO
GPIO / Wakeup	GPIO_S5_2	25	84	340	464 509	208 253	26	GPIO_IBL_8254 (*Notice) (MAX A2) I2SMCLK_GPIO (Turbot)	Timer / GPIO I2S MCLK / GPIO

The most promising would appear to be the FTDI that is normally used as the debug connector.

Failing that I'd be willing to give a shot at putting together drivers, it not an area I'm overly familiar with but I'm well experienced in development and engineering.

- - - Updated - - -

What I'm wondering is if it would be possible to somehow adapt the CTS/RTS to fill the DSR/DTR role (even if custom driver).

- - - Updated - - -

From

http://www.tldp.org/HOWTO/Text-Terminal-HOWTO-11.html



Connecting up DTR or DTR/DSR Flow Control

Some terminals use only DTR flow control. This is only one-way flow control to keep the terminal from being overrun. It doesn't protect the computer from someone typing too fast for the computer to handle it. In a standard file-transfer serial cable the DTR pin at the terminal is connected to the DSR pin at the computer. But Linux doesn't support DTR/DSR flow control (although drivers for some multiport boards may support DTR/DSR flow control.) A way around this problem is to simply wire the DTR pin at the terminal to connect to the CTS pin at the computer and set RTS/CTS flow control (stty crtscts). The fact that it's only one way will not affect anything so long as the host doesn't get overwhelmed by your typing speed and drop RTS in a vain attempt to lock your keyboard. See Keyboard Lock. For DTR/DSR flow control (if your terminal supports this two-way flow control) you do the above. But you also connect the DSR pin at the terminal to the RTS pin at the computer. Then you are protected if you type too fast.

- - - Updated - - -

If this is a proprietary project of yours (meaning you want to make something to sell later on) I'm happy to give you a brain dump on what I/we have put together so far as long as you'll provide a few sample units when you start making them

If I can make it work I'd share all the details openly but most likely would not be making them to sell. If it requires additional software to be written I'd be making that open source also.

[GBPaterson]

Got the board today.

So initial inspection it would seem they are all UART connections (as in TTL serial connections). The TinyADS is outputting RS-232 serial. So theoretically throwing in a MAX3232 breakout board should allow me to connect?

https://www.sparkfun.com/products/11189

- - - Updated - - -

Ok, TinyADS (No Connectors) and the MAX3232 breakout board ordered also now.

[328 Power 04]

Hmm, I wonder if you are working too hard to get ADS connection? You might be able to connect to all modules except Instrument Cluster through USB cable.
Does your Z3M have ASC traction control?

[GBPaterson]

Maybe true, but where is the fun in that?

I think I have the throttle body with no traction control.

[gmushial]

I think I've got it installed correctly - though with one question... but I'm not "connecting" to the data on Z..

The question is: which COM port should I have installed the last step to use... the laptop is vintage XP pro 32, but it has a built in modem and serial port... I believe they use COM1 and COM2 respectively - though not sure. The install gave me the choices 1 - 8... how should I decide? The laptop only has a single USB (probably 1) port. I do have the OBD to USB converter cable as specified back on page 1 or 2 of this thread... and when I plug it into the OBD port I do get a blue LED light up.

Beyond that, when I go into INPA, I get the front screen with all the F key assignments... where F2 is for E36 / Z3. But even though the Z is running (though I tried it with the key off, key in acc, and key in running position, I get the same results): that front page at the top says: "Battery: OFF Ignition: OFF"... even though the cable is plugged into the dash OBD port and into the USB port on the laptop. Do I need to use the 20 pin converter and connect under the hood? ... and when I select F2, and engine and then one of the items in the right list box... after I select an item, do I hit enter, or does selecting it cause the function to be loaded? ... so I guess I have two questions: one about getting INPA to see the cable plugged into the USB port; and how to run INPA.

[328 Power 04]

See connection troubleshooting instructions to fix your COM port. Your USB cable's COM port isn't matching to the settings needed for INPA. It is defaulted at COM1 when you do the Step 3 install. But can be changed to any of your needs.

[gmushial]

DevMngr.jpg

Thanks for the reply... and yes, assumed to be a comm error. Though the question is and this was that I was trying to get to: the USB port is mapped to COM9; where as COM1 is tied to a real old school RS-232 D-15 serial port on the back of the laptop... so the question is: do I mod the .ini to use COM9, even though in the com port config tool only COM1-8 were listed? Or, is there another workaround? Thanks again.

[328 Power 04]

I would change the COM port on the USB cable to the lowest available, AND then match the .ini to that. It will work then.


(COM9 may work too, doesn't hurt anything to try, no reinstalls or losses if you edit those settings around)

[gmushial]

I would change the COM port on the USB cable to the lowest available, AND then match the .ini to that. It will work then.


(COM9 may work too, doesn't hurt anything to try, no reinstalls or losses if you edit those settings around)

Just some follow up:

- Changed the COM port number in the .ini file to COM9, and INPA was able to communicate.

- If seems that at least on my '99 Z, only the engine data is available via the console OBD port; one has to go under the hood, and use the 20-pin adaptor to read other data... driving around with the laptop in the passenger seat checking values is reasonable... but given the cable length I have, driving around with the laptop on the hood, is not reasonable [though did enough to see that my problem was but is not now the wheelspeed sensors].

- the next question is: where does one fine further information on a specific error number? eg, 113 from the ABS/ASC system - one liner says main relay in control unit... ???

- how much extension will USB accept (and still work)? 1m? 2m?

But above all: many thanks, for the input, and many thanks for making this available to the community. :-) x100

[328 Power 04]

- If seems that at least on my '99 Z, only the engine data is available via the console OBD port; one has to go under the hood, and use the 20-pin adaptor to read other data... driving around with the laptop in the passenger seat checking values is reasonable... but given the cable length I have, driving around with the laptop on the hood, is not reasonable [though did enough to see that my problem was but is not now the wheelspeed sensors].

- the next question is: where does one fine further information on a specific error number? eg, 113 from the ABS/ASC system - one liner says main relay in control unit... ???

So on your 99 Z3 '2.3' with DSC you connected to "DSC E46". When you read errors, it had the 113 error? A search online says that the problem is the DSC module itself (quite common). Not sure if this is the simple to fix cracked solder on the board, but it may be.


And yes, only your engine control unit (and auto transmission, if you had one) can be diagnosed via OBD port, but not any others. I have not yet found the need to log anything from the 20-pin port while driving.

And you are most welcome!

[gmushial]

So on your 99 Z3 '2.3' with DSC you connected to "DSC E46". When you read errors, it had the 113 error? A search online says that the problem is the DSC module itself (quite common). Not sure if this is the simple to fix cracked solder on the board, but it may be.


And yes, only your engine control unit (and auto transmission, if you had one) can be diagnosed via OBD port, but not any others. I have not yet found the need to log anything from the 20-pin port while driving.

And you are most welcome!

Any guesses on the maximum usable USB extension length and still have it work? ... find it interesting that what I connected to was the "ACS Mk20 / DCS E46".. somehow would have thought the two systems would have been different in age to have used different units... ?? But yes, basically I tried all the options and that was the only one that didn't blow me out... and was sufficiently viable that I was able to reset the errors, drive it around the driveway loop - .1mi (goes around garage, barn, shop etc)... and the 113 came back but the wheelspeed sensor errors didn't... wondering if my cleaning of them had anything to do with that... though strangely, the 113 and sensor error cnts were exactly the same... from your comment, will have to do a search here on DCS/ACS module errors, deaths and repairs and see if one can come up with a solution... don't want to just throw parts at it. Thanks again.

[Laminar]

15ft is about as far as I've had USB work.

[328 Power 04]

15ft is about as far as I've had USB work.

Did you ever code out your auto transmission from your cluster to get rid of lights? (Saw blog video)

[gmushial]

Did you ever code out your auto transmission from your cluster to get rid of lights? (Saw blog video)

Not to hijack the thread... but is "coding a module" something that either INPA can do, or one of the other items in the distribution you put together?

[328 Power 04]

Not to hijack the thread... but is "coding a module" something that either INPA can do, or one of the other items in the distribution you put together?

It is done with NCSExpert, included.

[gmushial]

It is done with NCSExpert, included.

Just confirming: if I have to buy a used ABS module, I can use NCSExpert to code it to match my VIN or whatever it is? Again, many thanks. :-)

[328 Power 04]

Just confirming: if I have to buy a used ABS module, I can use NCSExpert to code it to match my VIN or whatever it is? Again, many thanks. :-)

You should be able to in NCSExpert, using the "FGNR_SCHREIBEN" job command. (And the SG_CODIEREN job will write correct car specific settings to the module, for instance if DSC comes out of an auto Z3)


If not, the supplied Tool32 will do it as well.
Also a proper reflash with WinKFP usually writes the correct VIN at the end of the programming.

- - - Updated - - -

) from your comment, will have to do a search here on DCS/ACS module errors, deaths and repairs and see if one can come up with a solution... don't want to just throw parts at it. Thanks again.

User puntoloco was able to fix a few of these modules by resoldering the cracked solder on the board.
In this post http://www.bimmerforums.com/forum/sh...4#post27767574

But his pictures aren't all working anymore

The idea is you crack the module open and inspect the soldered areas. This is what ModuleMasters does. It takes a bit of courage, but this is what I would be doing first before buying a used one.

[GBPaterson]

Got the Minnowboard set up with Win10 (x86) and EDIABAS/INPA/e.t.c. all seems to look good. It seems only one of the UARTS is fully set up to work with RS-232 serial as Windows shows only 1 COM Port. Unclear though if this is the Debug UART header or the Low Speed connector UART1 connection. Once the other parts arrive I'll do some testing and figure it out.

Either which way it seems its running Windows + BMW Tools fine and has a COM1 port present.

UART = Universal Asynchronous Receiver/Transmitter . The name used to be synonymous with RS-232 serial communications... by the same people that call Microsoft Windows "windows" and MS-DOS "DOS" and think PC means a machine with a microsoft operating system. In truth, a UART does not imply [COLOR=red !important][COLOR=red !important]RS232[/COLOR][/COLOR] compatibility. But if you are wiring your own board, do you really need to step from TTL to RS-232 levels and back?

I'm using the term UART here since as far as I can tell they are all TTL level coming off the board.