2010-03-02 07:18:38     flashw

Document created by Aaronwu Employee on Aug 20, 2013
Version 1Show Document
  • View in full screen mode

2010-03-02 07:18:38     flashw

Filip Vanalme (BELGIUM)

Message: 86723   


From within my application, I need to do an upgrade of the software. I.e. loading a new image in flash memory. I would like to do that with the flashw tool (using the system call). On the other hand, my application has to trigger a watchdog at regular intervals. For that, I created a sperate thread that does the triggering job. I noticed, however, that during the flashing process, the other thread was not running anymore. Apparently, the flashw process holds all other threads. Is this normal behaviour, or has this something to do with the priority of the watchdog-thread ? Is there another, maybe better way to do the flash job ?




2010-03-02 09:54:27     Re: flashw

Mike Frysinger (UNITED STATES)

Message: 86725   


i guess it depends.  flashw isnt a system call, it's an external app, so depending on how you're forking/execing things ...


most people dont bother with flashw anymore anyways.  it can be done with a lot more flexibility using standard tools:

- wget/ftp/etc... the file

- crc/md5/sha1/etc... the file

- dd the file into /dev/mtdblock#

- compare the mtdblock# to the file written




2010-03-03 10:54:05     Re: flashw

Filip Vanalme (BELGIUM)

Message: 86761   


Thanks Mike for the answer.


I could solve my problem by putting the "dd ......" system call into a separate thread instead of in the main thread. That way, I could trigger my watchdog from within a while loop in the main thread, while the flashing was going on in the other thread.




2010-03-03 15:34:39     Re: flashw

Frank Van Hooft (CANADA)

Message: 86765   


For me personally, I don't like having my watchdog refreshes in a separate thread. I'm always afraid in that case of my main code thread having a problem and hanging, whereas my watchdog refresh thread would happily keep running, thereby resulting in no processor reboot even though I need it. So I put watchdog refreshes in amongst my main application code. Is that the best way to do it? I don't know. But that's what I do.


So given that, when I do an update to flash memory, beforehand I set the watchdog timeout to a much larger value, then after the flash writing is complete I set the watchdog timeout back to a short duration again.




2010-03-03 19:45:49     Re: flashw

Mike Frysinger (UNITED STATES)

Message: 86768   


i dont see how your original attempt would work either with putting the execution and watchdog in the same thread.  `dd` is simply while (1) { read(); write(); }, so implementing that yourself while also inserting a call to the watchdog pet seems like it should be straight forward ...


or i'm not understanding what it is you're trying to do exactly.




2010-03-08 10:39:32     Re: flashw

Filip Vanalme (BELGIUM)

Message: 86955   


Hi Mike,




Indeed, I could have done it with a while loop and readin/writing/triggering the watchdog within the loop.


Writing a new binary to flash works well now. After the writing, I reset the board with a system("reboot") command. This works, but I notice a delay of several seconds between executing the reboot command and the real reboot. It's not really a problem, but I wonder if this is normal behaviour ? Is this because the system still has to finish some actions in background before it can really reboot (e.g. some handling of the filesystem that has to finish before reboot can take place) ?








2010-03-08 10:48:07     Re: flashw

Mike Frysinger (UNITED STATES)

Message: 86956   


yes, when you reboot, the system will flush all its pending disk caches and such.  if you were writting to some mtd device or using jffs, i could see there being a delay for the flash sectors to finish programming.  i dont think there's anything you can do about this if you're writing things.