5l40e

[Bernard Fife]

gurov,

The VSS should be:

CAN ID = 1 (the default, if you have changed this in the settings you need to adjust this to match, of course)
Table = 6 (txbuf) (or 7 for outpc, either should work)
offset = 2 bytes (the values at offsets 0 and 1 are the seconds high and low bytes)

VSS is an 'unsigned int' in the code, so you will want to grab 16 bits, and the value is x10, so you need to divide it by 10 to get the right speed.

However, I believe MS3 has implemented some limiting on what tables it can address, and you might check with the MS3 developers to see if it is allowed to grab table 6 (or 7). Note that CAN can only grab/write table values, and not the code itself (which is not in a table) so limiting the table values to prevent code corruption is not required. For MShift, the tables are:

Code: Select all

  //  RAM copy                    FLASH copy                     Table Size 
  {  NULL,                   (unsigned int *)cltfactor_table,  sizeof(cltfactor_table),    0x3C },
  {  NULL,                   (unsigned int *)sprfactor_table,  sizeof(sprfactor_table),    0x3C },
  {  NULL,                   (unsigned int *)linefactor_table, sizeof(linefactor_table),   0x3C }, 
  {  NULL,                   (unsigned int *)loadfactor_table, sizeof(loadfactor_table),   0x3C }, 
  { (unsigned int *)&inpram, (unsigned int *)&in1flash,        sizeof(inputs1),            0x3C }, 
  { (unsigned int *)&in2ram, (unsigned int *)&in2flash,        sizeof(inputs2),            0x3C },
  { (unsigned int *)&txbuf,   NULL,                            sizeof(txbuf),              0x3C },
  { (unsigned int *)&outpc,   NULL,                            sizeof(outpc),              0x3C },
  {  NULL,                   (unsigned int *)&outmsg,          sizeof(can_outmsg),         0x3C },
  { (unsigned int *)msvar,    NULL,                            sizeof(msvar),              0x3C },  
  {  NULL,                    NULL,                            0,                          0x3C },
  {  NULL,                    NULL,                            0,                          0x3C },
  {  NULL,                    NULL,                            0,                          0x3C },
  {  NULL,                    NULL,                            0,                          0x3C },
  {  NULL,                    NULL,                            0,                          0x3C },
  {  NULL,                   (unsigned int *)&RevNum,          sizeof(RevNum),             0x3C }

cltfactor is table 0, sprfactor is table1, ... , etc.

Also, on a related matter, the spark/fuel adjustments are described in the manual:

Spark/Fuel/Idle Adjustments: The following give the location in MS-II's memory of the fuel, spark and idle adjustments (that are sent from MShiftâ„¢). Normally you won't change these location parameters, unless the code on MS-II is 'non-standard'.

* MS-II in2ram block: The table number (from the tableDescriptor fields) of the MS-II table containing the external adjustment variables from MShiftâ„¢. The default is 5 (which is the 3.430 code's in2ram table).
* MS-II variable offset: The adjustment variables offset on MS-II from the start of the table. The default is 946.

Note that these values are also used in MicroSquirt®, the Sequencer™, etc.

The code will write the adjustments in the table, starting at the offset entered. It will write eight (8) bytes:

* Fuel adjustment - 2 bytes (default is table 5, offset 946 & 947),
* Spark adjustment - 2 bytes (default is table 5, offset 948 & 949),
* IAC adjustment - 2 bytes (default is table 5, offset 950 & 951),
* spare adjustment - 2 bytes (default is table 5, offset 952 & 953) - unused as of the 2.000 code but still must be available in the engine controller code or the value there will be overwritten.

So the controller for the engine must have 8 bytes set aside (in the order above) in the chosen table for it to read and implement these adjustments. All B&G code since 2.901/3.430 has these bytes reserved as in2ram bytes 946 - 953 (you can find these in 'page 2 of the INI). Other codes may or may not have this already implemented - check with your code's developer.

http://www.msgpio.com/manuals/mshift/V2tune.html#oa

Note that it does not matter if these values get written to flash by an inopportune 'burn', because:
- they are only accessed from RAM,
- the 'accidentally saved' value will be copied from flash to RAM on start up (and only on start-up), BUT
- the RAM Fuel, Spark, and Idle adjustment values are immediately cleared on start-up by MS-II, and every time through the MShift main loop if the operating conditions require it.

So there's no chance the adjustment value will end up being used indefinitely even if it is written to flash memory.

Lance.

[gurov]

gurov,

Attached is the 2006b S19 file that has the shift blocking in place.

Monitor_2006b.abs.s19

It won't let you shift again until you have released both shift buttons for 1/4 of the user-set 'shift button duration'. I have tested it quickly on the bench with both shift button polarities, and it appears to work as expected. It uses the same INI. Let me know if you see anything strange.

Lance.

works exactly as expected.

there is some weirdness with shift wait time below 20, where it goes back into auto mode instantly, but i don't think i'd want to set my wait time to something that low.

thank you for such quick turnaround time.

[Bernard Fife]

gurov,

Yes, very short shift duration times will cause problems. That part of code is essentially a 'software debounce' and if it gets to short the 'switch bounce effect' can cause all sorts of interesting behaviour. I will set the minimum duration to 25 in the INI (this is 25 samples at ~5kHz, so about 5 millisecond!).

Thank *you* for your clear and concise feedback - it makes it better for everyone!

Lance.

[gurov]

so i'm hitting some very strange behavior.

it seems that after burning a few things with tunerstudio, the entire flash is blanked until i reflash it, and reload the msq. at which point there's a much higher chance of hitting the same condition.

i'm still trying to find the pattern to this, but when this does happen, every single high current fet is pulsed, the LED drivers are all on.

[gurov]

well, seems as if i've lost the abiltiy to write things to flash with any kind of confidence. on power cycle, settings revert back to what they were from the flash, OR they get corrupted beyond all recognition, and all get set to 1... so the shift tables look to be 255 all across the board, all the 16 and 8 bit settings are at max values.

and this isn't software-related or serial-adapter, or computer it's talking to. tried TS e and g, linux/windows, two different serial adapters that worked great before.

[Bernard Fife]

gurov,

I will have a look at this shortly. Are you connecting directly, or using the CAN pass-through? Is your power supply known to be good?

Lance.

[Bernard Fife]

gurov,

Something is definitely wrong. I will look at this right away, and post results here (I suspect I have messed up the INI to memory footprint relationship). In the meantime, you should revert to older code.

Lance.

[gurov]

gurov,

Something is definitely wrong. I will look at this right away, and post results here (I suspect I have messed up the INI to memory footprint relationship). In the meantime, you should revert to older code.

Lance.

power supply is a PC silverbox, ms3 hooked up to it reads 10.7 volts(i did not check the 5v regulator though) , but this has never EVER been an issue before this on numerous ms1/ms2/ms3 boxes and this GPIO board. not sure what voltage gpio is seeing as there's not a voltage indicator like there is on the MS boxes.

i'm not sure if it is the INI, because when it freaks out it overwrites every bit with 1's, and same happens with 2.005

i am using straight serial to the gpio box.

i tried this in 2.005, and got the same issue where i change something, say in the target gear map, top left 3x3 block is set to 3, from 1, click burn, everything appears fine. close tunerstudio, open it up again, target map is still fine. powercycle the gpio, the top, left 3x3 block reverts back to 1's.

or if i was to power cycle the gpio box with TS shut down, and open TS again, it would give me a difference report saying that the target map has changed.

this is the same case with any variable. at one point i DID get it to work right by doing a full tune load, but on the next power cycle it overwrote all bits with 1.

i had to shave 0.5mm of the board's edge to get the case ends to go on right. this was done with a bench wheel grinder.

i'm going to guess that you can't reproduce this on the bench ?

[Bernard Fife]

gurov,

I am seeing some corruption, like you. Which end did you shave? I will see if that might cause any issues (iI doubt it though).

Try the attached code and INI (2.006c):

Monitor_2006c.abs.s19

GPIO_MShift_2006c.ini

It has some improvements that might help (they do here).

One thing that does corrupt code is shutting TS down quickly after changing values. That's because the flash has to be erased before it is written, and this takes a while. If it is interrupted, you get a 1 in every bit, and as a result all the values not yet written are maxed out.

You can't rely on the 'burned all data' notice in TS - this only means that TS has sent the data and burn instruction to MShift, but not necessarily that MShift has completed the burn process.

So try waiting 4 or 5 seconds after a burn and see if that helps.

I will keep testing here.

Lance.

[gurov]

gurov,

I am seeing some corruption, like you. Which end did you shave? I will see if that might cause any issues (iI doubt it though).

Try the attached code and INI (2.006c):

Monitor_2006c.abs.s19

GPIO_MShift_2006c.ini

It has some improvements that might help (they do here).

One thing that does corrupt code is shutting TS down quickly after changing values. That's because the flash has to be erased before it is written, and this takes a while. If it is interrupted, you get a 1 in every bit, and as a result all the values not yet written are maxed out.

You can't rely on the 'burned all data' notice in TS - this only means that TS has sent the data and burn instruction to MShift, but not necessarily that MShift has completed the burn process.

So try waiting 4 or 5 seconds after a burn and see if that helps.

I will keep testing here.

Lance.

i shaved the end the processor is on (the board is too long for the case to fit, probably due to the ampseal) it didn't nick any visible traces, but i do not know about the inner 2 layers.

which causes the corruption, shutting TS down or shutting GPIO down ?

is there any indication coming from mshift that the values have been burnt to flash ? could what i'm seeing be related to a hardware failure in the processor ?
i.e. should i order a new board set to swap all my circuitry onto, or is there a chance that this is firmware-related and software related to writing the flash ?