[rusEfi] Miata NA 1990, 1.6L stock #21

What engine are you torturing? Is it inside some car?
tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Mon Jan 02, 2017 6:28 am

As next step of endurance testing can we try adding

set_int 2472 100
writeconfig
set_int 2472 101
writeconfig
set_int 2472 102
writeconfig
I'll try to get it going. And I agree with @kb1gtt that doing incremental sweep would better than random timing.
Right now the power on/off setup is very dumb. I'll try adding sending commands with the power controls.

You know I'm pretty sure I was not running TS autotune when this problem occurred to lose the config settings. But I have turned off the switch with autotune running on other occasions. Did you say that could cause corruption of data? Seems like that is a problem that should be addressed since it could happen by accident or maybe some other failure.

User avatar
kb1gtt
contributor
contributor
Posts: 3489
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by kb1gtt » Mon Jan 02, 2017 7:49 am

@russian can correct me if I'm wrong. This is my understanding. If TS is doing a write operation, the memory block takes a certain amount of time to write. I seem to recall that the OS's write process first clears a chunk of memory, then writes that chunk of memory. If you kill power after it has cleared the memory and while it is writing, the data being written will be corrupted. As well if you kill power while writing, and if you do not have proper brownout protection, it's possible that you could not have enough voltage to reliably write a 1 or a 0. So it's possible that it could be worse than simply only having a loss of data. It's possible that you could have corrupted 1's and 0's. I understand that to ensure data integrity, there is a check sum done on the memory when it boots as well this check sum is periodically triggered by events like a TS write cycle to ensure the data was accurately written. When you boot up, part of the initialization procedure is to do a quick check sum on this memory which ensures that the data is valid. If that check sum is OK, then everything boots as you normally see. However if that check sum fails, then a routine is called which copies a default chunk of memory to the working memory, and then continues to boot up. As well some error flags are set, such that we can trigger warnings, logging data, etc.

Priorities have been to get it working, then add usability features like error protections and make the code more rugged, add more features etc. So while we know that things like brown out protections exist, so far we have relied on ChibiOS to magically deal with them. Now that the core features are working reasonably well, we are starting to look closer at these area's where we have relied on the OS to do some magic. If it's not proper then we'll start to figure out how to make it better. Right now I know the STM32 chip has 4 layers of brown out protection, each set at different voltages, with layer 4 being the most protective, and layer 1 being the most likely to allow a failure. As well you can technically turn off this protection altogether and you can have external circuits that do this rest operation. We are not considering the external option and we will have some kind of internal protection. As well it appears that the OS default is to use level 1. I think we should consider level 2 protection. If we go to say level 4, I fear we would trip nuisance trips, and we don't want to reset to often. We want to ensure data integrity. I'm currently learning what the variations in data integrity are between level 1 and level 2. I'm not sure there is a significant difference, but there might be some additional integrity features in level 2. I'm still learning. Also it's good to know that we have some layer of brown out protection, so the possibilities of 0's and 1's being wrong is minimal. However we might be able to further decrease the chances of these kinds of corruptions.

On a good note, I understand these data integrity checks are commonly not done on other platforms. It appears there are many possible data integrity issues, that they don't identify, and it would still try to operate with invalid data. In our case we have put up a safety net to catch potential bugs, which has apparently worked. As well I'm quite certain that the problem you had was not a brown out issue. Right now it appears your corrupted memory was a failed write operation, but there is some possibility that some other bit of code has also written to this area an corrupted it. The power killing sweep testing will hopefully identify when and how it failed, then we can start to figure out what is doing it. Once we can get the problem re-produce-able, we'll be able to start back tracking and finding out what the source is.

One item that @russian is looking into as a usability features, is once you have a known good default chunk of memory, how to write that into the default memory. Such that if the operating memory is ever corrupted for any reason, your default values are at least in limp home mode.

Also it's good that you ping us from time to time. It's easy for us to get distracted with other things. Often we simply decide on something for the sake of making a decision and getting something done. If you ping us about these kinds of things it will help us prioritize the problems you are seeing, vs the problems we are working on.
Welcome to the friendlier side of internet crazy :)

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Mon Jan 02, 2017 10:25 am

tomiata wrote:You know I'm pretty sure I was not running TS autotune when this problem occurred to lose the config settings.
Yes, right. We are mostly "looking under the lamppost" here - power off while flash right should be a failure scenario (probably a different one from what you have experienced) but that one we at least have a theory and a higher chance to reproduce.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Tue Jan 03, 2017 2:17 pm

russian wrote:As next step of endurance testing can we try adding

set_int 2472 100
writeconfig
set_int 2472 101
writeconfig
set_int 2472 102
writeconfig

And adding power off with a random delay after writeconfig?
My set up can now turn on the board for a specific length of time in milliseconds via serial connection to an arduino, and I wrote a python script that can sweep the time over a range of values. To send these commands after power on, I would need to send them to a different serial connection to rusefi. Can the console usb connection be switched to a mode that I can send the commands with a script?

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Tue Jan 03, 2017 5:53 pm

tomiata wrote:Can the console usb connection be switched to a mode that I can send the commands with a script?
Not sure I understand the question.

You do not need rusEfi dev console to send commands - same way as you read bytes from the stream to validate MIATA can you send the commands? Some command on top has turned console into plain text protocol so same as plan read you have plain write.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Wed Jan 04, 2017 4:53 am

I used dev console to disable binary_mode_console. And I'm using linux and python to drive the test.
And to test out the setup I power up the board with PB1 pin grounded and connect the FTDI USB port to a dumb terminal program and see output like this:

Code: Select all

                                     
Idle Valve on PB:9                                                              
line:22:msg,Idle Valve on PB9,                                                  
Emulating MIATA_NA_1_6                                                          
distributor ch1 on PD:1                                                         
line:27:msg,distributor ch1 on PD1,                                             
distributor ch2 on PD:2                                                         
line:27:msg,distributor ch2 on PD2,                                             
communication status 1 on PD:15                                                 
line:35:msg,communication status 1 on PD15,                                     
warning on PD:13                                                                
line:20:msg,warning on PD13,                                                    
is running status on PD:12                                                      
line:30:msg,is running status on PD12,                                          
Running main loop        
Are you saying I should be able to type on the dumb terminal to this serial connection to send console commands? Should I see any output from running a command? I tried it on windows with teraterm and see some garbage characters come out when I type on the console. I'm not sure what to expect.

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Wed Jan 04, 2017 8:17 am

Yep, you should be able to type commands right into this terminal connection.

fl 0 would disbale/reduce status messages

Some commands like set_int X Y would not produce output but some commands like get_int OFFSET would print out something
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Wed Jan 04, 2017 6:46 pm

russian wrote:Yep, you should be able to type commands right into this terminal connection.
Hmmm, I tried a few commands like sdinfo, writeconfig, fl 0, fl 1, but didn't see any output. I'll try again tonight.

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Wed Jan 04, 2017 9:21 pm

1) connect with console
2) disable binary_mode_console
3) writeconfig
4) disconnect from console, reset MCU
5) connect with terminal
6) get_gloat 12
7) fl 0

works for me via miscoUSB and does NOT work for me via miniUSB - looks like while both ports are now binary by default, only one of them goes into text mode with "disable binary_mode_console" setting. See https://sourceforge.net/p/rusefi/tickets/333/
Attachments
screenshot.png
screenshot.png (91.69 KiB) Viewed 2854 times
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Wed Jan 04, 2017 11:01 pm

tomiata wrote:PB1 pin grounded and connect the FTDI USB port to a dumb terminal program and see output like this
Hold on, looks like PB1 is still important.

Both ports could work in binary but only one can work in text mode - and which one is depends on if PB1 is low or high. Would it work the way you need it without grounding PB1? You only need one port to be in text mode, you do not need both ports in text mode? The issue right now is which port has text console?
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Thu Jan 05, 2017 2:59 am

The micro usb is a pain to use with linux. If the device is open, on reset the device name changes from /dev/ttyACM0 to /dev/ttyACM1, and changes back if you reset again. The test script could work with that but would be messy. How hard is it to change to support text console on the mini usb port?

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Thu Jan 05, 2017 8:42 am

russian wrote: Hold on, looks like PB1 is still important.
With PB1 grounded on firmware start I have text command line terminal on miniUSB port.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
kb1gtt
contributor
contributor
Posts: 3489
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by kb1gtt » Thu Jan 05, 2017 11:02 am

Do I understand correctly that your Linux python script is what is commanding to kill power? If so you could potentially kill power, then close the serial port, then re-open the serial port. I believe the issue you are having is that python script is keeping that port active, and when you power cycle the Frankenso, you are forcing Linux to disconnect and re-connect the USB port. When the USB comes back, the python script still has that device active, Linux then chooses the next available device. If the python script were to disconnect, then the ttyACM0 would probably become available. I'm assuming your using py.serial, which uses something like this.

Code: Select all

serialport= serial.Serial ("ser = serial.Serial('/dev/ttyACM0', 9600)
If so, you can close the port with this

Code: Select all

ser.close() 
As well it's usually good to capture open failures with something similar this

Code: Select all

ser = serial.Serial(/dev/ttyACM0', 9600, timeout=1)
if(ser.isOpen() == False):
    ser.open()
That last bit of code would continue to attempt an open until it was successful, then it would continue with the rest of the program once it was operational.
Welcome to the friendlier side of internet crazy :)

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Fri Jan 06, 2017 5:24 am

It might work to close the serial connection to avoid the linux device driver weirdness, but it needs to be 100% reliable for this test. And I'm guessing that the problem is because of the port being open when the USB device resets. I suspect there are other problems. I always restart the java dev console to make it work after a power cycle to work around it.

And there are mysteries around USB serial reliability that I have not seen explained.
See: http://rusefi.com/forum/viewtopic.php?f ... 252#p19252

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Fri Jan 06, 2017 10:20 am

I agree that native USB with it's drivers complexity is not the bext option for the test planned, do you have any luck with text protocol over TTL poer at in http://rusefi.com/forum/viewtopic.php?f ... 300#p21998 ?
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Sat Jan 07, 2017 6:22 pm

russian wrote:I agree that native USB with it's drivers complexity is not the bext option for the test planned, do you have any luck with text protocol over TTL poer at in http://rusefi.com/forum/viewtopic.php?f ... 300#p21998 ?
Sorry missed your earlier question. After updating to current firmware, with PB1 grounded text console on miniusb works. Updating firmware broke my config with an error "PB6 req by GPS tx ...", and I wiped the config to get it going again.

I'll start a new thread about testing on the software section.

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Sat Jan 07, 2017 8:14 pm

Sorry for the incopabible logic change - I've removed a layer of complexity so that having a pin set means you want to use it. Previously there was a set of boolean 'enable'/'disable' optiobs which were cluttering things a bit.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Mon Jan 09, 2017 1:38 am

Can we compare our boards in terms of jumper wire setup?

On mine the blue wire is MAP - http://rusefi.com/images/Frankenso/fran ... p_wire.jpg
and AFR is a jumper in W48

See also http://rusefi.com/wiki/index.php?title= ... Miata_1991

@ is now helping to set another NA6 car here in NJ.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Wed Jan 11, 2017 3:09 am

I documented most of what I did on this page:
http://rusefi.com/wiki/index.php?title= ... Miata_1990

Sorry, it's not up-to-date, and I didn't wire it very cleanly doing a little at a time. I'll try to update it to what I have.

My MAP is W46 Inp10 PA6.

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Thu Jan 26, 2017 1:49 am

tomiata wrote:I documented most of what I did on this page:
http://rusefi.com/wiki/index.php?title= ... Miata_1990
The writing setup I used is up to date on the wiki now, sorry I forgot to mentioned that before.

stefanst
contributor
contributor
Posts: 579
Joined: Wed Feb 17, 2016 12:24 am

Re: Miata NA 1990, 1.6L stock #21

Post by stefanst » Tue Jan 31, 2017 1:44 am

Could you please post your latest working tune? I need to copy parts of it. Thanks!

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Fri Feb 03, 2017 4:18 am

stefanst wrote:Could you please post your latest working tune? I need to copy parts of it. Thanks!
Sorry for the slow response, been busy with life etc.

I just got the car going again after the out-of-car-body experience with reliability testing. Attached is current tune, and I have a few problems to ask about.

1. I'm still running on firmware dated 12/2/16. How do I work around the problem I see with recent firmware: Updating firmware broke my config with an error "PB6 req by GPS tx ..."

2. SD logs files?? Running with a Rev D. discovery board on my Frankenso would not create SD log files. Any ideas on that? Attached console log from yesterday when I tried it. Today it worked fine when I switched back to my original Rev. C discovery board.

3. I think I resolved my timing problems. I verified TDC timing marks by inserting a rod into the cylinder 1 spark plug hole and rotate the crankshaft as stefanst suggested. Adjusted timing with CAS and verified it ran fine with stock ECU. Setting global timing offset to 18 degrees looks about right now. How does that compare with @russian's hunchback miata 1.6?

Btw, verifying the TDC position was a challenge because of a spark plug stuck in cylinder 1, was stripped smooth and 3 sparkplug sockets I tried would not grip it. The sockets were too thick to fit around the plug way down inside the head. I had to grind off the end and sides of a socket to grip it and pull it out. Thankfully, I figured that out before resorting to more drastic measures to break the plug and use a bolt extractor.
IMG_20170202_220005~2.jpg
IMG_20170202_220005~2.jpg (156.13 KiB) Viewed 2693 times
Attachments
MAIN_rfi_report_2017-02-01_22_41_03.csv
(971.28 KiB) Downloaded 396 times
CurrentTune.msq
(134.23 KiB) Downloaded 135 times

User avatar
kb1gtt
contributor
contributor
Posts: 3489
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by kb1gtt » Fri Feb 03, 2017 10:31 am

Some suggestions for plugs.

Use anti-seize grey goo on the threads. Do not get this close to the tip of the plug, just the threads.

Check the torque spec for the plugs. Often people thread it in very hard. If you use the real torque spec you might be surprised at how little torque you use. The long threads are to keep the plug cold, they are not there for you to crank down hard on the plug.

Use that silicon dielectric grease on the plug boot. Do not get this on the electrical contact, just the boot where it touches the porcelain.

Brown stuff on plug is indicating a failing plug. I would suggest a higher quality plug. Avoid Autolite, those are not good. Looks like NGK. I've had good luck with NGK for small engines. The big difference between quality plugs and low cost plugs these days is typically how the porcelain bonds to the metal. I've seen the porcelain of Autolite plugs blow completely out of the metal. I've seen Champions commonly have this brown or black around the bottom of the porcelain, which indicates a loss of combustion gasses and failing porcelain seal. This kind of leakage doesn't effect performance very much, but it does pull allot of heat into the plug making the plug hotter. This extra heat in the plug causes a bunch of long term problems.
Welcome to the friendlier side of internet crazy :)

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Fri Feb 03, 2017 12:35 pm

To resolve the "PB6 req by GPS tx ..." issue you would need to set GPX pins to NONE.

If same firmware and same settings I would expect both boards to just write SD logs, no revision-specific issues I am aware of. "SD enabled: Yes ... fs_ready=No" in your logs make me wonder if hardware issue? I believe you have a logic analyzer if you would like to compare SPI exchange on the SD pins (see schematics)

I unfortunately did not test on the Hunchback before this http://rusefi.com/forum/viewtopic.php?f ... =90#p22513
There is a chance I would be buying a pre-OBD2 car in a couple of months.
Attachments
screenshot.png
screenshot.png (63.58 KiB) Viewed 2677 times
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Mon Feb 06, 2017 5:04 am

russian wrote:To resolve the "PB6 req by GPS tx ..." issue you would need to set GPX pins to NONE.

If same firmware and same settings I would expect both boards to just write SD logs, no revision-specific issues I am aware of. "SD enabled: Yes ... fs_ready=No" in your logs make me wonder if hardware issue? I believe you have a logic analyzer if you would like to compare SPI exchange on the SD pins (see schematics)

I unfortunately did not test on the Hunchback before this http://rusefi.com/forum/viewtopic.php?f ... =90#p22513
There is a chance I would be buying a pre-OBD2 car in a couple of months.
Thanks, I got around the PB6 GPS error. With Rev. C Discovery and current firmware, firmware starts up, but is not stable with TunerStudio now when connect to the discovery microUSB. TS connects for a few seconds then drops, then reconnects again, repeating ... not usable.

With Rev D Discovery and new firmware, firmware works, TS is stable, car runs, but no SD logs. I didn't have time to look into that.

Back to Rev. C Discovery board and 12/2 firmware. It is stable and car runs fine. I tweaked on timing more and now car runs about as good as stock now. Cranking and warm up are not quite perfect yet, but are ok. I still get 6046 / fuel miss warnings. It's not really noticeable when driving. In normal driving, it's not too many warnings, maybe 10 or 20 in 20 minute driving in town. But out on the back roads if I really push it and accelerate through gears, I can get maybe 40 warnings in a burst. Here is an updated tune and log file.

So what other engines are working on rusefi right now? What engine type, what Discovery board type, and what revision of firmware? Can we start tracking these to know what is actually working???
Attachments
CurrentTune.msq
(140.22 KiB) Downloaded 167 times
rus-2017-02-04.msl
(1.29 MiB) Downloaded 410 times

puff
contributor
contributor
Posts: 2738
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Miata NA 1990, 1.6L stock #21

Post by puff » Mon Feb 06, 2017 9:56 am

Just to make sure: usually I face such problem after upgrading firmware.
And it seems each time the problem is resolved by creating a new project in tuner studio, with a proper rusefi.ini file.

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Mon Feb 06, 2017 6:18 pm

tomiata wrote:firmware starts up, but is not stable with TunerStudio now when connect to the discovery microUSB. TS connects for a few seconds then drops, then reconnects again, repeating ... not usable.
I agree with @ - this looks like a mismatch between TS project version and firmware version. Theoretically the best practice is to re-create TS project every time you update firmware, and also to use matching console with it.

There is a bit of usability issue here for sure. I've actually started working on https://sourceforge.net/p/rusefi/tickets/309/ only for console but you made me realize that TS situation could be improved as well. Let me see if I can implement a unified solution for both console and TS to detect incompatibility better.
tomiata wrote:With Rev D Discovery and new firmware, firmware works, TS is stable, car runs, but no SD logs. I didn't have time to look into that.
The part about not working SD logging surprises me.

I am still suspecting that Rev C and Rev D and same exact hardware - I believe the incompatible change to ST Link firmware is the difference. And I believe that updating st link firmware in the discovery is pretty much making Rev C board a Rev D board. And just a reminder, default Rev D firmware is the one from "rusefi over-current" problem so I am now flashing latest discovery firmware into the boards I sell.

With that in mind, I cannot explain lack of SD logging. I would say once you have time to look into that I would upgrade both boards to same discovery firmware, same rusefi firmware and settings. If they do not behave the same I would claim hardware issues. I would love to be wrong in this regard.

I am planning to solder the first of https://sourceforge.net/p/daecu/code/HE ... format=raw today to validate that little thingy and ship it your way with a D board.
tomiata wrote:So what other engines are working on rusefi right now? What engine type, what Discovery board type, and what revision of firmware? Can we start tracking these to know what is actually working???
You might not like what I say now: you are the 95% of real vehicle testing these days. Both Lemons race cars are work-in-progress getting ready for the new season - the yellow race car is not street legal so pretty much driven three times a year. The green race car right now is a tub with no engine, no suspension, no spindles.

Most of my rusEfi time is focused on making Frankenso full bundle look better. I hope that with better usability and slightly sexier looks there will be the critical mass of NA miatas. I am semi-actively looking for a pre-95 Miata already.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

tomiata
contributor
contributor
Posts: 231
Joined: Sat Aug 02, 2014 2:30 am
Location: Texas

Re: Miata NA 1990, 1.6L stock #21

Post by tomiata » Tue Feb 07, 2017 5:12 am

Some good news and some not-so-good news... Good news first.
I agree with @puff - this looks like a mismatch between TS project version and firmware version. Theoretically the best practice is to re-create TS project every time you update firmware, and also to use matching console with it.
Yes, creating a new TS project from scratch solved that problem. Scratch that one off the list. Feb. 4 firmware worked ok to connect to TS on both RevC and RevD Discovery boards.

Also, today running 12/1 firmware on the RevC discovery board, I drove to & from work with no laptop attached, no tweaking idle or temperature curves or autotuning along the way. Throttle response are pretty good. Temperatures are warmer now, maybe that helped.

But... RevD board still no workey to create SD log files. Tried two different RevD boards, both updated with STLINK firmware rev V.2.J27-M15, and with rusefi 12/1 firmware and with 2/4 firmware, I get the error in the console logs:
Tue Feb 07 03:29:58 CST 2017<EOT>: postMessage EngineState: SD enabled: Yes
Tue Feb 07 03:29:58 CST 2017<EOT>: postMessage EngineState: fs_ready=No totalLoggedBytes=0

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Thu Feb 09, 2017 3:10 am

At my place I have four boards with SD card sockets on them
very old frankenstein
2003 frankenso
hunchback frankenso
hunchback data logger

I've just spend two hours trying to get any them to write logs on SD card, NOTHING. Old boars, new boards, old settings, new settings, old firmware, new firmware. USB power and external 12 volts power. To say that I am puzzled would be an understatement.

At the same time @ has his brain board prototype which works with yesterday firmware - but it's a snow storm tomorrow so I would not have a chance to grab his board tomorrow.
2017-02-08 21_30: EngineState: *** rusEFI (c) Andrey Belomutskiy 2012-2016. All rights reserved.
2017-02-08 21_30: EngineState: rusEFI v20170206@11443
2017-02-08 21_30: EngineState: *** Chibios Kernel: 2.6.8
2017-02-08 21_30: EngineState: *** Compiled: Feb 8 2017 - 08:08:39
2017-02-08 21_30: EngineState: COMPILER=4.8.1
2017-02-08 21_30: EngineState: CH_FREQUENCY=1000
2017-02-08 21_30: EngineState: SERIAL_SPEED=115200
2017-02-08 21_30: EngineState: CORTEX_MAX_KERNEL_PRIORITY=2
2017-02-08 21_30: EngineState: STM32_ADCCLK=21000000
2017-02-08 21_30: EngineState: STM32_TIMCLK1=84000000
2017-02-08 21_30: EngineState: STM32_TIMCLK2=168000000
2017-02-08 21_30: EngineState: STM32_PCLK1=42000000
2017-02-08 21_30: EngineState: STM32_PCLK2=84000000
2017-02-08 21_30: EngineState: PORT_IDLE_THREAD_STACK_SIZE=1024
2017-02-08 21_30: EngineState: CH_DBG_ENABLE_ASSERTS=1
2017-02-08 21_30: EngineState: CH_DBG_ENABLED=1
2017-02-08 21_30: EngineState: CH_DBG_SYSTEM_STATE_CHECK=1
2017-02-08 21_30: EngineState: CH_DBG_ENABLE_STACK_CHECK=1
2017-02-08 21_30: EngineState: EFI_WAVE_ANALYZER=1
2017-02-08 21_30: EngineState: EFI_TUNER_STUDIO=1
2017-02-08 21_30: EngineState: EFI_SIGNAL_EXECUTOR_SLEEP=0
2017-02-08 21_30: EngineState: EFI_SIGNAL_EXECUTOR_HW_TIMER=0
2017-02-08 21_30: EngineState: EFI_SHAFT_POSITION_INPUT=1
2017-02-08 21_30: EngineState: EFI_INTERNAL_ADC=1
2017-02-08 21_30: EngineState: WARNING: TPS too low: -18.59
2017-02-08 21_30: EngineState: confirmation_sdinfo:6
2017-02-08 21_30: EngineState: MMC CS PD4
2017-02-08 21_30: EngineState: SD enabled: Yes [rus0208_212937.msl]
2017-02-08 21_30: EngineState: fs_ready=Yes totalLoggedBytes=37417
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
russian
Site Admin
Posts: 9779
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: Miata NA 1990, 1.6L stock #21

Post by russian » Thu Feb 09, 2017 3:45 am

Complaining on the forum always works for me. Just found _one_ SD card which seems to work in three boards already:

Card is a 2GB SandDisk formatted FAT

1) hunchback datalogging - rev D board modified with 32K crystal, latest V2.J27.M15 which I am pretty sure has nothing to do, powered via mini USB
2) frankenstein board - rev C no modifications, powered via mini USB
2b) frankenstein board - different discovery, rev D no modifications, latest V2.J27.M15, powered via mini USB

3) hunchback ECU - another rev D no modifications, latest V2.J27.M15, powered via mini USB

too lazy to go try 2003 ECU. Will play with different SD cards now see if I can figure it out - I know some of them are smaller FAT (not FAT32)

Are you using same board same SD card in both cases?
2017-02-08 22_31: EngineState: *** rusEFI (c) Andrey Belomutskiy 2012-2017. All rights reserved.
2017-02-08 22_31: EngineState: rusEFI v20170208@11443
2017-02-08 22_31: EngineState: *** Chibios Kernel: 2.6.8
2017-02-08 22_31: EngineState: *** Compiled: Feb 8 2017 - 22:30:07
2017-02-08 22_31: EngineState: COMPILER=4.8.1
2017-02-08 22_31: EngineState: CH_FREQUENCY=1000
...
2017-02-08 22_31: EngineState: confirmation_sdinfo:6
2017-02-08 22_31: EngineState: MMC CS PD4
2017-02-08 22_31: EngineState: SD enabled=Yes status=MOUNTED
2017-02-08 22_31: EngineState: filename=rus0208_223046.msl size=45884
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

Post Reply