I have some troubles with partial IFU. It seems that when I update with config firmware firmware2 and the app. all is ok. But as soon as I just update app.hex the board does not work anymore. Assembly are missing…
The board stalls and nothing happens. The only way to have some debugging information is to restart CLR using MFdeploy: here’s the output:
[quote]Connecting to EMX_EMX…Connected
Created EE.
Found debugger!
Create TS.
Loading start at a0e00000, end a0e1383c
Assembly: mscorlib (4.2.0.0) Assembly: Microsoft.SPOT.Native (4.2.0.0) Assembly: Microsoft.SPOT.Security.PKCS11 (4.2.0.0) Assembly: System.Security (4.2.0.0) Loading Deployment Assemblies.
Attaching deployed file.
Assembly: Microsoft.SPOT.IO (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.IO (4.2.11.1) Attaching deployed file.
Assembly: Microsoft.SPOT.Graphics (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.USBHost (4.2.11.1) Attaching deployed file.
Assembly: Microsoft.SPOT.TinyCore (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0) Attaching deployed file.
Assembly: USBH_SDC (2.0.33.0) Attaching deployed file.
Assembly: GHI.Premium.System (4.2.11.1) Attaching deployed file.
Assembly: System (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.USBClient (4.2.11.1) Attaching deployed file.
Assembly: Microsoft.SPOT.Net (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.Hardware (4.2.11.1) Attaching deployed file.
Assembly: System.IO (4.2.0.0) Attaching deployed file.
Assembly: USU (2.0.33.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1) Attaching deployed file.
Assembly: GHI.Premium.Net (4.2.11.1) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware.OneWire (4.2.0.0) Attaching deployed file.
Assembly: MFDpwsExtensions (4.2.0.0) Resolving.
Link failure: some assembly references cannot be resolved!!
Assembly: USBH_SDC (2.0.33.0) needs assembly ‘FtpServer’ (1.0.0.0)
Assembly: USBH_SDC (2.0.33.0) needs assembly ‘GHI.Premium.SystemUpdate’ (4.2.11.1)
Assembly: USU (2.0.33.0) needs assembly ‘USBH_SDC’ (2.0.33.0)
Assembly: USU (2.0.33.0) needs assembly ‘System.Xml’ (4.2.0.0)
Assembly: USU (2.0.33.0) needs assembly ‘GHI.Premium.SystemUpdate’ (4.2.11.1)
Error: a3000000
Waiting for debug commands…[/quote]
Ok this seems to be solved. To briefly explain:
I can update the platform using ftp server that put hex files on the SDCard.
After data transfert, file are loaded an de deleted. then system update.flashandreset.
The problem was that after deletion, SDC is not flush and files was still existing on the card. After rebooting the system find again firmware.hex on the card, it start then to update but some files may miss…
I do not know if its completely solved (can not explain why assembly are missing if app is correctly loaded) …
May be it only couldn’t find the correct version of the assembly.
@ leforban - I tried IFU with firmware, config, and app and then just app and both cases worked fine multiple times in 4.3. IFU has not changed internally between 4.2 and 4.3 so your explanation seems to be the likely one. If in doubt, create a quick IFU test outside of your normal application.
@ Reinhard. app.hex is the same for the full update and the partial one. I think the problem was non deletion of files before flash and update methods. However, I am using canupdate method that should prevent a bad firmware file. So I can still not explain why after reboot the second update failed and crashes the system if canupdate check for app.hex integrity.
We had the same problem last week:
[quote]EMX
Version: 4.2.11.1
Debug: COM1
LCD: 0x0
.NetMF v4.2.0.0
EMX, Build Date:
Oct 17 2013 09:45:30
ARM Compiler version 410713
TinyCLR (Build 4.2.0.0)
Starting…
Created EE.
Started Hardware.
MSdbgV1k§""eâ71y©Create TS.
Loading start at a0e00000, end a0e1383c
Assembly: mscorlib (4.2.0.0) Assembly: Microsoft.SPOT.Native (4.2.0.0) Assembly: Microsoft.SPOT.Security.PKCS11 (4.2.0.0) Assembly: System.Security (4.2.0.0) Loading Deployment Assemblies.
Attaching deployed file.
Assembly: Microsoft.SPOT.IO (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.IO (4.2.11.1) Attaching deployed file.
Assembly: Microsoft.SPOT.Graphics (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.USBHost (4.2.11.1) Attaching deployed file.
Assembly: Microsoft.SPOT.TinyCore (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0) Attaching deployed file.
Assembly: USBH_SDC (2.0.37.0) Attaching deployed file.
Assembly: GHI.Premium.System (4.2.11.1) Attaching deployed file.
Assembly: System (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.USBClient (4.2.11.1) Attaching deployed file.
Assembly: Microsoft.SPOT.Net (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.Hardware (4.2.11.1) Attaching deployed file.
Assembly: System.IO (4.2.0.0) Attaching deployed file.
Assembly: USU (2.0.37.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1) Resolving.
Link failure: some assembly references cannot be resolved!!
Assembly: USBH_SDC (2.0.37.0) needs assembly ‘FtpServer’ (1.0.0.0)
Assembly: USBH_SDC (2.0.37.0) needs assembly ‘GHI.Premium.Net’ (4.2.11.1)
Assembly: USBH_SDC (2.0.37.0) needs assembly ‘GHI.Premium.SystemUpdate’ (4.2.11.1)
Assembly: USU (2.0.37.0) needs assembly ‘USBH_SDC’ (2.0.37.0)
Assembly: USU (2.0.37.0) needs assembly ‘Microsoft.SPOT.Hardware.OneWire’ (4.2.0.0)
Assembly: USU (2.0.37.0) needs assembly ‘System.Xml’ (4.2.0.0)
Assembly: USU (2.0.37.0) needs assembly ‘GHI.Premium.SystemUpdate’ (4.2.11.1)
Assembly: USU (2.0.37.0) needs assembly ‘GHI.Premium.Net’ (4.2.11.1)
Error: a3000000
MSdbgV1Þ; Waiting for debug commands…[/quote]
This time USB becomes unreachable. The version of the application before IFU was not flushing and unmount SD card before restart and therefore before update. Again IFU should not start in this case if files are corrupted… and why files are corrupted? version number are correct it succeed to link some assemblies, why not all?
I am able to reproduce the bug. This happens in 4.2.11 sdk. The bug is the one I described, the app.hex is corrupted. The application does not wait enough for data to be properly saved and reboot. Therefore some bytes are missing (839kB instead of 1057kB).
I thought CanUpdate was checking data integrity of hex files!!! Please GHI add more comments on what your methods are doing or not doing! Don’t let user try and see…
@ leforban - Have you tried to flush the SD card after you delete the files and before you call FlashAndReset()? VolumeInfo.GetVolumes()[0].FlushAll().
Instead of deleting the files, you could keep a small text file on the card that contains the version of the firmware and application on it and compare that against the current system versions and only updating if needed that way you are only reading from the SD card after you write the initial files.
We do parse the hex files and check for valid lengths but there is no built in integrity check beyond that as far as I know.
the problem is not file deletion but comes from the fact that before restarting the board, I was not calling the flush method and therefore file was corrupted.
What do you mean by valid length? I have here the problematic app.hex (the troncated one) and canupdate returns true for this file whereas it should not be the case.
@ leforban - The hex file format used by NETMF has a length as part of it, the byte count field: SREC (file format) - Wikipedia
So this won’t work; the file is truncated but canupdate returns true.
See the end of the problematic hex file
This line should end with 017EDA as in the correct hex part (see bellow)
Data length is 15 for all the line. I thought canupdate will check that and would reject the update in such a case.
@ leforban - We will look into possibly verifying more of the data you pass to us in a future 4.3 SDK but for now I would make sure you call flush.
yep calling flush is needed, this is true. However if the file is corrupted for other reason it would be great that canupdate check data integrity (length and crc)… If not we need to do that by our own ways.