v2.883i - 2nd bug fix

Forum for discussing how to install MicroSquirt(TM), choose and troubleshoot sensors, wiring, and communications for MicroSquirt (TM) and MicroSquirt Module(TM).
Forum rules
Read the manual to see if your question is answered there before posting. If you have questions about MS1/Extra or MS2/Extra or other non-B&G code configuration or tuning, please post them at http://www.msextra.com The full forum rules are here: Forum Rules, be sure to read them all regularly.
Post Reply
grippo
MegaSquirt Guru
Posts: 921
Joined: Mon Feb 16, 2004 6:55 pm

v2.883i - 2nd bug fix

Post by grippo »

We have recently helped several people in getting microsquirt running with several dual spark mode configurations. In the course of doing this it was found that ignition outputs were occasionally missed or had longer dwells - later timing than they were supposed to. This only happened at low rpms - below about 250 rpm. This code version fixed these problems, so I am putting it out to replace the existing 2.833b version. There were no changes in features, so existing 2.883 inis and msqs will work fine.
Attachments
main_v2.883i.zip
(76.52 KiB) Downloaded 54 times
Monitor_v2.883i.abs.zip
(37.33 KiB) Downloaded 54 times
Bernard Fife
Super Squirter
Posts: 1009
Joined: Mon Feb 16, 2004 3:15 pm

Post by Bernard Fife »

Al,

These are also posted on the code page (http://www.megamanual.com/ms2/code.htm).

Lance.
MoveX
MegaSquirt Newbie
Posts: 8
Joined: Thu Jul 21, 2005 9:45 am
Location: Munich, Germany

Post by MoveX »

Hi Al,

I think t_chgoff could be the reason for missed sparksat 2.883b code. The 300ms are one crank rotation at 198 rpm and that's the timeout for every spark channel.


Karl
grippo
MegaSquirt Guru
Posts: 921
Joined: Mon Feb 16, 2004 6:55 pm

Post by grippo »

That is an interesting coincidence, but if the 300 ms condition is met, the logic should force a spark, not prevent it, and if the condition was not met, then that is good because you would never want a 300 ms dwell. But it might apply to the second problem which also sometimes occurred, where I would set the output compare to start the dwell, bu the dwell never happened. However I looked at the logic for t_chgoff and it should only be set to non-infinity value at the time the dwell is actually turned on. But it is true the problems occurred only within a narrow rpm range from about 180 to 195 rpm, which unfortunately is a common cranking rpm range. I tried dumping delta times everywhere the registers were set, and everything looked perfect, but occasionally in this rpm range either no spark or extended dwell. The only assumption I made was that the processor was following the C instructions, but with CodeWarrior who knows. So rather than dig into the assembler, I constructed a watchdog from the .128 ms timer since this is more than enough accuracy below cranking rpm - like less than 0.1 deg.

I would like to find the cause of the problem, and I will keep the tchgoff coincidence in mind, but I think at some point I may convert the code to vsn 4.5 and see if the problem is still there without the watchdog.
Post Reply