no diodes and resistors necessary
eehack was mostly developed and tested with the rx and tx wires literally twisted together and hanging in mid air, from a cheap ftdi ebay board
no diodes and resistors necessary
eehack was mostly developed and tested with the rx and tx wires literally twisted together and hanging in mid air, from a cheap ftdi ebay board
Well that settles that!! As soon as I get home from work I'll swap out the protection circuit wiring for bare wires and run another test!
Sadly, no good news.
I had already lowered latency to 1ms before posting this thread, so there's that. I did change the USB buffer size to 1024 as in your screenshot just for kicks but that didn't change anything either.
So I tried my FTDI friend, or rather, THIS one from my local electronics store. It was flaky almost immediately. I only managed to complete a read once, after which it said the same "invalid checksum" error. All other attempts it would fail at some random point and force me to yank the ECM fuse to get everything back. I thought it might be bad connection between my test leads and the socket, so I desoldered the socket, soldered together the TX and RX pins, then soldered wires directly to the GND and TX/RX pins. This changed nothing, it was just as flaky as it always had been.
FT_PROG reports that the chipset on both my flaky device and my perfectly-working-except-for-EEHack-Reads ALDLcable is the FT232R. Neither is FT232B. The cable seems to have zero issue talking to the car otherwise, it just won't let me read the ROM in EEHack. My little dongle though, nothing doing.
I suppose I could drop by there and pick up the Adafruit version just to see if that would do anything different. If it doesn't I can always return it. I'll do that tomorrow after work. But for now, I figured I'd drop that update.
odd for sure. just use winflash to read the bin then. you only need to do it once
Update: Local electronics store said they had two FTDI Friends, but in fact they had zero (or they had been misplaced by people so badly that they will never again be found). They did however have the OSEPP version, which other forums are using as ALDL interfaces, so I picked that up. Tossed it on and it ended up exactly as flaky as the adapter I already have, leaving the ALDLcable as the most reliable of the bunch in terms of connectivity. If every single one I threw at it worked exactly the same way that would immediately make me think something was wrong with the car, either electrically in general or specific to the ALDL port's wiring...but the fact that one cable seems to work properly (except for Read in EEHack) and the others don't makes me wonder.
Reading is fine, I've got the BIN. My worry is that I'll start the flash procedure and whatever is causing this sort of behavior will rear its ugly head and brick it. Yet as far as I can tell the issue must be...
1. There is an electrical problem with the car that somehow the ALDLcable is working around better than the FTDI breakout boards.
2. There is a problem with the ROM on the car that doesn't prevent the car from running but does prevent EEHack from working correctly.
3. There is a problem with the latest FTDI driver for the RS232R (2.12.28), which is the driver being used for all of these.
4. There is a problem with my netbook's USB port.
5. There is a problem with EEHack.
I have a second netbook that runs XP, so I will give that a shot just for kicks in a bit.
EDIT: XP netbook worked the exact same way, so at least it's not an issue with my specific netbook or a quirk with Windows 7 x86's serial communications or something.
Last edited by NomakeWan; 07-12-2019 at 01:25 AM.
thing is if the read always succeeds in eehack but the checksum is always wrong, could be a problem with the bin itself. have you confirmed you're running EE and not EEB?
Posting Permissions
Reply With Quote
Bookmarks