Logging to an SD Card or SPI EEPROM Internally to the ECM

[UCMatt]

It is a shame that we can't access all of that 'spare' space in the Dallas NVRAM conversion....................

[antus]

actually im sure you can. you can map data below 0x8000 by going active when chip enable is low. Simplest would be to hard wire the nvrams CE high, and run the ecus CE line to the high address pin. Would need something extra though to not collide with ram access < 0xFF. Maybe some other kind of logic chip would need to watch for 0x00->0xFF while not CE, and drop the chips CE. Not that I could implement it

[VL400]

I guess the only thing is its not really a huge amount of space, it depends how you arrange the memory but the simplest way would only give 32K of space. With 60 bytes per ALDL message and 10 messages per second it gives just under a minute of logging. Could use it a circular buffer thats always recording giving a one minute history (would have something trigger it to stop recording), factory GM codes does this in a way by taking a snap shot of the current operating conditions when a malfunction occurs, buts its only a single capture of certain parameters.

[antus]

circular buffer would be a good idea.. and need to use a spare input to the ecu to enable/disable logging. Then you could just leave it running and if something glitches you could hit the stop logging button/switch and read the logs up to that point off when you get home. being nvram it would even be stored if you switched the car off. Pretty cool. Since the logged packets have a lot of similarity to each other, it could be possible to pack a lot more data in to that 32k with compression too. But would it be worth the effort? probably not

[UCMatt]

Would not need to log the full 60 bytes. Only the essentials such as MAP, RPM, Wideband, TPS etc

If the 32K presents a limit, how about an SD card on the SPI bus?
There are an umber of HC11 examples on the web for non SDHC cards (<2GB). The required pins are available on the diagnostic edge connector of an 808.
There is a bit of code involved, but it avoids the circular buffer limitations, and the complexity of pageing. If the uploading of logs was done via the ALDL, there would be no need for FAT support, just raw read/write to the card (and another ALDL mode).
As Antus suggested, we could use a spare DI to enable/disable logging.

[VL400]

The SD card idea was something that was thrown around a few months back actually. There is a way to have the ECU spit out a ALDL frame automatically from factory - its how the BCM security request is done - so that parts very easy. There are also some spare mode 1 messages and a few spare DI so thats not a problem either.

[UCMatt]

I was thinking more along the lines of logging hardware within the ECU (either NVRAM or SD card) and a seperate ALDL mode to upload the logged data when convenient.

How about a serial EEPROM on the SPI bus? They are now available up to 1MBit density.
HC11 app note can be found here:- http://ww1.microchip.com/downloads/en/A ... 00646c.pdf
Would have to arrange a chip select, however, I am sure we could find a spare bit of I/O.

It would be nice to be able to log long term without the need for a PC (or any external hardware for that matter).

Just thinking out loud.....

[VL400]

I like your thinking I thought that may have been what you were getting at in your post but was not sure about the ALDL bit.

Its possible yes, but the only issues I could see are time in the ECM and spare pin for the chip select - after clearing out a few things I have a spare 6.25mS, am adding VE learn in there but there will be some free time still. GM use the SPI for a couple of devices in the ECM already so a chip select line for the EEPROM would be required. Thats the one thats going to be more of a problem.

Getting the data out would be easy using a new ALDL mode.

[UCMatt]

Port 25,26 and 27 (pins 5,4 and 3) on the MCU are physically joined together. 1 is configured as an output and the other 2 as inputs (in the $5d code at least), and are part of the limp home function.
As far as I can see, the inputs are not used in the code, and can be configured as outputs. The rest of this port is used for CS for the other SPI devices.
I will have to remove a MCU and see if we can physically seperate these pins.

[VL400]

You can seperate them easily, but need to solder directly to the CPU pin if you wanna use it. Only Bit 0 to 3 are used (IAC pahsing and the two CS pins), cant see a reference to B4 or higher so they should be free to use - other than the limp home connection that has no code reference either.