Click here to Skip to main content
15,887,966 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi,
i am writing to a file in USB and while in progress i removed the USB. In the code i am using fwrite to write to the file. i put a try{} catch(...){} block to handle the exception. Exception wasn't getting caught.

i have a requirement to upgrade the firware from USB. so i am using fread to read a chunk of data from the file and sending the command to the module. While the reading is in progress, i removed the USB. Same try{} catch(...){} block to handle the exception. but the exception is not gettign caught

Thanks
Ajai
Posted
Comments
Sergey Alexandrovich Kryukov 19-Mar-13 9:59am    
If exception is not caught, does it mean the file was read successfully? It is actually possible...
Did you run it under the debugger? Could you see the result of reading?
Also, it's usually important not to catch exception locally, but catch it up the stack (this won't solve your problem, just for general design).
—SA
ajaiisnow 19-Mar-13 10:06am    
yes the file read got completed successfully with out any exception.
i ran in debugger and i am suppose to read 64 bytes in each iteration and it is reading successfully 64 bytes. the return code for fread is returning 64.

in case of fwrite, as the file is invalid the system hangs if i remove the usb in between.
Jochen Arndt 19-Mar-13 10:09am    
Which exception did you expect? fwrite() does not throw exceptions. Use the CFile class if you want exceptions.
ajaiisnow 19-Mar-13 10:13am    
i am new to WINCE. Is it specific to WINCE CRT version that exception trowing is avoided.

thanks
Ajai
Matthew Faithfull 19-Mar-13 11:08am    
It's not specific to WinCE CRT but in general WinCE doesn't code doesn't use exceptions, at least it didn't with WinCE 3 through 5 on an ARMV4I device which is what I used to work on. Generally the removal of USB storage in the middle of reading and writing is not safe on
WinCE devices and I don't believe you can make it so. Even if you can at the WinCE end you'll need thouroughly tested industrial grade flash storage on the other end or 1 in every few hundred times your storage device will be effectively destroyed anyway.

1 solution

If possible you should first copy the firmware from the USB drive to a safe memory location and when complete you should validate the data on the copy and then upgrade the firmware.

Directly upgrading from the USB key is not safe as the user can remove the key at any point.

You should at least validate that all bytes were copied to the temporary location and if possible you might want to do a checksum or other validation to ensure that the firmware is valid before using it.

And in any case, you should tell the user not to remove the USB key while upgrading as you want to be on the save side and if somethying goes wrong then you can ask the user if he has followed the instructions to help ensure that users won't abuse your technical support.

Finally, the hardware should be designed in a way to be safe enough. In a case like yours, I would recommand you to have memory specifically reserved for upgrading the firmware.
 
Share this answer
 
v2
Comments
Matthew Faithfull 19-Mar-13 13:49pm    
+5 and then some. I'd forgetten most of the details of what we used to do but they were just as you said.
Maciej Los 19-Mar-13 14:34pm    
Good point!
+5
ajaiisnow 20-Mar-13 3:21am    
Thanks philippe,
Actually the client needs that firware to be upgraded from USB only, and has to be handled when USB is removed. so only i am trying these different type of file operations.
Philippe Mori 20-Mar-13 8:45am    
What can you do when the user remove the key. The partly upgraded device will probably not works anymore. Could the user restart the upgrade if it fails? By the way, I abswolutely don't recommand to do an upgrade from USB because your upgrade code it much more complexe than upgrading from memory (thus you have a much higher risk that you will need to eventually upgrade the boot loader itself) and USB key are prone to failures. You remove them at thne wrong time and they are corrupted (and everything is lost at least without using recovery programs).

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900