Arduino Forum

Using Arduino => General Electronics => Topic started by: monte_carlo_ecm on Jan 23, 2016, 01:03 am

Title: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 23, 2016, 01:03 am
Hi Arduino enthusiasts,

I imagine my problem/question will be difficult to comment on without pouring over my wiring and code, but incase there is something fundamental I am missing, I thought I would ask.  I am very comfortable with programming, been writing code for the better part of 30 years, but electronics is not my strong suit at all.

First I should summarize my project.  I am using my Arduino Mega2560 R3 to read from one port of a Dual Port SRAM chip - in particular an AM2130 (I have tried an IDT7132 with the same result).  The other port is written to by an old 6801 based car computer at the command of an interrupt triggered by the Arduino - I modified the car computer code to add the interrupt routine.  The interrupt routine simply copies the car computer RAM to the SRAM chip so the Arduino can read the data and process it further.  The car computer adds a checksum byte and a request counter to the end of the RAM values it copies so the Arduino can test the data for validity.  Here's the data sheet for the SRAM chip:

AM2130 Datasheet (http://www.digchip.com/datasheets/download_datasheet.php?id=1725808&part-number=AM2130&show=inline)

5 times a second, the Arduino flips a pin connected to the IRQ of the car computer, waits a suitable amount of time for the data to be copied by the car computer (10us - I've tried longer values, doesn't help my issue), then uses an adaptation of this sketch to read the values back (224 bytes total) from the SRAM:

eeprom_read.pde (https://github.com/phooky/PROM/blob/master/tools/eeprom_read/eeprom_read.pde)

Let me refer to the 224 bytes as a Packet.  My issue is that about 0.5% of my packets contain at least one "bad" byte.  I know it must be the Arduino side of the equation, because I wrote a retry routine and sure enough, second pass the Arduino gets the correct value.  Here's an example of my Serial output:


Error - Checksum mismatch!
Checksum error - 3C vs 7C
Retrying and dumping differences:
0 : EE/EE 1/1 76/76 80/80 80/80 66/66 66/66 0/0 0/0 0/0 1/1 CD/CD 4/4 74/74 DE/DE 0/0
10 : 41/41 C0/C0 91/91 1E/1E 2/2 0/0 60/60 0/0 0/0 5F/5F 3F/3F FD/FD 2/2 6D/6D 3F/3F A2/A2
20 : 83/83 59/59 8B/8B 8E/8E 8E/8E 0/0 ED/ED 1/1 14/14 88/88 8E/8E 4B/4B 4B/4B 20/20 7D/7D 47/47
30 : 4B/4B 4B/4B 4B/4B 4B/4B 8C/8C 96/D6 96/96 76/76 86/86 ED/ED 2F/2F 14/14 14/14 0/0 14/14 9D/9D
40 : 46/46 85/85 42/42 0/0 2D/2D 2A/2A 3D/3D AE/AE 4E/4E 63/63 1A/1A D6/D6 55/55 1/1 45/45 0/0
50 : 15/15 83/83 6E/6E 30/30 0/0 6E/6E 1/1 BE/BE 0/0 3/3 0/0 0/0 0/0 0/0 2/2 6D/6D
60 : 0/0 5/5 1/1 43/43 50/50 0/0 39/39 0/0 3F/3F 0/0 0/0 50/50 0/0 39/39 3D/3D FF/FF
70 : 58/58 0/0 0/0 50/50 0/0 0/0 3D/3D 0/0 5/5 FF/FF 58/58 1/1 43/43 0/0 0/0 3/3
80 : 2D/2D 3/3 C/C 0/0 32/32 0/0 0/0 A/A 0/0 0/0 0/0 18/18 0/0 0/0 44/44 6/6
90 : 0/0 0/0 B2/B2 A5/A5 80/80 80/80 40/40 9C/9C 4D/4D 4D/4D 40/40 40/40 40/40 40/40 40/40 40/40
A0 : 40/40 40/40 9A/9A EF/EF 9A/9A 5/5 0/0 2/2 4/4 0/0 0/0 9C/9C 98/98 0/0 29/29 91/91
B0 : 20/20 FF/FF FF/FF FF/FF 0/0 0/0 0/0 88/88 0/0 0/0 0/0 FF/FF 0/0 2/2 0/0 0/0
C0 : 3/3 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0
D0 : 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 C4/C4 43/43 6D/6D 3C/3C
E0 : EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE
F0 : EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE
Differences at bytes: 35


This dump shows each byte read in the first (error) pass, followed by a slash, followed by the byte read in the retry pass.  If you look at the byte at offset 0x35, it differs by exactly the checksum, so the second pass got the right answer.  My request counter is at offset 0xDD/0xDE (16 bits so it doesn't wrap around too fast).  It didn't change between the two reads the Arduino made from the SRAM, so I know that the car computer didn't touch the data due to the interrupt line floating around or something else strange.

What I find really confusing is that, even though 99.5% of the packets are clean, when it does error out, it's just as frequent to have many bad bytes as just one.  Here's another packet with lots of differences:


Checksum error - 78 vs FC
Retrying and dumping differences:
0 : EE/EE 1/1 0/0 80/80 80/80 66/66 66/66 0/0 0/0 0/0 1/1 CD/CD 0/0 60/60 DE/DE 0/0
10 : 41/41 60/60 45/45 2E/2E 2/2 0/0 20/20 0/0 0/0 49/48 34/34 D1/D0 2/2 EF/E9 34/34 0/1
20 : 78/78 D8/5C 8B/8B 9B/9B 9B/9B 0/0 ED/ED 1/1 14/14 95/95 9B/9B 2E/2E 2E/2E 2E/2E 7D/7D 46/46
30 : 2E/2E 2E/2E 2E/2E 2E/2E 89/89 DE/DE DE/DE 37/37 47/47 ED/ED 2F/2F D7/D6 D8/D5 0/2 0/86 C6/C6
40 : 61/61 D7/D7 9D/A7 0/1F 92/54 8D/CC BB/92 3C/8D F5/BB 84/3C 7/7 99/99 18/18 0/0 66/66 0/0
50 : 0/26 34/78 0/36 80/30 0/0 0/CA 0/8 0/9A 0/0 0/2 0/0 0/0 0/0 0/0 2/2 ED/F2
60 : 0/0 8/4 1/1 50/4A 50/50 0/0 39/39 0/0 3F/3F 0/0 0/0 50/50 0/0 39/39 3D/3D FF/FF
70 : 3D/3D 0/0 0/0 50/50 0/0 0/0 3D/3D 0/0 5/5 FF/FF 3D/3D 1/1 50/4A 0/0 0/0 3/3
80 : 2D/2D 3/3 E/E 0/0 32/32 0/0 0/0 A/A 0/0 0/0 0/0 18/18 0/0 0/0 3/3 6/6
90 : 0/0 0/0 67/67 80/80 80/80 80/80 40/40 4D/4D 4D/4D 4D/4D 40/40 40/40 40/40 40/40 40/40 40/40
A0 : 40/40 40/40 81/81 0/0 81/81 1/1 0/0 0/0 4/4 0/0 0/0 80/80 0/0 0/0 0/0 2F/2F
B0 : 20/20 FF/FF 0/0 0/0 1E/1E 0/0 0/0 95/95 0/0 9/9 B4/B4 0/0 0/0 2/2 0/0 0/0
C0 : 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0
D0 : 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 B/B A5/A5 78/78
E0 : EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE
F0 : EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE
Differences at bytes: 19 1B 1D 1F 21 3B 3C 3D 3E 42 43 44 45 46 47 48 49 50 51 52 53 55 56 57 59 5F 61 63 7C


So 29 bytes different between the reads there.  What's funky about this one is that many, but not all, of the error bytes are 0, not just a single bad bit but the entire byte is coming back low.  Regardless of how "severe" the error is in terms of number of bytes trashed, a fraction of a second later it goes back to getting clean packets for a while until the next error.   :o

I can and will code around the issue by enhancing this retry logic to just try reading a few times before giving up on a particular iteration.  That said, there is still a measurable chance that an 8-bit checksum is "fooled" by two or more offsetting bad bytes so I'm still wishing I could find a more robust answer.

I used oshpark.com to make a really nice circuit board for this interface.  I'm using ribbon cables with crimped on connectors (like the old style "IDE hard drive cables").  It looks like this (with the IDT7132 chip installed rather than the AM2130, but like I said, both behave the same):

(http://i1066.photobucket.com/albums/u411/timekiller_9/IMG_20151012_1308242.jpg)

I was careful to use pull-down resistors on both ports for the address lines I don't use (I'm only addressing the lower 256 bytes of the SRAM chip), so the extra address lines aren't floating around.  So I can't see anything sketchy about my wiring or design, it's all put together quite solidly compared to my breadboard version which had the same issue (I thought soldering it all down would help - Argh!)

The one piece that's a little suspicious is that I had to make the ribbon cable that goes between the Arduino and SRAM board about 2.5 feet long because the Arduino can't live very close to the car computer just due to space issues.  I figured that the Arduino isn't going very fast though relatively speaking, and comparing this to running an old IDE hard drive with the same style cable, I remember cables of that length working fine in those applications (did they have to cope with high amounts of error checking/correction in those applications too?)  My breadboard version used a much shorter cable when I had the car computer, breadboard, and Arduino laid side-by-side on the car floor while I was designing this.  I had the same problem then with the occasional errors as I do now.

I guess that sums it up.  Thanks for reading, and any thoughts you might have!

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: MarkT on Jan 23, 2016, 02:04 am
Do you have ceramic decoupling capacitor(s), not just electrolytic?
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 23, 2016, 02:29 am
Hi MarkT,

Thanks for your response.

The only capacitor I have employed is at the 5V Vcc power for the AM2130 chip (you can see it there in the photo above).  If you have a look at the picture I posted above - I run a ribbon cable straight from the shorter of the two header blocks to the Arduino Mega digital pins 22 through 45 - the ones at the "back end" of the Mega.  Traces on that board shown go straight to the AM2130 address/data/select pins.


I know just enough about electronics to be dangerous - almost nothing really.  Can you give me a few hints on where/why/how I would use capacitors to solve the issue?

Thanks again!

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: outofoptions on Jan 23, 2016, 02:58 am
Parallel communication is susceptible to losing data which is why hard drives now use serial.  If all bits don't arrive in the alloted time it doesn't work.  The reliability of serial  ends up making it faster.   To lose a whole byte though I'd suspect loss of clock so the byte failed to 'latch'.  I doubt this is happening but given the intermittent nature I thought I'd muddy the waters with it. ;)
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 23, 2016, 05:26 am
Hi outofoptions,

Thanks for the thoughts.  I'm hoping the problem isn't as complex as what you are aiming at.  The communication in my application is essentially serial.  It's a simple archaic address bus I'm working with, nothing fancy.  The SRAM chip essentially behaves like an old style EPROM, like say a 27C512; all address bits are requested independently by a separate pin, and one data bit is fetched at a time from separate pins.

I'm really hoping to hear more about MarkT's thoughts.  I looked up some info about decoupling capacitors and something smells right about that idea, I just don't know enough about electronics to know how to apply the concept.  Here's why I think he's on to something there:

One thing I forgot to mention in my original question/post:

I can turn the car ignition on but not start the car and the Arduino will consume data error free from the SRAM chip indefinitely.  The data is very boring without the engine started, but it's data, and never corrupt with the engine off.  The issue only occurs with the engine running.

So with that tidbit of additional info... Help?  ???
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: Paul__B on Jan 23, 2016, 07:53 am
I can turn the car ignition on but not start the car and the Arduino will consume data error free from the SRAM chip indefinitely.  The data is very boring without the engine started, but it's data, and never corrupt with the engine off.  The issue only occurs with the engine running.
Well, that rather says it all, doesn't it?
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 23, 2016, 08:49 pm
Hi Paul__B,

Probably that says it all, yeah.  I regret not mentioning that detail in the original post, it wasn't until the questions started coming about decoupling capacitors that my train of thought shifted to it.  I've been a software guy all my life, hardware and electronics is not a strong part of my background.  My brain just wanted to park that detail as irrelevant because the car computer isn't doing very much without the engine running, much of the data is 0's and hardly anything changes over time.  But I can see now that's just my software based perspective being wrong.

Engine noise certainly seems like a reasonable suspect.  We're not at all talking about a quiet/modern engine here.  It's a heavy old Chevy 305 8 cylinder 5 liter with an aftermarket ignition module and medium cam shaft - so muscle car stuff basically. 

So all that said, I'd still be super grateful for some hints/details on what capacitors to choose and where to locate them.  If the location answer is right near the Vcc for the SRAM chip - Do I even need that 10uf electrolytic capacitor or can I reuse that spot for a different capacitor or perhaps pair of capacitors?  I have no reason to have chosen the 10uf electrolytic, I just read something that says capacitors should be used at the Vcc of all integrated circuits so I stuck it there kind of randomly chosen.

Just so everything is out on the table - I power the SRAM chip from the +5V coming out of the port on the car computer; these old GM car computers had unused edge connectors on them (probably intended for factory diagnostics) that expose the entire address/data bus, interrupts, etc. and of course a few +5V and ground pins, so that's what I'm interfacing with.  I built one of these (image below) to power the Arduino Mega (I replaced 7805 with 7809 to satisfy the Mega's need for 7-12V, all other components are the same as in the schematic) taking the input power for that circuit from a spare ignition power on the car fuse box:

(https://lh6.googleusercontent.com/-t44ht0HkrFQ/SejGUBsSSFI/AAAAAAAAFz8/ey210YoXJ4Y/w773-h306-no/PowerSupply.JPG)

The fuse box is on the left side of the car and the car computer/Arduino on the right, so I had to run a few feet of cable to from the fuse box to this power rectifier circuit which I hide behind the radio in the middle of the car, then another few feet to run from the power rectifier output to the Arduino

I'm hoping I can find a way to fix this issue without redesigning my SRAM circuit board, but I shouldn't get ahead of myself here...  Anyone willing to help me select component(s) and location(s) to hopefully smooth out the noise issues?

Thanks for everything so far folks!
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 24, 2016, 07:51 pm
Anyone able/willing to help me take at least a decent guess at a value and location for a decoupling capacitor that might help my noise issues with this circuit?

I'm about ready to hook up my Saleae Logic Analyzer to try to capture the analog signal on a glitched data line, but even if I do manage to catch it in the act and find the point in time, I'll still not have enough electrical knowledge to apply a fix.

Thanks!

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 25, 2016, 07:43 am
I'm trying to collect as much data as possible here in hopes that someone with some background in electronics will be enticed to help me close up this glitching issue likely coming from engine noise.

It turns out that the Saleae knock off that I bought from ebay some time ago and never tried is not the analog capable version, just the old Logic 16 digital only version.  Regardless, I figured I'd give it a go and try it out.  I hooked it up at the SRAM chip, put in a "trigger" from the Arduino so I could find errored packets and went for a test drive.

Here's an errored packet:


Error - Checksum mismatch!
Checksum error - 9C vs 30
Retrying and dumping differences:
0 : EE/EE 6/6 9A/9A A2/A2 80/80 AD/AD 66/66 0/0 0/0 0/0 2/2 36/36 4/4 70/70 DE/DE 0/0
10 : 41/41 86/86 81/81 3E/3E 2/2 0/0 62/62 0/0 0/0 57/57 3C/3C EE/EF 2/2 94/93 3C/3C 0/0
20 : 78/78 A3/2A 8C/8C 9E/9E 9E/9E 0/0 F0/F0 1/1 17/17 95/95 9E/9E 4B/49 4B/49 20/20 7D/7D 47/46
30 : 4B/4B 4B/49 49/49 49/49 8C/8C 67/67 67/67 9A/9A AA/AA EE/EE 2C/2C 35/35 1C/1E 0/0 5B/3F AE/AE
40 : AF/AF C1/C1 C5/C5 4/1 FF/FF EF/EF 12/12 10/10 23/23 29/29 19/19 52/52 50/50 3/3 E2/E2 0/80
50 : 16/FF 78/2A 8D/52 30/20 0/0 73/C7 0/0 B6/BE 0/0 2/3 0/0 0/0 0/0 0/0 2/2 94/92
60 : 0/0 1/3 1/1 41/43 50/50 0/0 39/39 0/0 3F/3F 0/0 0/0 50/50 0/0 39/39 3D/3D FF/FF
70 : 51/51 0/0 0/0 50/50 0/0 0/0 3D/3D 0/0 5/5 FF/FF 51/51 1/1 41/43 0/0 0/0 6/6
80 : 9B/9B 6/6 1C/1C 0/0 32/32 0/0 0/0 A/A 0/0 0/0 0/0 18/18 0/0 0/0 D2/D2 B9/B9
90 : 0/0 0/0 BF/BF BF/BF 80/80 80/80 9C/9C AC/AC 4D/4D 4D/4D 77/77 7C/7C 40/40 40/40 77/77 77/77
A0 : 40/40 40/40 B6/B6 2F/2F B6/B6 5/5 0/0 2/2 2/2 AD/AD 17/17 AC/AC 66/66 0/0 29/29 91/91
B0 : 20/20 FF/FF FD/FD FF/FF F/F 0/0 0/0 95/95 0/0 1/1 0/0 FF/FF 0/0 2/2 0/0 1/1
C0 : 5/5 C9/C9 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0
D0 : 0/0 0/0 0/0 0/0 0/0 0/0 1/1 0/0 0/0 0/0 0/0 0/0 0/0 75/75 F2/F2 9C/9C
E0 : EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE
F0 : EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE EE/EE
Differences at bytes: 1B 1D 21 2B 2C 2F 31 3C 3E 43 4F 50 51 52 53 55 57 59 5F 61 63 7C


With 16 pins on the logic analyzer I only have enough for the lower 4 data bits after the trigger, chip select, read/write, enable, and address lines - without those I can't find the point in time where the data is "bad" at the Arduino, nor can I prove that the inputs to the SRAM are good.  Regardless, that's good enough to prove the point.  I wanted to have a look at Byte 0x50. especially  It should be 0xFF as the retry read shows.  But the first read gets 0x16.  Looking at the logic analyzer at the packet just before my trigger pin fired because of the error I see this:

(http://i1066.photobucket.com/albums/u411/timekiller_9/checksum_error_study_20160124_1600_zpsevcncak1.png)

So D0-D3 are all 1 for the entire read period of that byte.  D0 and D3 would be 0 at some point if the answer was really 0x16.  So the Arduino is getting the wrong answer.  My first question is - would the logic analyzer have seen something different if I hooked it up AFTER the 2.5 feet of cable beyond the SRAM chip?  Do I need to hook it up at the Arduino instead of the SRAM chip?

I checked a few other error bytes as well, same thing, logic analyzer doesn't see what Arduino sees, logic analyzer sees the right answer for the entire period the output enable pin is set to read data.

Here's the only thing I saw that's suspicious.  Take a look at this overall picture:

(http://i1066.photobucket.com/albums/u411/timekiller_9/checksum_error_study_20160124_1600_2_zpsoefbacg2.png)

The Arduino requests a data transfer 5 times a second and that corresponds to the little rectangular blocks of activity.  But then during what should be quiet time, the logic analyzer sees a little blip on some of the pins, designated by the thin lines scatter through the timeline occasionally.  Zooming in on one of them, it's very brief and affects what seems to be a random set of pins:

(http://i1066.photobucket.com/albums/u411/timekiller_9/checksum_error_study_20160124_1600_3_zpskq11efnd.png)

Does this help shed any light on what needs to be done to eliminate these occasional data glitch issues I'm getting at the Arduino side?  Any thoughts are appreciated!

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 27, 2016, 11:24 pm
Taking a bit of a shot in the dark, I replaced the 10uf electrolytic capacitor I had on my SRAM board running between VCC and ground with a .1uf ceramic disc capacitor - based on what I was reading online about similar SRAM chips and IC's in general, the .1uf ceramic disc seemed to be the best general purpose decoupling capacitor for such an application.

I took the car for a test drive.  Very similar results - an errored packet at random times, on average about one per 800-1000 queries.  Sometimes just one byte, sometimes a few, and other times 20-30 bytes.

I still don't get why the logic analyzer doesn't see it but the Arduino does.  :o

At the risk of focusing on the wrong thing, I'm going to drop one more question here - can the Arduino Mega (+ EasyVR voice recognition shield + SparkFun MP3 shield [doing nothing but waiting] + 16x2 LCD display) run for any reasonable length of time on a 9V battery?  I'd need about 15 minutes to really prove things as the same or different.  Would driving it with a battery source prove anything in terms of targeting or eliminating the power supply I built (schematic above) for the Arduino from the car fuse box?

Whatever it is I have been saying or not saying here hasn't caused much in the way of repeat engagement.  So I'll probably just rely on my checksum/retry logic for the time being, but if at some point anyone has any ideas or similar experiences, I will be listening with a burning curiosity!

Thanks for reading!
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: outofoptions on Jan 28, 2016, 12:55 am
I haven't verified it but the Atmega chips aren't rated for use in automobiles according to a post someone made.  They supposedly took the info from the data sheet.  Could be they know something.
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 28, 2016, 01:52 am
That's a good thought outofoptions.  At some point I may need to accept that the Atmega (Arduino) isn't entirely happy in a car.

Please disregard the question about the battery above.  I wasn't thinking straight.  I ran out and pulled the plug out of the power port on the Arduino and ran it off Laptop USB power.  Same result.

But I have a new suspect.  While I thought I had done this before, it may not have been with the engine running.  I wiggled the ribbon cable I have on my SRAM board going to my Arduino a bit while the engine was running.  Sure enough, I could clock dozens of errors that way.  Took apart the cable and found that I must have slightly bent some of the crimping pins on the ribbon cable connector at the SRAM end.  I imagine this could have led to a breach of the wires on the cable too.  Just as a quick experiment, I tried to clean up the pins a bit with a jeweler's screwdriver and a magnifying glass and then reinstalled it for a test.  While I seem to get the same number of errors, it happens on its own on only one byte in each errored packed, I didn't get a single errored packet with > 1 byte bad.  And I can still make it error violently by wiggling the cable at the SRAM end.

That cable is very likely toast, I need to get another cable.  I'm trying to remember why I didn't just use an old 26-pin floppy cable from the electronics surplus place instead of building one from cable and connectors myself - the pre-built cable should be a heck of a lot more robust and reliable than my hand built one if I can get one in the right length, gender, and without that weird twist they put in those old cables as I remember!  I need to go by the surplus place near me and see if they have an old floppy cable that would work.

Consider it in my hands for now until I can prove my cabling is good.  Thanks to everyone for reading thus far and helping talk this through with me, I really appreciate it!  I feel pretty lame that I posted prior to being 200% sure my cables were rock solid.  My apologies for that!
 
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 28, 2016, 02:05 am
I didn't use a floppy cable because they were 34-pin not 26-pin.  Been so long since I've touched a floppy drive I had forgotten how many pins they were.  I might need to search for another source of a pre-made 26-pin cable...
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: Paul__B on Jan 28, 2016, 11:02 am
That's a good thought outofoptions.  At some point I may need to accept that the Atmega (Arduino) isn't entirely happy in a car.
Nonsense!  A microcontroller is a microcontroller.  Silicon is very similar, one family to another.

Rating for automotive use focuses on temperature specifications for modules in the engine compartment and whether the manufacturer feels like warranting this specification.  If it isn't in the engine compartment, that is generally not a concern.

It is your business as the designer to condition the supply voltage and all the inputs (and outputs) to their specified values.  If you allow those to stray, then no microcontroller (or clearly, any other device) will be warranted to function.
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 28, 2016, 05:12 pm
Thanks for the encouragement Paul__B.  I'm actually hoping I can get it performing satisfactorily with a new cable.  This won't be the first time in my project where I've been reminded that something which isn't completely rock solid may seem to work okay on the "bench" but then act strangely in the field because of the more hostile conditions.

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: outofoptions on Jan 28, 2016, 05:31 pm
I used to see this in my past life regarding appliance repair.  When they started putting computer boards in refrigerators guys would always assume the board was at fault because that is what they least understood so it became their focus.   It's as though they suddenly forgot how to do simple continuity checks on simple components and didn't check the things they KNEW how to check.  Like cable ends? ;)  I hope that is your answer.
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 28, 2016, 09:46 pm
Well, I bought a proper IDT crimping tool and some new 26-pin IDT connectors.  Built a new cable, much better than the one I was working with before, I can wiggle the cable as much as I want and I can no longer produce errors on command.

Unfortunately, and to my surprise and great disappointment, the random errors while the engine is running continue.  Back to the same old symptom, often just one byte but sometimes a whole stream of multiple bytes.  Same approximate frequency of occurrence as before.  I guess my old cable was "good enough as long as you didn't touch it"; I mean, I'm glad I changed it out because that's no way to run things, but just to say that it looks like the true underlying issue I'm looking for is elsewhere.

I bought two more connectors than I needed to rebuild the cable, maybe what I'll do is build a really short cable with those just to run a test to see if it changes anything.  Aside from that I'm out of ideas.

Thanks again everyone for your thoughts and ideas so far...
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: Paul__B on Jan 29, 2016, 11:30 am
I will suggest it is all about "lead dress" - how you run the leads from one part to another.

Any time you form a "loop" you have a potential for problems; you will generally be better off with all the connections to one part running together.

The ground in particular is important; while it has always been convenient in automotive wiring, to use the chassis as the ground return, that is not  appropriate for digital electronics unless you have isolation of communication lines; opto or transformer - and also in general for radios where preferred practice is to operate from a cable pair directly from the battery; though I am not suggesting that here.

So either all the connections to your recorder come directly from the car computer, or vice versa.  Having their power supply from different grounds is not appropriate.
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 29, 2016, 06:30 pm
Thanks for your thoughts on the power/ground sources Paul__B.  I had been putting some thought into that, though I'm not sure how I could do it better.  Maybe I can explain how it's done here as succinctly as possible and you could comment on suitability?

I'll start with the car computer.  The schematic looks something like this:

(http://www.exatorq.com/ludis_obd1/1227170sheet1.gif)http://www.exatorq.com/ludis_obd1/1227170sheet1.gif (http://www.exatorq.com/ludis_obd1/1227170sheet1.gif)

Mine is a slightly different model, but most of the pins are the same.  Notable differences - Pin 38 is actually ~IRQ not RFDENABLE, and Pin 35 is +5V.

The connector J3 on the left of the schematic translates into the edge connector on the left of this image.

(http://www.thirdgen.org/forums/attachments/diy-prom/147181d1195576855-1228079-info-bccs-diagrams-079-over.jpg)http://www.thirdgen.org/forums/attachments/diy-prom/147181d1195576855-1228079-info-bccs-diagrams-079-over.jpg (http://www.thirdgen.org/forums/attachments/diy-prom/147181d1195576855-1228079-info-bccs-diagrams-079-over.jpg)

That connector is not used by the car computer, you can even see the shiny plastic layer they coated the board with all over those pins.  That has to be carefully scraped off in order to make use of it; I'm confident I did a very good job with that and that my connections are solid there.

So I use a 40-pin edge connector and a few inches of ribbon cable to a 40-pin IDT connector to map the address/data lines as well as Chip Enable, Output Enable, and Read/Write to one port of my dual port SRAM.  Pin 35 from the computer powers pin 48 of the SRAM, and similarly, Pin 39 from the computer grounds pin 24 of the SRAM.

(http://i1066.photobucket.com/albums/u411/timekiller_9/IMG_20151012_1308242.jpg)

The 40 pin connector on the right is where my ribbon cable from the computer edge connector goes.  That electrolytic capacitor in the picture has been replaced with a 0.1uF ceramic disc.

The Arduino has different power requirements (7-12V) than the car computer and SRAM, so I built a separate power supply for it from this circuit:

(https://lh6.googleusercontent.com/-t44ht0HkrFQ/SejGUBsSSFI/AAAAAAAAFz8/ey210YoXJ4Y/w773-h306-no/PowerSupply.JPG)

Only difference being I used a 7809 power rectifier in order to get 9V rather than 5V.  That circuit is supplied from the car's fuse box and is currently grounded to the car chassis on the opposite side of the car from the computer.  Should I have grounded that power supply circuit at the car computer instead?  And the 12+V power supply input, should that come from somewhere else?  I'm squeamish about integrating power supply stuff with higher voltage into the car computer because my understanding of what will happen is weak, and it's a crap-tonne of work to retrofit that computer to take over the code and move it from ROM to EPROM - if I pop it my heart will be forever broken!

The rest of the Arduino wiring to the SRAM board is pretty straight forward, no power or ground, just digital pins for Address/Data plus Chip Enable, Output Enable, and Read/Write, all on the second port.

Any thoughts on what could/should be changed where I might have a "loop" or other problems?

I hope I'm striking a reasonable balance between detail and succinctness here.  Thanks so much for reading, considering, and advising!

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: Paul__B on Jan 29, 2016, 11:17 pm
Should I have grounded that power supply circuit at the car computer instead?
That's what I said.

And the 12+V power supply input, should that come from somewhere else?
It should come from the same place as the car computer, and the cables should run together.  Obviously you can (should) use a common supply cable to both, splitting it to the corresponding two regulators at the car computer (that is, it supplies the car computer regulator and goes on to the recording computer along with all the other cables).  Similarly for the ground, and as long as no other ground connection is made anywhere.
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 30, 2016, 01:43 am
That's what I said.
Thanks for clarifying your suggestion Paul__B.  I wasn't sure exactly what you meant by "recorder".  In my mind prior to us discussing this, the "recorder" is just the SRAM because the Arduino is connected to a separate port of that dual channel SRAM.  You are including the Arduino in the scope of the recorder, I get that now.

It should come from the same place as the car computer, and the cables should run together.  Obviously you can (should) use a common supply cable to both, splitting it to the corresponding two regulators at the car computer (that is, it supplies the car computer regulator and goes on to the recording computer along with all the other cables).  Similarly for the ground, and as long as no other ground connection is made anywhere.
I'm going to try your recommendations some time in the near future because clearly what I don't know can hurt me.  It's a more involved retrofit to redirect the power/ground for that Arduino power supply than, say, replacing a ribbon cable, so it could take me some time.  One of the more difficult pieces will be figuring out how to splice into the power/ground at the car computer in a clean and non-destructive fashion.

If you don't mind - can I ask you one more thing so I don't waste your time later?  Let me come back to this picture for a second:

(http://www.thirdgen.org/forums/attachments/diy-prom/147181d1195576855-1228079-info-bccs-diagrams-079-over.jpg)http://www.thirdgen.org/forums/attachments/diy-prom/147181d1195576855-1228079-info-bccs-diagrams-079-over.jpg (http://www.thirdgen.org/forums/attachments/diy-prom/147181d1195576855-1228079-info-bccs-diagrams-079-over.jpg)

That's the car computer again.  The 12V ignition power and ground connections come in on one of the two edge connectors on the right (I'll have to refer to the schematic again to find out which pins exactly, I figure it's not important for this question.)  The 5V rectifier is under the heat sink at the bottom of the image.  If I can figure out a nice way to splice into the ends of the wires that come into the edge connector, is that satisfactory in your mind?  Or do I have to splice off the input and ground right at the power rectifier?

Thank you very much for reading/considering my design and providing some tips.  I really do appreciate it.

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: Paul__B on Jan 30, 2016, 11:03 am
If I can figure out a nice way to splice into the ends of the wires that come into the edge connector, is that satisfactory in your mind?  Or do I have to splice off the input and ground right at the power rectifier?
When I refer to loops, I mean substantial ones - where the various connections are separated by more than the width of the circuit board.  It would be appropriate to splice into the connection to the edge connector.

When you initially referred to a "car computer" using a 6801, I was thinking of an after-market project - this begins to look like standard equipment ("Delco" - the chips have OEM markings, not Motorola - and if anything based on the 6802 as the 6801 was never a going proposition) built into the loom.

The point is - this computer and your attachment each have their own regulator, you wish to derive common power from the supply that feeds this, not the board itself, and that includes the ground - from the loom.
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Jan 30, 2016, 07:46 pm
Thanks Paul__B.  I'll try to wire something up soon that's robust enough for a test drive.  I fiddled around with a spare edge connector that I pulled from the junkyard a while back and I think I should be able to run a test without too much hacking.

Yes, it's substantially an OEM computer, from a 1987 GM with a computer controlled carburetor.  One guy on the car forums that knows entirely too much about this era of GM computers told me it was "based on the 6801 but specifically made for GM/Delco".  So far I haven't noticed any difference from a command set point of view, maybe the pinouts are slightly different or something.

There's one significant difference in my computer in that I replaced the 1K EPROM with a 64K EPROM, and built a daughterboard to replace a 74LS138 demultiplexer in order to redirect the ROM range to the EPROM thereby allowing me to add/change the code, and direct an unused address range to that dual port SRAM.  It looks like this:

(http://i1066.photobucket.com/albums/u411/timekiller_9/P1040927_zps4vlrc279.jpg)

I took that picture a while back - I have since added 0.1uF ceramic disc capacitors between +5V and ground on my EPROM and my demultiplexer and gate chips based on the advise I've been getting here.  Also if you look close you'll see that two of the gates on the lower 74LS00 are not wired up in that picture - that has since been resolved.

One day I want to use OSHPark to make some nicer boards.  I'm still pretty confident that this piece is working fine though because each time the Arduino gets a checksum error, re-reading gets the right answer.  So the car computer appears to be reliably dumping its RAM to SRAM.

I got to wondering last night, seeing as the car computer and SRAM are powered from the same source without a (substantial) ground loop, when I power the Arduino from my laptop via USB and the laptop battery ultimately (and pulling the plug from the extra 9V power source I built), does that still form a ground loop?  When I tried that, I got pretty much the same error rate.

Anyway, many thanks once again!

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Feb 02, 2016, 12:48 am
Okay, so I soldered a new cable to the ends of the 12V and ground pins on the edge connector that connects to the car computer.  That now powers my voltage rectifier circuit which in turn powers the Arduino.

Test drive gave me the same data error rate as before.  I did have my laptop plugged into the Arduino's USB in order to view the Serial monitor to see the nature of the errors.  Could a laptop running off its own USB power (not charging from the car lighter or anything) be introducing noise to the circuit?  At some point I will of course try it without the laptop plugged into the USB (I have a little 16x2 LCD that shows various measurements from the car memory, as well as the error count) but I'm not hopeful there will be a difference.

The only other idea I have is to get a cheap Mega knock-off and swap it in just to see if maybe my Arduino is flaking for some reason.  Since my Saleae Logic analyzer doesn't see any glitches in the periods of time the Arduino gets a bad reading, I wonder if it could be true that the Arduino is somewhat fried?  Seems a bit of a stretch in that it generally functions well, but I don't know what else to try!  :'( 

Any other ideas are of course greatly appreciated!  Thanks for putting up with me sorting out my design and build basics!

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Feb 03, 2016, 01:42 am
I was just reading through the forum trying to learn a little more and came across this post from MarkT in the thread "Wiring S-R Flp-flop to arduino (http://forum.arduino.cc/index.php?topic=373640.0)"

TTL is _not_ directly compatible with the ATmega inputs - they require 3.0V or more for logic high,
74LS only guarantees 2.7V unless you use a pull-up resistor on the output - I doubt the built-in
pull-ups are strong enough though, I'd suggest 10k external for LS, 1k external for plain TTL.


In my case I'm getting occasional "glitches" from my SRAM chip in the form of both incorrect high and incorrect low, but maybe there is still something to this?

The AM2130 Datasheet (http://www.digchip.com/datasheets/download_datasheet.php?id=1725808&part-number=AM2130&show=inline) isn't clear about whether the chip is strictly TTL or not.  It says "All inputs and outputs are TTL-compatible".

In the charts about half way through the datasheet it says

Vol1 Output LOW voltage (I/O0 - I/O7)   Max 0.4 V
Voh  Output HIGH voltage Min 2.4 V (lower than the 3.0 mentioned by MarkT).

I have tried setting the data input pin modes to INPUT and INPUT_PULLUP, I don't really notice any difference, glitches appear at about the same rate.

Am I barking up the wrong tree here or could there be something to this?

Assuming there could be something here - I only need to read (not write) the SRAM at the Arduino side.  Can anyone advise what the simplest way to resolve this might be, assuming I need this style of SRAM chip for the other side of the communication?  Should I use something like a CD4505B-EP CMOS HEX VOLTAGE LEVEL SHIFTER FOR TTL-TO-CMOS (http://www.digchip.com/datasheets/download_datasheet.php?id=1132856&part-number=CD4504B-EP&show=inline)?




Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: Paul__B on Feb 03, 2016, 10:39 am
The AM2130 Datasheet (http://www.digchip.com/datasheets/download_datasheet.php?id=1725808&part-number=AM2130&show=inline) isn't clear about whether the chip is strictly TTL or not.  It says "All inputs and outputs are TTL-compatible".
That is correct.  It is TTL compatible, but not CMOS compatible.  Its outputs may require 4k7 pull-ups to be CMOS compatible.  (The Arduino is CMOS.)
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Feb 03, 2016, 05:41 pm
Thank you Paul__B, I appreciate you confirming that.  Running these tests is a lengthy process to retrofit and setup so it really helps to know that the effort is worthwhile.

I figure I'll put a 4.7K ohm pull up on just one data line using a couple of test leads and see what happens.  I get errors pretty consistently (while still randomly, if that makes sense!) across all the 8 data lines, but my hope is that if this is the issue, the one line with the resistor on the test leads should never contain an error during the test run.

Fingers crossed...
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Feb 03, 2016, 10:04 pm
Okay, so I tried the 4.7K ohm pull up resistors on two data lines.  Same error rate on those two lines as always.  Since I had the test leads already hooked up I also tried 1K ohm and 10K ohm resistors, no difference in results.

I'm back to thinking the issue is entirely related to the very noisy environment with a heavy old 8 cylinder engine running and a high voltage ignition box to boot.  I keep wanting to blame the Arduino (ie that I fried it some how, not by its nature) or my design somehow, but then I pinch myself and remember it only happens with the engine running!

I'm going to try a twisted ribbon cable if I can get one at the local surplus place in 26-wire.  Shielded too if they have that in 26-wire.  I also read that ferrite cores at each end of ribbon cables can improve the situation in noisy environments like cars.

Of course, any other ideas are more than welcome!

Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Feb 05, 2016, 01:33 am
I'm hoping someone can help me validate what I think I am seeing in terms of power usage and availability in my project.  I've tried to do as much homework as possible, but I'm essentially a Noob, so I'm at the point where I think I have something but really need an experienced eye to pass it by for a reality check!

Quick background why I got on to this: While I was picking up shielded cable and ferrites, I decided to grab a 74HCT245 Octal bus tranceiver (http://www.nxp.com/documents/data_sheet/74HC_HCT245.pdf) based on some things I was reading about people wiring up IDE drives in their car over long lengths of ribbon cable and the signal not being strong enough.  I'm not using an IDE drive, but it's the same style cable, and thought it was worth a shot to see if I could change things with a "buffer" of sorts.  Easy enough to wire up on a breadboard, I was done pretty quick.

Well, to my surprise it made things worse.  I started getting occasional errors at Ignition on but Engine off even.  The car computer even rebooted itself at one point.  I went for a quick test drive but returned quickly as my Arduino started reporting huge streams of errors and the usual "just reread it and its okay" wasn't working.

Alright, so I got to thinking about power.  I'm powering my SRAM chip (and hopefully temporary 74HCT245) from the car computer's edge connector.  I think I mentioned in a previous post that I want to do it this way because I want everything on that computer's bus to be powered by the same source; I don't want the computer crashing because something on the bus loses some alternate power source.  So I begin to wonder if the computer's power circuitry can supply enough power for the computer itself and the extra chips.  Here's where the questions start.  Taking a look at the schematic for the power section of the car computer:


(http://www.exatorq.com/ludis_obd1/1227170sheet7.gif)Larger Version (http://www.exatorq.com/ludis_obd1/1227170sheet7.gif)

It's not a simple little 7805 mechanism.  From what I can tell based on write-ups I've seen online with respect to power rectifiers using transistors, it would appear that R2 in that schematic is a current limiting resistor.  Is that true?

I'll assume it is for now and continue with the follow-ups.

VCC is 5V, I know that of course.  And if R2 is a current limiting resistor, if I understand ohms law correctly, we go I=V/R, I=5/5.1, so I = ~980mA.  Is that correct, and does that mean that VCC is limited to 980mA across the entire circuit?

Again, I'll assume that is correct and pose the next follow-up for now:

The proprietary CPU in the car computer is some derivative of the Motorola 680x.  Apparently 6801.  Something close to that anyway, the instruction set is the same for sure.  Taking a look at the datasheet (http://datasheets.chipdb.org/Motorola/mc6801_3.pdf) I see:

Internal Power Dissipation    Pint    Max = 1200 mW.

So I think that in order to determine the current requirement I go:

P = VI, therefore I = P/V, I = 1.2 / 5, so I=240mA.  Did I get that right?  The CPU alone can take about 25% of the maximum available current in the worst case scenario?

Might as well continue, hopefully I'm not way off so far...

Taking a look then at the AM2130 Datasheet (http://www.digchip.com/datasheets/download_datasheet.php?id=1725808&part-number=AM2130&show=inline) for the SRAM I've added into this power supply, I see:

Absolute Maximum Ratings.....Power Dissipation..... 1.2W.

Same formula then as the CPU.

The 74HCT245 is rated at 750mW max.  Perhaps I'm pushing an already marginal current limit way over the top adding it to the circuit?  I think that's just a rhetorical question and inferred by answers to the other questions so I'm not bolding it.

If everything above is correct or at least close, then half my available current is gone, and there is still onboard RAM, ROMs, ADC converters, various gates, etc. to power.  If that is correct Are my symptoms at all consistent with trying to draw more than the maximum available current?

Final follow-up question for now then, and of course the big one because this is where it potentially gets dangerous what sort of good or bad things will happen if I jump that 5.1ohm current limiting resistor with a, say, 3ohm resistor in order to boost the maximum current by about 25%?

Gosh, I hope I'm at least somewhat on target here, and that some kind soul is willing to help me clear away the fog in my mind!  Thanks ever so much for reading and considering!   :)
Title: Re: Occasional error reading from AM2130/IDT7132 Dual Port SRAM
Post by: monte_carlo_ecm on Feb 10, 2016, 08:28 pm
It looks like I may have been overcomplicating things worrying about current limits or the possible need for a line driver/buffer.  I still have a question below but it's much simpler.  If anyone is still following my saga here, I'd appreciate tips on how to complete my setup!

Real quick, I made a new data cable out of shielded 26-conductor ribbon cable to run between my SRAM and Arduino.  A picture is probably best - top is before, bottom is after.

(http://i1066.photobucket.com/albums/u411/timekiller_9/P1040994_zpsekwm2iu5.jpg)

It took me some time to make this cable because it seems as if the cable itself inside of the outer shielding is stronger; my crimper kept destroying the connectors as I tried to put them on the cable and I had to run back to the electronics store to get a handful more of them!  This did not happen with the cable I was first using - the connectors crimped on like butter.  With this new cable, the connector has to be very well centered in the crimper and I have to squeeze really slowly and progressively more firmly or the connector pins either crush all over the place or don't cut through.

Anyway, I put the cable in the car and went for a 15 minute test drive.  In that amount of time with the previous cable, I would have had 5-10 errored packets easily.  With the new cable, zero, none, perfect run.

So it looks like engine noise in cars is even more evil than I imagined.  My two remaining questions then:

There is a wire mashed in between the foil shielding and the outer heavy plastic housing on the ribbon cable.  I have grounded that close to my common ground on the car computer.  Should it be grounded only at that end, or at the Arduino as well?

I bought a ferrite clip for the ribbon cable, I figure I might as well use it since it's mine now.  Is there a "correct" location for that to go?  ie. at the transmitting end (SRAM), receiving end (Arduino) or somewhere in the middle?  The cable is just about 2 feet long.

Thanks to everyone for reading and throwing in ideas, I really appreciate it.  I think perhaps my struggles with this may soon be over!  I think it's a really cool project.  If anyone wants to see some of a fun video of what it does, here's a link to a sample video I made for the car enthusiasts (with the old cable so 40 checksum errors by the time I call for it):

Arduino Mega 2560 & 1987 Monte Carlo SS (https://youtu.be/sy1WX-nUdm4)

The first 45 seconds or so are pretty boring because I'm waiting for the engine to heat up ("closed loop" in car terms).  After the 5 minute mark there isn't much more to see.