CA18DET + Type 1 board => knock maps

Discuss software bugs and related problems here.

Moderator: Matt

ByReaL
 

Posts: 127
Joined: Fri Mar 23, 2007 11:46 pm
Location: Romania / SUA
Contact:

Post by ByReaL »

any news on this?
* Got CA18DET Love
Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Post by Matt »

sorry been on vacation for the last two weeks.

Flying back (today) and have several things to go through... tonn of emails, problem with the Type 4 boards and getting Type 5 ready for prototyping I can continue to look at the knock sensing enhancement
ByReaL
 

Posts: 127
Joined: Fri Mar 23, 2007 11:46 pm
Location: Romania / SUA
Contact:

Post by ByReaL »

sorry to be so annoying about that but is there any news?
* Got CA18DET Love
GZ@hybridka
 

Posts: 112
Joined: Wed May 03, 2006 5:51 pm
Location: Id, USA

Post by GZ@hybridka »

I did some work on the CA18 timing map routine and fixed it up a bit. I dont know if Matt got it, but ill post the details here. Do you have the cability to reprogram your own type 1 board or is that something Matt has to do?
Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Post by Matt »

Unfortunately its something I have to do... because the board has no internal microcontroller it is only programmable off ECU. Which requires the programmer board we have developed
ByReaL
 

Posts: 127
Joined: Fri Mar 23, 2007 11:46 pm
Location: Romania / SUA
Contact:

Post by ByReaL »

Matt wrote:......... Which requires the programmer board we have developed
i remember it was somewhere over here a "how to" for the ones that had a Wilhelm/Willem programmer, or we are not talking about uploading a bin file into the SRAM memory ?
* Got CA18DET Love
Vetal
 

Posts: 128
Joined: Tue Jun 26, 2007 10:39 pm

Post by Vetal »

Is it the same issue I have?
OK, after 10+ hours spent doing runs and analysing logs, I can confirm that:
a) knock ignition map changes don't affect torque/power
b) reported igniton is affected by knock map; changing main map doesn't influence reported timing
viewtopic.php?t=326&postdays=0&postorder=asc&start=15
Vetal
 

Posts: 128
Joined: Tue Jun 26, 2007 10:39 pm

Post by Vetal »

although ByReal says he's ECU is using Knock timing map, while my is using Normal map but reporting from Knock map
Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Post by Matt »

ByReal - The howto documents are for the older Type 1 - Rev1/2 boards which used external NVsRAM chips which could autostore their data when an external capacitor was hooked up.

Doesn't apply to newer boards... The newer Rev3/3A boards use a different NVSRAM chip which requires a specific set of reads to save new ROM data to the board. This requires the NIStune programmer since the willem programmer could not drive the /CE (driven by the parralel port) line steady without ringing... stopping the STORE from working


Vetal - From what I read about ByReals issue with timing is that the ECU was running from the primary timing map. But the consult ignition timing value displayed was from the knock timing map. I will have to see if there is another way to get the correct timing value out of the ECU... if that is possible. I dont know why it reads the knock timing value into the various memory addresses the ECU uses

His ECU is effectively the same as your ECU. The timing value in NIStune is repored coming from the wrong map. Also you will have to ignore the 'pink' highlighted map for now on CA18 until knock detection is worked out. Might disable it for CA18 in the interim until that is sotred.

I've got some more time now so should be able to investigate it next week. Keep bugging me if I dont get to it... its definately in the list
GZ@hybridka
 

Posts: 112
Joined: Wed May 03, 2006 5:51 pm
Location: Id, USA

Post by GZ@hybridka »

I wrote a patch to fix this so that the ecu will only use a single 16x16 table at a time, outputting the value to both actual timing advance and consult.

But of course, it is not something that can be done without reprogramming the nistune board, and would need to be done to each code version seperately.

I could probably write an autopatcher software to do the code modifications, but it would be up to Matt whether or not he wanted to do it this way at this point in time.

Just out of curiosity Matt, are your safety limitations on NVSAM write locations done in the firmware or software? If the firmware allowed writes to any or most locations, perhaps with some custom software the code could be patched using USB consult and not requiring a full reprogramming? Just trying to think of ways these little quirks could be ironed out without having to send boards back and forth all of the time, and without exposing firmware of course.

I can see something like this being a bit problematic during major code restructuring though, if your USB consult required the ecu code to be running (im not sure). Some extra steps might be required to ensure the block of code is not being used when update is taking place. If the block is a subroutine, the first byte written could be a RTS, or even a jump to RESET (though that would be a couple bytes), then pasted over with the actual first byte of the code routine, once the majority of the routine has been patched? Involved?, yes :? Im rambling.
Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Post by Matt »

Gabe if you can send the BIN through to me I can have a look at the modifications and see if I can autopatch it here (just amend my existing autopatcher)

Safety limitations are done in firmware loaded in the ECU. The ECU has a preprogrammed range for each ECU type which is allowable for read/write access (for RAM reads and limited ROM access area)

The safety mechanism on the NVsRAM is that no changes are permanently saved until the STORE sequence (via burn button) is performed. Just in case it ever got corrupted, just power off the ECU and all is well again

I would love to perform onboard firmware updates, but it is very difficult. You cannot update firmware or other ECU ROM code whilst it is running.

Just thinking about it.... the only way I could self-upgrade the firmware is to add an additional instruction for firmware update, upload the firmware to a second memory location, then execute from that second memory location to perform the copy accross to the original location and then perform a STORE to save the changes

However major code restructuring is fraught with danger because if the interrupt handler doesnt get executed due to code error then there is no possibility of recovering. But then I guess you can cut the power and restart since it never got performed the STORE
GZ@hybridka
 

Posts: 112
Joined: Wed May 03, 2006 5:51 pm
Location: Id, USA

Post by GZ@hybridka »

Ill set the patch up for a little bit more simple operation (right now its 32x16 function using both ignition tables, one at a time, switching as a function of TP) and send you the details and .bin here tonight.
Vetal
 

Posts: 128
Joined: Tue Jun 26, 2007 10:39 pm

Post by Vetal »

I can't say I've understood a lot about upgrades/firmwares/... :roll:
So did you find the reason why with CA18 it behaves like that?
Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Post by Matt »

I spent some time last week looking through the CA18 code

I worked out the following ... because I want to get away with displaying a timing value without modifying the Nissan code
10394 CA18 Ignition timing table investigation
HIGH_TIMING = DIFF_TIMING 0x10C2 (0x103D) + REG_TIMING (0x110D)
The diff timing = high_timing - reg_timing... so to get high timing just reverse the equation

Thats the theory but I will need to monitor on the bench tomorrow night in practice and see if it matches what I see

You can also do this yourself using Display - Consult RAM trace and monitoring around those addresses in decimal. You will need to minus the value by 16 (being the consult timing offset)

Best way to check the ECU / real value is with a timing light and changing engine revs just above idle and seeing the real timing value. I cant do any of that kind of checking here to see what real timing values are. Only by looking at the code which I am doing now
Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Post by Matt »

Okay this required some playing around on the bench.

I've got the scope hooked up to show injector 1 and coil 1

Modifying the timing map when TPS = OFF will result in coil movement on the scope

Modfying the idle speed timing when TPS = ON will also result in coil movement

Vetal has pointed out that when temperature is ~65C that the timing doesnt function as expected. I also noticed this sometimes when TPS was disconnected. Both maps when having timing altered on the maps do not change the advance/retard of timing on the scope. Dont know the reason for this. Something the ECU is doing strange


Now in regards to the timing values. The timing map currently displays just the 'knock' map timing values. However the regular map is actually referenced by the ECU during normal operation

I have noted the following:
10C2 - Timing value from primary map (minus knock map value)
110D - Timing value from knock map (currently displayed)
110B - Timing value from idle/decel timing table
1116 - This is affected by Idle and knock map modificaitons (but not main map)

1010 copied to 100F is the timing value which appears to be actually used by the ECU
Looking at the value, it seems similar to later model ECUs

Timing = (Value at 100F) - 110

But it seems a little off, about 8 degrees on the ignition timing map (if everything set to same value) and 4 degrees on idle/decel map

So what I've done

Changed timing value to use this address in firmware
ADR $100F ; IGN TIMING

Updated address file to reflect timing map value
CONSULT_TIMING_OFFSET=4

Now I see the 'knock' table being accessed in hardware trace but no effect at all on final timing. Next experiment is to put a knock signal into the ECU and watch the timing on that.

I'll post some pics of the scope up next time too, since some of you might be interested to see the pulses coming out of the ECU driving the injectors and coils


What this will mean for those who want this fixed in your board... I'll have to update the firmware. I dont have any exchange over boards here at the moment, so if you wanted to post your board here I can update it
Post Reply