MicroSquirt.com read only forum (Jan.15,2018)

Having problems with tach resets on my wasted spark setup. CPU does not reset. It only happens when the Tuner Studio is running. If the ECU is connected to the computer but TS is not running, no problems.

I have tried a laptop with a USB serial port, a laptop with a real com port and a PC with a real com port. The laptops have been tested with and without mains supply. All exhibit the same problem.

The TS version is 1.004 on the laptops and a little older on the PC.
You will see from the log file that time continues to count so the CPU does not rest and that between the resets the tach count increments quite reliably.

Ideas anyone?

Forgot to mention, have tried 3 Microsquirt boxes too.

Are you controlling ignition or is your project fuel-only? (I didn't look at your msq). Of course, I see that you posted this thread under the "Ignition Setup, Tuning, and Troubleshooting" which suggests that you're controlling ignition. But here's my story anyway, just in case it helps.

I had a similar sounding situation with my project (Kawasaki EX-250 motorcycle, fuel-only), tons of resets when I had the computer connected using either Megatune or TunerStudio.

In the end it turned out to have nothing to do with the computer or the serial cable or the usb adaptor for the cable.

My project is fuel-only so I had to get the tach signal to the Microsquirt by sensing directly off one of the bike's coils (couldn't use the bike's VR signal off the rotor because it's an odd configuration not supported in Mega/microsquirt). I was trying all kinds of configurations of the coil-sensing-to-OPTO circuit setup while also having all sorts of difficulty with resets just like you describe. So I was also changing computers, serial cables, and usb adaptors. It was a big mess.

When I finally found the right way to feed the bike's coil signal into the Microsquirt's OPTO circuit all the computer problems went away.

Yes, fuel and ignition are being controlled and since we have no distributor the VR is our only option. I suspect a firmware problem as the tach is very stable until the reset occurs, as can be seen in the log file. Unfortunately we have no internet access at the workshop so I couldn't try any earlier code versions. We have scoped the power lines, Vref and the output of the VR sensor and all look clean. We ran up the Tachref program too so we can see it as the cpu sees it and it's all quite stable and the gap/teeth are well defined.

Just a point to be clear on, it's not when the computer is connected, tha's fine. Only get resets when it's connected and TS is running which is just weird as it's kind of like the comms overhead is more than the system can handle it it somehow loses sysnc, although the logs don't seem to show that happening.

Only get resets when it's connected and TS is running which is just weird as it's kind of like the comms overhead is more than the system can handle it it somehow loses sysnc, although the logs don't seem to show that happening.

Yes, that's how my microsquirt used to behave. I even had that same thought, that it was something to do with the ability of the computer or it's input-output capabilities (what you describe as "comms overhead"), but in the end that wasn't the issue at all. I was just suggesting that you continue to focus your work/experimentation on whatever signal you're using as tach-input to the microsquirt's OPTO/VR circuit. I believe there's a good chance you could solve it there.

I'm not convinced it's actually a problem with the VR signal because the trigger +/-, DeltaT and sync status all say that everything is fine. Right up to the point the tach reset occurs the sync status is 3, the Triggers +- is 0 and everything is working OK. If the problem was with the VR pickup I would expect to see missed triggers count from 1 to 2 then the sync status to drop, followed by tach reset. That does not happen which suggests that the ECU either did not see a problem and what happened was an untrapped error in the firmware. Maybe I'm thinking too deeply but I would expect that the datalog should show one of the classic symptoms of missed synch before the ECU resorts to a tach reset.

We do have theoretical option of fitting a distributor to the engine and using the opto inputs as it has a blanked hole for one but that requires some re-engineering as the distributor will foul the intercooler. Actually it's rather worse than that as we have two identical cars fully built and we will have to do this on both. I want to persevere with the VR method but with 2 cars, 3 ecus, 2 laptops and a PC all doing the same thing I'm worried that I'm trying to solve a problem that can't be solved by me, ie a bug.

jon,

It sounds to me like it may be the flash burns from TunerStudio causing issues with the timing of the incoming teeth. Flash burns take some time (much longer than changes to RAM). The code has to be sure a tooth (or two) wasn't missed in that time.

In that case, a reset is a good thing. The controller sees there has been a burn, and if there is any chance a tooth was missed, it resets and all is well again.

It would be a problem if a tooth was missed and the reset didn't happen - the timing would be messed up.

So it sounds like yours is working as it should.

However, TunerStudio burns flash on a page or menu change. That can happen a lot as you move between menu and items while tuning. You can turn off this 'auto-burn' behavior. I always shut it off. You can do this by editing the file C:\Program Files\EFIAnalytics\TunerStudioMS\TunerStudio.properties.

Set:
autoBurnOnCloseDialog=false, and
autoBurnOnPageChange=false

You have to remember to manually burn things then, of course.

BTW, I am running 2.905 and have no tach reset issues (but I have the auto-burn turned off, as noted above).

Lance.

Thanks Lance

I will give that a try but I'm fairly sure the resets occur even when TS is running but idle, ie just on the gauge screen and with AMC updates and VE analyze disabled. I could be mistaken though, yesterday was a long day. Will update with more information later in the week.

I tested your msq on the bench, letting it run for about an hour at 3200 rpm, and no resets. In looking at your datalog, I'm not sure what is going on, there is certainly a resync because there is a reset - only place tachCount gets cleared. There are many places where reset can be called besides missing/ extra teeth, for example if rpm drops too low (stall), but none fit in with what you are seeing with the settings you are using. I agree VR problems don't appear to be obvious. Only on the first reset is there a count up for trigger+/- and that could be a result rather than a cause of the reset. For example you can pull out the VR wire and the trigger may count as the engine drops speed. There is a large gap between lost and resync, about .3 secs. I suspect there is a loss of comms here, but you are running 2-3000 rpm, there is no way the processor can be overloaded - I just finished testing newer, more complex code, with a 36-tooth wheel at 16K rpm with no resets and with TS running. The comms have a lower priority, but they will still slow things down, but 3000 rpm is way too low to be causing problems.

One thing to make sure of, as Lance said, is that what is in the processor matches your msq. Check this by saving your current msq and file comparing it to the one you posted.

Today we reburned 2.905 and installed the ini file again and checked it was selected in the project settings. Upgraded to TS version 1.10 and tested again. No change. We then confirmed the comms ground and tech grounds were on the correct pins on the bought in connector and they are also OK. We repositioned the VR as it was a couple of mm off center and this also didn't help. We then upgraded to V3.76 and roughly configured the settings to get the engine runable. Same result, as soon as we start tuner studio running we get tach resets randomly every few seconds accompanied by a wall of flame from the tail pipe. It makes no difference if we are actually doing anything in TS and the changes in the TS profile also had no effect on the problem.

We have added suppressors to the wasted spark coils and removed the comms lead from the loom so it's well away from the injector and ignition wires.

Any more thoughts on this before I stick in a distributor and go optical or hall?

I ran a comms log and it showed a few "waiting for and expecting xx" messages like it was having comms errors but will a comms error cause a tach rest? I can imagine a cpu rest causing a comms error but no sign of cpu resets happening.