Pages: [1] 2
Author Topic: Critical feature request  (Read 15024 times)
julex
Hero Member
*****

Karma: +78/-4
Offline Offline

Posts: 923


« on: April 19, 2011, 11:50:17 AM »

First off, awesome job Tony! I just tuned my Allroad and your flashing tool is extremely handy, I do have some issues though.

My car is 2001 Allroad. I have to ECUs at this time, one original from 2001 Allroad and one from 2002 A6. They both flash ok on the bench without a single issue ever.

Every time I try to flash in the car though, I am having extremely hard time pushing the flash through successfully (that's with K module fuse out). I believe that there is some issue with Radio interfering with the flash albeit this is just a theory based on the fact that sometimes when transfer visibly stalls the radio display flashes really quick when it is off, and pops up "DIAG" message if the radio happens to be on. Now this is issue is not NEfmoto Flasher specific at all, I used to have Maestro and the same issues were plaguing it as well although their software was re-trying each failed block so 99% of time the flash was successful after all in one short session.

With Nefmoto, for one successful flash I have about 20-30 failed ones anywhere from first to last flashable block (60%ish). I just spent last 3h trying to push a file through and I am still failing so I am taking a break. I am at work and can't bench load it, luckily I have the second ECU with previous version of tune so no big deal swapping it in.

I attached a log from failed session. The important observation of mine is that after failing of the flash, if I don't disconnect from ECU, I can re-try the flash again... almost unlimited times at that.

My request would be to add automatic block re-try on error. Given that the session is still open it should not be a biggie? This would help me and other Allroad (I believe the issue is Allroad specific) owners/user.

Now if the premium version of your software was available, it would also help me somewhat as there would be much less to flash and fail on, but the re-try would help everyone.


Thanks in advance!
« Last Edit: April 19, 2011, 11:55:59 AM by julex » Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +131/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #1 on: April 19, 2011, 12:21:59 PM »

I don't see a log file attached. If I can have a look at the log file, I can determine what we could possibly do to continue or retry despite the error. The flashing software tries really hard to continue in the event of errors, but there are certain cases that are unrecoverable.

The fast flashing premium feature really is awesome, since it only erases and flashing memory sectors that need updating. The next software release containing that feature is done, but I need to tie up a couple loose ends on the website before releasing it.
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
julex
Hero Member
*****

Karma: +78/-4
Offline Offline

Posts: 923


« Reply #2 on: April 19, 2011, 12:38:13 PM »

I don't see a log file attached. If I can have a look at the log file, I can determine what we could possibly do to continue or retry despite the error. The flashing software tries really hard to continue in the event of errors, but there are certain cases that are unrecoverable.

The fast flashing premium feature really is awesome, since it only erases and flashing memory sectors that need updating. The next software release containing that feature is done, but I need to tie up a couple loose ends on the website before releasing it.

Hi Tony, the log file is attached. I forgot to attach it initially and uploaded it about 10 minutes after the original post time.

I noticed that I might have had chosen wrong chip type, I had 29F800 instead of 29F800BB... I chose the new layout and failed only twice, third time I finally flashed ok. Maybe proper layout made the error recovery you mentioned work properly.


Thanks.
« Last Edit: April 19, 2011, 12:40:30 PM by julex » Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +131/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #3 on: April 19, 2011, 12:41:15 PM »

I saw that you updated the post with a log file.

Looking at the log it seems as though the issue is that the TransferData messages sometimes don't get a response from the ECU. Currently the software assumes that if there is no response to the TransferData messages that the ECU probably received it but didn't respond. But then later when we try to exit the transfer, the ECU rejects the exit because it doesn't think we transferred enough data. So this seems to indicate that ECU didn't respond to the TransferData message because it didn't receive it.

Let me see if I can give you a test release that has different behaviour when there is no response to the TransferData message. I can make it not assume that the message was received if there is no response.

The trick with the TransferData messages is that there is no way to know how much data has been received by the ECU. So if the ECU loses a TransferData message, then everything gets out of synch and we have no way of knowing.
« Last Edit: April 19, 2011, 12:42:53 PM by Tony@NefMoto » Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
julex
Hero Member
*****

Karma: +78/-4
Offline Offline

Posts: 923


« Reply #4 on: April 19, 2011, 12:52:09 PM »

I saw that you updated the post with a log file.

Looking at the log it seems as though the issue is that the TransferData messages sometimes don't get a response from the ECU. Currently the software assumes that if there is no response to the TransferData messages that the ECU probably received it but didn't respond. But then later when we try to exit the transfer, the ECU rejects the exit because it doesn't think we transferred enough data. So this seems to indicate that ECU didn't respond to the TransferData message because it didn't receive it.

Let me see if I can give you a test release that has different behaviour when there is no response to the TransferData message. I can make it not assume that the message was received if there is no response.

The trick with the TransferData messages is that there is no way to know how much data has been received by the ECU. So if the ECU loses a TransferData message, then everything gets out of synch and we have no way of knowing.

I understand.

I am not asking to do miracles and figure out the impossible (what was received and what wasn't) but re-trying the current block/sector starting with flash erase for current address range should be sufficient and would do the trick?

I figured something is interfering with transfer as logging on my car is also problematic sometimes due to timeouts etc albeit EcuX and VCDS automatically reconnect so it is not that bothersome only resulting with gaps in data.  Again, this is independent of ECU (two separate ECUs having the same issue in my car) but most likely something else making mess on K-Line. .
Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +131/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #5 on: April 19, 2011, 01:19:29 PM »

The trick is that the ECU will refuse to let you do anything until it thinks the current transfer is complete. In order to make the ECU complete the transfer, you have to just keep sending it data until it reaches the expected amount. I do detect incomplete failed transfers and cause them to abort, but I think I only do that when you attempt to enter programming mode at the very beginning. I will see if I can some extra sector retry code that handles this case. This wouldn't be until the next release though, but I should be able to give you a test build in the mean time that may let you avoid this problem.
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
julex
Hero Member
*****

Karma: +78/-4
Offline Offline

Posts: 923


« Reply #6 on: April 19, 2011, 01:25:06 PM »

The trick is that the ECU will refuse to let you do anything until it thinks the current transfer is complete. In order to make the ECU complete the transfer, you have to just keep sending it data until it reaches the expected amount. I do detect incomplete failed transfers and cause them to abort, but I think I only do that when you attempt to enter programming mode at the very beginning. I will see if I can some extra sector retry code that handles this case. This wouldn't be until the next release though, but I should be able to give you a test build in the mean time that may let you avoid this problem.

Big thanks!

I just wanted to point one thing again. When it aborts like that, I can re-initiate the transfer in the same session immediately without any issues but if I power off the ignition the ECU will brick and I have to pull fuses/disconnet battery for at least 1minute for it to reset and allow new session. If it is possible for you to write any arbitrary memory address in the ECU, as it appears to be, it should be possible to jump to beginning of memory address range that failed and re-try?

Apologies if I am drilling you about something that is not easily doable.

Thanks!
Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +131/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #7 on: April 19, 2011, 01:43:01 PM »

If you turn off the ignition after a failed flash, then the ECU should stay in programming mode as long as you don't disconnect power to the ECU. If you disconnect power to the ECU it will reboot in regular mode, and will try to run the program in its flash memory, which may be garbage.

If you disconnect after a failed flash you should be able to reconnect using slow init. I have found that fast init does not cause the current failed programming session to abort, but slow init does seem to. So my question is, does slow init allow you to reconnect after disconnecting from a failed flash?

Continuing a flash from where we previously failed is possible if I add feature to the code. I can keep track of the state of the ECU flash sectors, and figure out which ones need to be flashed, as long as we stay connected to the ECU. But if we disconnect from the ECU, then I don't have a way to know if I should start from the beginning or not. You may have disconnected from ECU 1, and reconnected to ECU 2, so I can't assume I should start where we previously failed.

The flashing system is able to determine which sectors match and skip sectors that don't need to be flashed. I consider this a premium feature though, so I don't want to base the error recovery mechanism of failed flashing on it. Adding error recovery of failed sector flashing that allows you to retry flashing the current sector without restarting from the beginning is now on my todo list.
« Last Edit: April 19, 2011, 01:55:29 PM by Tony@NefMoto » Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
julex
Hero Member
*****

Karma: +78/-4
Offline Offline

Posts: 923


« Reply #8 on: April 19, 2011, 01:52:21 PM »

If you turn off the ignition after a failed flash, then the ECU should stay in programming mode as long as you don't disconnect power to the ECU. If you disconnect power to the ECU it will reboot in regular mode, and will try to run the program in its flash memory, which may be garbage.

I understand that by saying "turning off ignition" you mean backing the key into accessory position? I always just backed it all the way...

If you disconnect after a failed flash you should be able to reconnect using slow init. I have found that fast init does not cause the current failed programming session to abort, but slow init does seem to. So my question is, does slow init allow you to reconnect after disconnecting from a failed flash?
Not sure as I had no need to do that. If I connect with Fast Init the session is active even after the flashing fails. I can immediately re-try flashing whole flash memory without doing anything else than just pressing that one button.

I can experiment with slow init just to have an answer for you next time I try flashing the car.


Continuing a flash from where we previously failed is possible if I add feature to the code. I can keep track of the state of the ECU flash sectors, and figure out which ones need to be flashed, as long as we stay connected to the ECU. But if we disconnect from the ECU, then I don't have a way to know if I should start from the beginning or not. You may have disconnected from ECU 1, and reconnected to ECU 2, so I can't assume I should start where we previously failed.

Re-trying only during current session is all that would be needed. Storing the state and resuming in next session would be an accident waiting to happen and I understand that.

The flashing system is able to determine which sectors match and skip sectors that don't need to be flashed. I consider this a premium feature though, so I don't want to base the error recovery mechanism of failed flashing on it. Adding error recovery of failed sector flashing that allows you to retry flashing the current sector without restarting from the beginning is now on my todo list.

Keep us posted about premium feature, I even got a proper cable to be able to use it Smiley
« Last Edit: April 19, 2011, 01:55:42 PM by Tony@NefMoto » Logged
nyet
Administrator
Hero Member
*****

Karma: +605/-168
Offline Offline

Posts: 12243


WWW
« Reply #9 on: April 19, 2011, 07:58:03 PM »

The trick with the TransferData messages is that there is no way to know how much data has been received by the ECU. So if the ECU loses a TransferData message, then everything gets out of synch and we have no way of knowing.

Seriously?

As a networking/communications guy, this sort of lazy design pisses me off to no end.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +131/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #10 on: April 19, 2011, 08:03:46 PM »

The trick with the TransferData messages is that there is no way to know how much data has been received by the ECU. So if the ECU loses a TransferData message, then everything gets out of synch and we have no way of knowing.

Seriously?

As a networking/communications guy, this sort of lazy design pisses me off to no end.

Yup, it's a real pain in the ass. You RequestDownload for a specific address and size, then you TransferData until you finish sending all of the data. The TransferData messages have no address or offset information inside them. Also the TransferDataPositiveResponse have no address, offset, or size in it. So if you fail to send one TransferData message, you have no way of guaranteeing that you are still in synch. If you get out of synch, there is no way to end the transfer of data either. The ECU will reject all requests until it gets all of the data it expects. The way I handle this is by just sending TransferData messages of a 0xFF until the ECU is happy.

The last project I was on I was doing client server networking, and yes, the KWP2000 flashing protocol sucks.
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +131/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #11 on: April 20, 2011, 11:59:36 AM »

julex, if you send me a PM with your email address, I can give you a test release which may improve things in the meantime. The test release changes the behaviour of flashing such that it will retransmit failed TransferData messages rather than assuming they were sent correctly.

I am testing some changes I may to allow retrying flashing of the current sector if flashing that sector fails due to bad TransferData messages. These changes won't be ready for little while longer though.
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
julex
Hero Member
*****

Karma: +78/-4
Offline Offline

Posts: 923


« Reply #12 on: April 22, 2011, 07:07:12 AM »

Using the special version I was able to flash my car three times already without a single hiccup. Very nice, thank you!
Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +131/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #13 on: April 22, 2011, 02:54:11 PM »

Awesome. Smiley

Can you send me the log file or post it here so I can see how it is working?
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
julex
Hero Member
*****

Karma: +78/-4
Offline Offline

Posts: 923


« Reply #14 on: April 22, 2011, 03:18:17 PM »

Awesome. Smiley

Can you send me the log file or post it here so I can see how it is working?

Log is attached.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.047 seconds with 17 queries. (Pretty URLs adds 0.009s, 0q)