[Gmecm] On the fly tuning

Craig Moates craig
Fri Jun 30 14:08:55 UTC 2006


Darren,

The entire content of the Flash is emulated via the 2-bank RAM. So it boots from 'ROM', but boots from the 'RAM' of the emulator. I
could also have set it up so that the emulator only kicked in when certain addresses were accessed and let the ROM kick in when
other areas were being used, sort of flip-flopping back and forth. That would prevent the need to change lookups and what-not, but
you'd have to make the swap pretty fast and avoid contention. I guess the same is true for what you were thinking of, assuming you'd
be sharing the same data bus as the Flash. We do that with some of the Ford applications and it works well. However, there's not
that much room left in the RR architecture now. The CPLD is just about jamb-pack full, especially with the trace functionality ;^).

Best regards,
Craig Moates



----- Original Message -----
From: "Darren Freed" <darrenfreed at gmail.com>
To: <gmecm at diy-efi.org>
Sent: Friday, June 30, 2006 3:21 AM
Subject: Re: RE: [Gmecm] On the fly tuning


> Craig,
>
> That's some very cool stuff.  That's basically where I was headed, but
> you're way ahead of me!  My plan was to have only the cal data in the ram,
> but that would require changing all the lookups in the code to point to the
> ram rather than rom - a bit tedious to say the least, but not impossible.
>
> So does yours boot from ram or rom?
>
> darren
>
>
> On 6/29/06, Craig Moates <craig at moates.net> wrote:
> >
> > Steve,
> >
> > Yes, that's right. You can disable the onboard flash nicely that way. I've
> > done that already, where you force the ROM CE high and
> > you can essentially throw the whole onboard Flash into high impedance
> > mode. Then you can apply your own bootstrap RAM/etc to shadow
> > the ROM code and act as an emulator. That way you don't even have to
> > remove the Flash chip to achieve the RT emulation, just disable
> > it by forcing the flash CE high.
> >
> > I looked into doing something via dual port, but it ended up being a bit
> > prohibitive in terms of architecture/availability/cost. I
> > ended up going with parallel battery-backed SRAM with decent logic in
> > between for effective gating/muxing.
> >
> > Here's a couple of pics of the present (and past) implementations:
> > www.moates.net/images/rr2/
> > That stuff all goes right off the pads of the flash location, not the edge
> > connector, but it could be done on the edge connector as
> > well (install a little more tedious I suppose).
> >
> > Best regards,
> > Craig Moates
> >
> >
> >
> > ----- Original Message -----
> > From: "Steve Ravet" <Steve.Ravet at arm.com>
> > To: <gmecm at diy-efi.org>
> > Sent: Thursday, June 29, 2006 4:50 PM
> > Subject: RE: RE: [Gmecm] On the fly tuning
> >
> >
> > As far as shadowing goes, one of the pins on the expansion connector is
> > a ROM disable signal.  You could add a dual port RAM to the connector,
> > copy the flash contents to the RAM, and get on the fly tuning via the
> > second port of the dual port.  I don't know about accessing CPU internal
> > memory, though.
> >
> > --steve
> >
> > > -----Original Message-----
> > > From: gmecm-bounces at diy-efi.org
> > > [mailto:gmecm-bounces at diy-efi.org] On Behalf Of Craig Moates
> > > Sent: Thursday, June 29, 2006 4:29 PM
> > > To: gmecm at diy-efi.org
> > > Subject: Re: RE: [Gmecm] On the fly tuning
> > >
> > > Darren,
> > >
> > > Sounds like some very nice and interesting stuff. I'd love to
> > > open a dialogue and help where I can. I've spent some time
> > > probing many of the edge connections to determine what is
> > > connected where and how they behave on the scope. One of my
> > > present interests is to develop an easy-to-use internal
> > > interface which would use some of the existing edge connector
> > > terminals to access RAM data within the CPU of the PCM. This
> > > could, in practice, allow high-speed data acquisition
> > > separate and apart from the DLC/OBD2 protocols. I'd started
> > > chasing the possibility of having external RAM to shadow the
> > > content in some way if the address or data lines were common
> > > with the Flash bus. However, a serial solution, even if a CPU
> > > code patch had to be applied via BDM, would be ideal I think.
> > >
> > > Best regards,
> > > Craig Moates
> > >
> > >
> > > ----- Original Message -----
> > > From: "Darren Freed" <darrenfreed at shaw.ca>
> > > To: <gmecm at diy-efi.org>
> > > Sent: Wednesday, June 28, 2006 10:03 AM
> > > Subject: Re: RE: [Gmecm] On the fly tuning
> > >
> > >
> > > > Yup - connected it to the edge connector.  I used CS8 for the CE
> > > > signal and CS9 for the OE signal.  Both of these chip selects
> > > aren't used in the stock code.  The SRAM is addressed to
> > > $B0000 and the address lines are connected as in the efi332
> > > project (ie leaving A1 not connected).  It worked well - no
> > > troubles at all.  I just need to work on the PC software now,
> > > to make it more user friendly.  Unfortunately I'm over in the
> > > UK now for a year, away from my ECM bench.  So everything for
> > > the next year will be PC programming stuff.
> > > >
> > > > On another note, I've been looking at the DLC routines
> > > quite abit in a
> > > > variety of V6 and V8 code, from '96 to '04.  It seems
> > > pretty well conserved throughout, which is good news in terms
> > > of developing an interface and programming for datalogging/reflashing.
> > > Although my SCI stuff works well for me, its not particularly
> > > useful to anyone else (I suspect).
> > > >
> > > > Darren
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Steve Ravet <Steve.Ravet at arm.com>
> > > > Date: Wednesday, June 28, 2006 0:06 am
> > > > Subject: RE: [Gmecm] On the fly tuning
> > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: gmecm-bounces at diy-efi.org
> > > > > > [gmecm-bounces at diy-efi.org] On Behalf Of Darren Freed
> > > > > > Sent: Sunday, June 11, 2006 1:12 PM
> > > > > > To: gmecm at diy-efi.org
> > > > > > Subject: [Gmecm] On the fly tuning
> > > > > >
> > > > > > So I'm one step closer to on the fly tuning with a GM
> > > OBDII pcm.
> > > > > > I've added an additional 16k sram and am able to write
> > > to it and
> > > > > > read from it with SCI(ALDL) type comms - ie modify
> > > tables on the
> > > > > > fly.  This is similar to what is done with the
> > > > > > efi332 project.
> > > > >
> > > > > Darren, where (physically) did you connect the SRAM?  To the edge
> > > > > connector?  Did you use an unused chip select output, or did you
> > > > > replacean existing item in the CPU memory space?
> > > > >
> > > > > --steve
> > > > >
> > > > >
> > > > > -- IMPORTANT NOTICE: The contents of this email and any
> > > attachments
> > > > > are confidential and may also be privileged. If you are not the
> > > > > intended recipient, please notify the sender immediately
> > > and do not
> > > > > disclose the contents to any other person, use it for any
> > > purpose,
> > > > > or store or copy the information in any medium.  Thank you.
> > > > >
> > > > > _______________________________________________
> > > > > Gmecm mailing list
> > > > > Gmecm at diy-efi.org
> > > > > http://lists.diy-efi.org/mailman/listinfo/gmecm
> > > > >
> > > >
> > > > _______________________________________________
> > > > Gmecm mailing list
> > > > Gmecm at diy-efi.org
> > > > http://lists.diy-efi.org/mailman/listinfo/gmecm
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Gmecm mailing list
> > > Gmecm at diy-efi.org
> > > http://lists.diy-efi.org/mailman/listinfo/gmecm
> > >
> > _______________________________________________
> > Gmecm mailing list
> > Gmecm at diy-efi.org
> > http://lists.diy-efi.org/mailman/listinfo/gmecm
> >
> >
> >
> > _______________________________________________
> > Gmecm mailing list
> > Gmecm at diy-efi.org
> > http://lists.diy-efi.org/mailman/listinfo/gmecm
> >
> _______________________________________________
> Gmecm mailing list
> Gmecm at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/gmecm
>
>





More information about the Gmecm mailing list