USB Software update without a Display

Hello,
you can do this by yourself!
Refer http://www.fs-net.de/phpBB2/vi…p=5524&hilit=update#p5524. Rename the "real update tool" and write "your update tool" (two lines) which prints a string to the debug port and lauch the "real update tool".

Ok, i choose bad terms.
What i meant was you can rename "update.exe" from F&S and write you own "update.exe" which launches renamed F&S update program and does something else (read boot delay, write to debug port, ...).

Hello,

Quote

Ok, I think I understand. This would be the same like if I let the update tools name as it is and execute some own code(that writes on debug port) with the X feature of the update tool, correct?

No, i thought we talk about USB detection. Here you can start update program by your own program and check e.g. "boot delay" and do some serial debug output.

Quote

But how should I, means my program detect things like copy failures or a started rolling back action? ...

You can use the "Logfile-feature" (access logfile by your program).

Hello,
- yes, i know what is your purpose. But this feature is not available right now! So i try to give you the possibility of a workaround (which may not be the optimum).

My last concept was that you enable the "Logfile-feature" (see documentation for the NetDCU Update). Logfile should contain all information you need (?). With your own program you can redirect this information to the serial debug line.

If you want that we implement such a feature, for control update without display, please send your specification to <!-- e --><a href="mailto:sales@fs-net.de">sales@fs-net.de</a><!-- e -->.

I'll try to explain it a little bit in more detail. The update process is split in two parts: a small resident program on the board that checks whether a USB stick is inserted and whether it contains an executable program in a special place. And the update program itself, which is located as exactly this executable program on the stick. This program currently only does some output on a connected display.

But the resident part on the board does not specifically look for the update program, it can be any program with the same name in the same location. What fs-support_ZU is suggesting now is that you can replace the update program on the stick by an own small program, that simply does some serial output, e.g. "Starting update process, please wait..." and then calls the main update program. After the update program finishes, your small program can continue to run and output the results of the log file on the serial port, or at least a message "Update complete, please reboot the system." The update program also returns a result value, showing if the update was successful or not. This allows to send the appropriate serial message.

Therefore your "wrapper" program can handle all the serial output without any need of change to the update program itself.

We agree that this is no perfect solution. But currently we have no time to extend the update program ourselves. If you nevertheless don't want to write such a wrapper program yourself and if you want enhancements directly added to the update program, then you have to talk with our distribution to get a quote of the costs involved with this.

Quote from "andyinfsnet"

Do you see what I do wrong?

Yes. The AutoStart.exe is called with a command line parameter that tells whether the program is called with active delay or not (see page 9, "Background Check for Auto Start" in the Update documentation) . You have to pass this parameter (in argv in your _tmain function) on to the main update program ("MyAutoStart.exe"). The parameter reads as "-t <n>" where <n> is the current timeout value.

The Update program decides on the existence of this parameter if it can start with the update or if it must wait for the restart first. If you leave it out, the program assumes the former case and immediately starts the update.

Quote

//Problem is still that we cannot detect a rolling back....

Whats about the log file? You can enable it by your script.

Or in worst case you can read "window text" of the update program (FindWindow->...).

Quote from "andyinfsnet"

Problem is still exisiting that we cannot detect a rolling back. If you have an further idea for that, please tell me.

Well, my first idea was to wait until the update process finishes and look at the return code. But unfortunately when I looked at the update code again, I found that there is the same return value 0 in both cases. Therefore it's not possible to decide if a rollback took place or not.

But I have another idea. How about streaming the log file to the serial port while the update is in progress? Then the user can see what happens right now.

This approach has two advantages: the user sees all actions already during the update process (well, OK, slightly delayed) and the end is here in this program, too, and needs not be done by executing another program showing the final message.

Remark: this code is not tested, maybe it still needs some improvements. But the idea should be clear.

Hope this helps.

Well, what you're saying reveals a major design flaw of my idea: when the update is done, the main window remains active until closed by the user or the board is restarted. Therefore you're right, the wrapper program would stay forever in the output loop and would never reach the end point, as the spawned process will never finish. Damn, I did not think of this.

But this morning I had a new idea anyway. How about this:

• Write a small program SerialOutput.exe that simply outputs its command line arguments to the serial port. This is something like this:
  
  
  Code

  1. int _tmain(int argc, _TCHAR* argv[])
  2. {
  3. int i = 1;
  6. while (i < argc)
  7. {
  8. OutputDebugString(argv[i]);
  9. if (++i < argc)
  10. OutputDebugString(_T(" "));
  11. }
  12. OutputDebugString(_T("\r\n"));
  15. return 0;
  16. }

  Display More

  
  Put the program in the same directory on the stick as the update program. Keep the name AutoStart.exe for the update program.

  
  

  
  

• Add a line at the beginning of your update script
  
  
  Code

  1. X 'SerialOutput "STARTING UPDATE PROCESS, PLEASE WAIT..."' 'SerialOutput "ROLLBACK DONE, UPDATE NOT SUCCESSFUL!!!"'

  
  

• Add a line at the end of your update script
  
  
  Code

  1. X 'SerialOutput "UPDATE PROCESS COMPLETE, PLEASE RESTART BOARD!"'

Well, what happens? The script is started and the first message "STARTING..." is output. If the update process completes successfully, then finally the last command is executed and the "COMPLETE" message is output. However if the rollback starts, then the last message is never reached and instead as the last step the rollback-command of the first line is executed, which is the "ROLLBACK" message.

This is simple, does not require any command line parsing and uses the built-in mechanisms of the update program itself. And I think it's the only way to detect whether the update was successful or failed.

But then the rollback should kick in...