Consult disconnected

Stinky · Post by **Stinky** » Sat Feb 18, 2006 1:36 am

I'm not sure if you said you fixed this or not but im still getting disconnected once in a while. Here is some info from my last log.

NISTUNE LOG Feb 11 2006 00:53 0.760a
16:59:43 CImageSelPanelView
16:59:43 ConsultMain
16:59:43 Consult::Create
16:59:43 CImageSelPanelView
16:59:43 RomulatorMain
16:59:43 CImageSelPanelView
16:59:43 USBMain
16:59:43 CImageSelPanelView
16:59:43 TechEdgeMain
16:59:43 InitialiseRegisters
16:59:43 CImageSelPanelView
16:59:43 Opening C:\nistune\Z31_128_E.v3.adr
16:59:43 ~CParser
16:59:43 statusbar: Opened image file C:\nistune\0122kv3.bin - Size 16384 bytes
16:59:43 MainSize
16:59:56 CUSBMain: Connecting16:59:57 statusbar: USBConsult connected
16:59:57 Consult display running on USBConsult
17:00:21 statusbar: Creating new log file C:\nistune\logs\021606-122.csv17:00:21 statusbar: Log file opened for recording=n17:00:22 statusbar: Recording to log
17:00:26 MainSize
17:00:52 MainSize
17:05:08 USBDriver:Write: error writing bytes
17:05:08 UpdateConsultRegs: Error writing
17:05:55 USBDriver:Write: error writing bytes
17:05:55 UpdateConsultRegs: Error writing
17:07:28 USBDriver:Write: error writing bytes
17:07:28 UpdateConsultRegs: Error writing
17:08:53 USBDriver:Write: error writing bytes
17:08:53 UpdateConsultRegs: Error writing
17:17:46 USBDriver:Write: error writing bytes
17:17:46 UpdateConsultRegs: Error writing
17:17:46 check_usb_consult_errors() - too many errors -bye
17:17:46 USBDisconnect: USB Disconnected

Any clues? Could this be a problem with my pc?

Matt · Post by **Matt** » Sat Feb 18, 2006 2:06 pm

its strange that it can't write out to the usb chip....

is this happening whilst the engine is not running? the 1 degree CAS signal spinning triggers interrupts on the HD6802 IRQ line from the HD46510

it is highly preferred that the engine is running so there are interrupts to the ECU code for the patch code to run.

this problem is definately between the driver and the hardware (including ECU firmware running)

are there any other certain conditions which this happens (high pc load, position of ecu?). i did notice write problems in the early days when engine not running if i flooded the bus with requests. a trace mode connection could do this perhaps

Stinky · Post by **Stinky** » Sat Feb 18, 2006 3:19 pm

The log was done with the car being driven. I usually start the nistune log and my wideband logging and drive off. As far as I can tell it disconnects randomly. I didnt have tracing open. Are there any updated drivers or anything i could try?

Matt · Post by **Matt** » Sun Feb 19, 2006 12:57 pm

no updated drivers are available or should be required. if its whilst driving, some errors are happening for unknown reason

can you email me the full logs where it dies randomly in the middle. i'll have a look through them and see what the problems are. please zip them when you send them through

Stinky · Post by **Stinky** » Sun Feb 19, 2006 4:41 pm

I'll do some more logs over the next couple of days and see what I can come up with.

Matt · Post by **Matt** » Sun Feb 19, 2006 6:17 pm

i'll start doing some more logging when i can. unforuntaely my laptop battery isn't lasting too long these days so logs are fairly short in the car

a new laptop should fix that

Matt · Post by **Matt** » Sun Feb 19, 2006 8:31 pm

I get USB consult read errors some times... actually it is around 737rpm - 812rpm that i get them. very strange, not if any slower/faster. need to look into this and see why, something to do with the frequency of interrupts

Your PC isn't able to write to the FTDI buffer chip. perhaps the buffer is full on the chip? Please use the next version of nistune (an update is happening tonight) with extra debug logging. It will get the actual status of the write... value is 0 - 6 as below

FT_OK,
FT_INVALID_HANDLE,
FT_DEVICE_NOT_FOUND,
FT_DEVICE_NOT_OPENED,
FT_IO_ERROR,
FT_INSUFFICIENT_RESOURCES,
FT_INVALID_PARAMETER

I was getting read errors tonight with this particular RPM range

19:36:07 TX:CA 00 00 13
19:36:07 TX:CA 00 00 05
19:36:07 TX:CA 00 00 0C
19:36:08 USBDriver:read: not all expected bytes read
19:36:08 UpdateConsultRegs: Error reading
19:36:08 RX:
19:36:08 TX:CA 00 00 0F
19:36:08 TX:CA 00 00 10
19:36:08 TX:CA 00 00 0D
19:36:08 TX:CA 00 00 0E
19:36:09 USBDriver:read: not all expected bytes read
19:36:09 UpdateConsultRegs: Error reading
19:36:09 RX:
19:36:10 TX:CA 00 00 0F
19:36:10 TX:CA 00 00 10
19:36:11 USBDriver:read: not all expected bytes read
19:36:11 UpdateConsultRegs: Error reading
19:36:11 RX:
19:36:11 TX:CA 00 00 0F
19:36:11 TX:CA 00 00 10
19:36:11 TX:CA 00 00 0D

below you can see its transmitting stuff, but not receiving anything... i'll need to put the scope on the board

Stinky · Post by **Stinky** » Tue Feb 21, 2006 6:19 am

Here are two logs from yesterday. I'll email them as well.

Matt · Post by **Matt** » Tue Feb 21, 2006 3:50 pm

12:47:07 TX:CA 00 00 02
12:47:07 TX:CA 00 00 20
12:47:07 TX:CA 00 00 21
12:47:07 USBDriver:Write: error writing bytes: STATUS CODE: 4
12:47:07 UpdateConsultRegs: Error writing
12:47:07 USBDriver:Write: error writing bytes: STATUS CODE: 4
12:47:07 UpdateConsultRegs: Error writing
12:47:07 USBDriver:Write: error writing bytes: STATUS CODE: 4
12:47:07 UpdateConsultRegs: Error writing
12:47:08 USBDriver:Write: error writing bytes: STATUS CODE: 4
12:47:08 UpdateConsultRegs: Error writing
12:47:08 USBDriver:Write: error writing bytes: STATUS CODE: 4
12:47:08 UpdateConsultRegs: Error writing
12:47:08 check_usb_consult_errors() - too many errors -bye

This is FT_IO_ERROR... need to look into it

Stinky · Post by **Stinky** » Wed Feb 22, 2006 1:49 am

Okay these aren't good logs.... it completely dies in the butt and I dont know why yet. Whats even worse is that im not getting those type of logs here, im getting the other sort (different problem) with read errors at a particular rev range on the bench.... so we have three problems

Z31: ECU missing injections in interrupt routine during long ECU->PC messages
Z31: FTDI chip indicating I/O errors and disconnecting randomly during communications
R31: 6802 chip receiving empty or no indication of arrival of NIStune command around 700-800rpm

I should start being able to look into it tomorrow night. I have also emailed FTDI asking for suggestions

You indicated that you had more problems with a longer USB cable. I suspect noise is causing problems with the setup. Why it is disconnecting I am unsure, but could you please confirm that for me with logs if possible?

Is the ECU completely shielded (ie casing on)? I never run mine with a romulator but did have some USB errors during drives.

Maybe the romulator hanging off is causing problems also in regards to these type of errors. What about if you burn the NIStune image to EPROM, and run that in the car. How does that go, do the problems decrease?

thanks
Matt

Here's everything I've noticed that I can remember...
- I seem to have better luck when the ecu is laying on the floor instead of mounted in the stock location against the kick panel.
- I always have the ecu case on and secure.
- The romulator cable is shielded with aluminum air conditioning duct tape
- I didnt notice any significant difference with a shorter or longer cable

On a possibly related note...
- My wideband has been having issues getting disconnected independant of Nistune.
- The main reason I dont think its directly related is because it only seems to happen when the air fuel ratio goes lean during coast down.
- Nistune and the wideband never seem to die at the same time.
- I've got a new cable and sensor to install so this might clear up this issue.

Things I will do.
- I'll try a chip instead of the romulator
- I'll try completely disconnecting my wideband

Is there any reason I'm only get TX errors and no RX errors? Is it possible theres a problem with my USB ports? I might try a pcmcia usb card.

Matt · Post by **Matt** » Wed Feb 22, 2006 12:11 pm

from the FTDI USB chip support guys:

There are two possible cause of the FT_IO_ERROR (code 4) returned by FT_Write 1) indicates a timeout condition 2) unable to communicate with driver because the device has been removed from the USB bus.

For (1) increase timeouts or if (2) is the cause check that you have:

1. 47pF capacitors are fitted to ground on USB data lines (USBDP and USBDM) between the connector and series resistor.

2. The USB shield is not connected to USB ground, if it is either couple via a 470nF capacitor or leave unconnected.

3. You are using the correct decoupling capacitors (fitted power lines to ground)
i) 10uF lower base band noise.
ii) 0.1uF suppresses noise caused by internal 48Mhz clock
iii) 0.01uF suppresses noise caused by the 6MHz Crystal..
iv) 0.1uF and 470R RC filtering is on the analogue VCC (AVCC).

4. Ferrite bead fitted on the +power line before FT232BM device. This isolates noise form external circuit to FT232BM circuit and visa versa circuit similar to http://www.ftdichip.com/Documents/DataS ... 232b18.pdf page 15 (although for a bus powered design).

(1) timeout condition should not be a concern (we normally get many messages to/from before timeout) unless the interface has stopped working altogether

(2) see below

1. We donâ€™t have 47pF capacitors between USBDP/USBDM connector lines and ground. New board revision we will need to do this (this was not specified on the FTDI datasheet)

2. The USB shield is not connected to USB ground directly. However it is mounted against the ECU chasis. From memory ECU chasis did not directly â€˜buzzâ€™ out to the GROUND (pin 14) on the EPROM socket. However when the ECU is installed to the vehicle will screw against chasis ground.

What this could mean is that when the ECU is not installed correctly in the vehicle, the ECU chasis is not grounded (neither is USB shield in this case). However when installed, the chasis (and hence USB shield) will then GROUND against EPROM GROUND. Regardless, we should connect the 470nf capacitor

3. We are decoupling (ii) [0.1uf] and (iv) [0.1uf and 470R] to ground on the FTDI chip. However I missed the 10uf from the datasheet since ourr schematic came from the DLP Design 245 module rather than specifically from this datasheet. However I donâ€™t see the (iii) [0.01uf] about the crystal at all on the datasheet.

4. We donâ€™t require this item (Ferrite bead) since we are self powered, not USB powered configuration

So we can to add some extra decoupling capacitors to the hardware to filter out some of the noise. However i think the romulator could be causing some errors. Quality of USB cabling and shielding is also another concern which is why longer lengths you reported caused more problems

The more devices (Romulator and Wideband) the more noise that gets generated. Even though you shield the romulator I/O lines, the Atmel controller itself generates noise and could cause problems.

I would like to see if you get any WRITE errors at all just using EPROM in ECU by itself (but with the ECU sitting on the floor rather chasis). Once we've established that, can workout the other problems. I'm getting a CRO to monitor noise levels on the various USB lines to see what increases it/decreases it

Installing romulator inside the ecu may increase noise also....

Stinky · Post by **Stinky** » Sat Feb 25, 2006 2:09 pm

Tried the ecu without the romulator. With the ecu in the stock location I still get the same disconnect with the same errors as posted above.

Next is to try things with the ecu on the floor again.

Anything I can try with the location of the usb connector?

Matt · Post by **Matt** » Mon Feb 27, 2006 1:53 am

floor sounds better because of grounding issues. let us know how floor goes with firmware on EPROM chip

im getting a CRO next week to look into it. also some hardware modifications may be needed (extra caps). i'll look how we can add these to the existing board design

Matt · Post by **Matt** » Mon Feb 27, 2006 4:39 pm

move to hardware bugs

Stinky · Post by **Stinky** » Wed Mar 01, 2006 3:21 pm

I tried the ecu on the floor tonight. It still disconnected after a little while. I plan on trying different cables when time permits.

Also, I got a read error before the usual write errors. Log is attached.