[README] End users, PLEASE subscribe to this topic - MAJOR firmware announcements

[AndreyB]

Bake Cookies Day released

December 2020 Bake Cookies Day

Breaking Changes
GM x24 trigger now uses 0 offset (offset is now built in, previously needed 50 degrees offset)

Added
DAIHATSU 3/4 cylinder trigger https://rusefi.com/images/triggers/trigger_6.png
Ford ST170 VVT cam trigger https://rusefi.com/images/triggers/trigger_42.png
Changed scheduling timer driver to improve scheduling accuracy #1983

Fixed
microRusEFI GP3 & GP4 fixed

[AndreyB]

Breaking change:

On our way to quad VVT first VVT shaft target is now "vvt table #1" not "fsio table #1" like before. Anyone using VVT control would have to copy-paste their target table.

More renaming would probably follow later.

image.png (52.86 KiB) Viewed 203906 times

[AndreyB]

New release https://github.com/rusefi/rusefi/releases/tag/2021.03.10_release

[AndreyB]

New release https://github.com/rusefi/rusefi/releases/tag/2021.04.17_release

[AndreyB]

While anyone is free to self-assemble anything we publish... Please don't. The rusEFI project uses machine assembled boards to avoid having to troubleshoot poorly user-assembled boards.

[Simon@FutureProof]

We have outlined the reason for this decision in the wiki page here.

We hope everyone will understand and appreciate there are good reasons for this with the recent hardware.

https://github.com/rusefi/rusefi_documentation/blob/Build-the-firmware/FAQ/FAQ-Why-No-Self-Assembly.md

[AndreyB]

https://github.com/rusefi/rusefi/releases/tag/2021.06.28_release release with major idle improvements!

[AndreyB]

In preparation to two banks of VVT in my Nissan we have a small breaking change in snapshot builds:

Code: Select all

### Breaking Changes
 - vvtOffset field migrated to four vvtOffsets fields. Anyone using VVT would need to manually adjust their configuration.  

[AndreyB]

We have a release candidate https://github.com/rusefi/rusefi/releases/tag/2021.08.27_release

[AndreyB]

TS project had issues in 2021.08.27 so now a new release candidate https://github.com/rusefi/rusefi/releases/tag/2021.09.09_release

[tmbryhn]

Feel free to move to correct sub-forum if appropriate.

Just wanted to give a shout out that I've uploaded last firmware release for Proteus (20210909_013133) together with my current tune file made with a previous nightly build (20210714_031445_proteus_f4), and I get this error:

error.png (311.88 KiB) Viewed 202229 times

.msq uploaded here:
https://rusefi.com/online/?vehicleName=Aurora&user_id=1083&sorts[uploadedMsq]=-1&sorts[uploadedLog]=-1

Any ideas how to get this fixed?

[AndreyB]

I read the message is "invalid table axis must be ascending! VE"

please consider fixing your VE table axis and have keys ascending. Two keys of same "1" value is not a valid rusEFI table at https://rusefi.com/online/view.php?msq=638&dialog=veTableDialog

[tmbryhn]

Thanks. I just noticed, lol. After fixing VE, I got prompted with the exact same problem for the VVT intake and exhaust tables (even though I don't have VVT enabled either under advanced trigger or VVT settings).
Had to put in some arbitrary acceding values on X and Y to make the error go away. All fine now, but would've been nice to get that cleaned up

[AndreyB]

but would've been nice to get that cleaned up

Great idea! this is now done https://github.com/rusefi/rusefi/commit/410e449a22128ba770074f60c19291d2bbc978ee

[AndreyB]

We have pre-release https://github.com/rusefi/rusefi/releases/tag/2021.10.07_release

Will promote that one to full release status in 48 hours unless we come up with major defects.

[AndreyB]

In _snapshot_ we now use STM32CubeProgrammer and current STM32 Bootloader driver instead of legacy DfuSe tool and driver.

It's going to be a messy transition, next step would be to update https://github.com/rusefi/rusefi/wiki/HOWTO-DFU

Reminder that we have Install Drivers button in rusEFI console, please download full new bundle, just auto-updating would not get you fresh drivers pack. Fresh drivers pack is called silent_st_drivers2.exe not silent_st_drivers.exe

This change is needed to better support newer chips like F7 used on Proteus 0.6

javaw_QGMp6FyFHw.png (46.41 KiB) Viewed 201749 times

javaw_BzNH5sAlL6.png (19.31 KiB) Viewed 201749 times

[AndreyB]

Some minor internals renaming related to VVT outputs: please make sure your VVT output pin and frequency are migrated while updating to latest firmware. https://github.com/rusefi/rusefi/commit/5f4fa50682e3cfbac81690969d478ea6335535ac

[AndreyB]

Just removed FSIO from user interface. While deep inside some system logic still runs using FSIO for now, for end users it's Lua time.

https://github.com/rusefi/rusefi/issues/2928

[AndreyB]

We have a release candidate https://github.com/rusefi/rusefi/releases/tag/2021.11.14_release

[Zeiss]

Hello Andrey,

what does "hardware_QC_special_build" mean?

Many thanks.

[AndreyB]

what does "hardware_QC_special_build" mean?

Added into https://rusefi.com/build_server/readme.txt

[AndreyB]

More detailed announcement later but David has made http://wiki.rusefi.com/

[Zeiss]

I've tried to install this RC on my Proteus, but it's failed and now is and now Proteus is no longer recognized by Windows (device manager).

Logfile from FW-update is attached.

I'm able to boot MCU into Bootloader mode (by pressing PROG-button during power on) and I can reprocduce update firmware with the same result. If Proteus is in Bootloader-mode, I see this in device manager under USB-Devices I see STM32 BOOTLOADER:

grafik.png (3.8 KiB) Viewed 200264 times

Sorry, it's in German.

[AndreyB]

Zeiss, please clarify if you are good at the moment or in the indefinitely loop of bricked?

I've just added stm32-read-dfu.bat script into console\STM32_Programmer_CLI\bin

If yours is a brick at the moment can you please
1) get fresh bundle
2) go to console\STM32_Programmer_CLI\bin and execute stm32-read-dfu.bat to preserve the broken image for later investigation (rusefi_dump.hex file should be created)

once you have rusefi_dump.hex you can use stm32-full-erase.bat for full erase and attempt to flash either RC or latest good release in order to un-bricked if you are bricked

[Zeiss]

Hello Andrey,

thank you for a fast response!

Zeiss, please clarify if you are good at the moment or in the indefinitely loop of bricked?

At the moment I'm in the indefinitely loop of bricked: bootloader --> flash hex file --> error by verify --> restart board --> no recognition in Windows --> bootloader -->.....

I've just added stm32-read-dfu.bat script into console\STM32_Programmer_CLI\bin

Where did you add it? I just downloaded this bundle and it's not in there. Is it a wrong one?

[AndreyB]

Where did you add it?

yes that's wrong. see https://github.com/rusefi/rusefi/wiki/Release-Process

[Zeiss]

Argh, damned... okay, new try.

If yours is a brick at the moment can you please
1) get fresh bundle

Done, I took this one: https://rusefi.com/build_server/rusefi_bundle_proteus_f7.zip

2) go to console\STM32_Programmer_CLI\bin and execute stm32-read-dfu.bat to preserve the broken image for later investigation (rusefi_dump.hex file should be created)

Done, file and log attached.

once you have rusefi_dump.hex you can use stm32-full-erase.bat for full erase and attempt to flash either RC or latest good release in order to un-bricked if you are bricked

grafik.png (22.86 KiB) Viewed 200242 times

After that power cycle into Bootloader and upload firmware with RusEfi Console and all clear!

Thank you verymuch!

[AndreyB]

I believe I had cases of same. This is now https://github.com/rusefi/rusefi/issues/3566

I believe that this is not about specific RC but just an F7 issue we have

[AndreyB]

Release candidate https://github.com/rusefi/rusefi/releases/tag/2021.12.22_release

[Zeiss]

Hello Andrej,

I've got some problems after upgrade to January 2022 Release - "Green Juice". I've used this bundle: https://github.com/rusefi/rusefi/releases/download/20220126.release/rusefi_bundle_proteus_f7.zip

I've followed these instructions: https://github.com/rusefi/rusefi/wiki/F7-requires-full-erase

Result:
-> after power cycle I don't have any drives "mounted" (either drive contains rusefi_proteus_f7.ini nor the installed SD card)
-> if I start console, I get the connection dialog, the I hit connect (the right COM port is choosen), the console opens as "not connected"
-> after some time (ca. 10 seconds or so) the console closes without error messages or the like

In CMD I see this output:

rlog Writing to logs/MAIN_rfi_report_2022-03-02_09_28_36_903.csv
2022-03-02_09_28_36_915<EOT>: OS name: Windows 10
2022-03-02_09_28_36_916<EOT>: OS version: 10.0
Console configuration not found C:\Users\Heinrich\.rusEFI\console_properties.xml, using defaults
LazyFile: Not updating logs/README.html since looks to be the same content, new content size=171
Opening rusefi_tool.log
2022-03-02_09_28_37_769<EOT>: Rendering available ports: [Auto Serial, COM11]
2022-03-02_09_28_38_000<EOT>: Reading from https://rusefi.com/console/versions.txt
Wed Mar 02 09:28:38 CET 2022: Server recommends java_console version 20171217 or newer
Wed Mar 02 09:28:38 CET 2022: Server recommends firmware 14892 or newer
Wed Mar 02 09:28:39 CET 2022: Connection refused in getAvailablePorts(): simulator not running in 2041ms
Wed Mar 02 09:28:39 CET 2022: Connection refused in getAvailablePorts(): simulator not running in 2047ms
communicationThread lookup DONE
class com.rusefi.io.CommandQueue: SerialIO started
2022-03-02_09_28_41_978<EOT>: Settings file not found or damaged. Using default settings.
2022-03-02_09_28_42_292<EOT>: Console 20220124
2022-03-02_09_28_42_292<EOT>: Hardware: F4
Zoom setValue 1.0
ANTLR Tool version 4.5 used for code generation does not match the current runtime version 4.9.3
Wed Mar 02 09:28:42 CET 2022: Connection refused in getAvailablePorts(): simulator not running in 2039ms
ANTLR Tool version 4.5 used for code generation does not match the current runtime version 4.9.3
line 8:6 missing ';' at '['
Got from settings:
2022-03-02_09_28_47_428<EOT>: onWindowOpened
class com.rusefi.io.LinkManager$5: Opening port: COM11
FuelTunePane: Loaded [28.0, 23.0, 17.0, 10.0, 0.0, 0.0, 0.0, 0.0, 32.0, 28.0, 23.0, 17.0, 10.0, 0.0, 0.0, 0.0]
FuelTunePane: Loaded [35.0, 32.0, 28.0, 23.0, 17.0, 10.0, 0.0, 0.0, 37.0, 35.0, 32.0, 28.0, 23.0, 17.0, 10.0, 0.0]
2022-03-02_09_28_48_813<EOT>: ConnectionWatchdog.reconnectTimer restarting: 5000
Shutdown hook...
SystemOut Hook done for rusefi_tool.log
Saved settings to C:\Users\Heinrich\.rusEFI\console_properties.xml
Shutdown hook!

E:\_Software\rusEFI\January_2022\snapshot_20220126_214648_proteus_f7_rusefi\console>

and the content of rusefi_tool.log is:

logs/README.html does not exist considering empty current content
LazyFile: Not updating logs/README.html since looks to be the same content, new content size=171
LazyFile: Not updating logs/README.html since looks to be the same content, new content size=171
LazyFile: Not updating logs/README.html since looks to be the same content, new content size=171
LazyFile: Not updating logs/README.html since looks to be the same content, new content size=171

I think I am too stupid to update the firmware of my Proteus...

The strange thing is:

2022-03-02_09_28_41_978<EOT>: Settings file not found or damaged. Using default settings.
2022-03-02_09_28_42_292<EOT>: Console 20220124
2022-03-02_09_28_42_292<EOT>: Hardware: F4

I've got a revision 0.6 with F7 in it...