I have implemented IFU support in out application.
I can update the application, but when I tries to update all files (config, firmware, firmware2 and application/deployment) the firmware is wiped.
The update process works fine. After call to FlashAndReset() the device reboots but never wakes up.
Unitl I load the config, firmware and firmware2 with FezConfig. And now it has the latest application.
This is my sequence.
if (SystemUpdate.CurrentSystemUpdateStatus == SystemUpdate.SystemUpdateStatus.Inactive)
// Set that we are going to update all areas, we may not do all but there is no way later to adjust it.
SystemUpdate.Load(SystemUpdate.SystemUpdateType.Config, hex, count)
SystemUpdate.Load(SystemUpdate.SystemUpdateType.Firmware, hex, count)
SystemUpdate.Load(SystemUpdate.SystemUpdateType.Firmware, hex, count) // Firmware 2
SystemUpdate.Load(SystemUpdate.SystemUpdateType.Deployment, hex, count) // Application
I am not sure but I think something wrong with these,
count = stream.Read(data, 0, (int)(length - byteCount < BLOCK_SIZE ? length - byteCount : BLOCK_SIZE)); // Read the remainging part
if (count <= 0)
if (blockCount == 0 && stream.CanTimeout)
stream.ReadTimeout = 1000; // We are now in sync, reduce timeout
hex = crypter.Decrypt(data, count);
hex = data;
// Check that the line starts with a 'S' (0x53) and ends with line feed 0x0D + 0x0A)
if (hex != 0x53 || hex[count - 2] != 0x0D || hex[count - 1] != 0x0A)
// "Wrong start or end of hex line." +
// " Start: " + Converter.ToString(hex, true) +
// " End: " + Converter.ToString(hex[count - 1], true) +
// ". Block " + blockCount++ + "/" + blocknum + ", Bytes: " + byteCount + "/" + length);
SystemUpdate.Load(ifutype, hex, count);
byteCount += count;
//LogHandler.Instance.LogInformation("Updater", "Block " + blockCount++ + "/" + blocknum + ", Bytes: " + byteCount + "/" + length);
} while (count == BLOCK_SIZE); - See more at: https://www.ghielectronics.com/community/forum/topic?id=14142&page=1#msg144346
1- Why do you need to check them:
IFU does it inside and if there is wrong format, an exception will be raised. and the second and the third , 0x0D and 0x0A, why are they these number? I remmember if they are in a line, the last will be CRC and the last -1 is our firmware data, nothing like 0xD and 0xA
2- Where is the rest, let say you have 101 bytes, block is 10, so the rest will be 1, where is that?
3- I don't think this condition is correct, try to add debug.print to see data is loaded correctly or not.
while (count == BLOCK_SIZE);
I check this to make sure, if file is crypted, that we have a complete decryption without any data loss. As the HEX file is in ASCII, each line ends with CR and LF.
But if this check is already in the IFU I can remove it.
As I always try to read a complete block (BLOCK_SIZE = 1024 * 48; // Each row in hex file is 46 + 2 (line feed))
The rest in your example is read the last time in loop. At while (count == BLOCK_SIZE) where we have only read the last byte it will break. At this point we have made a call to read from stream 11 times.
I have debugged the code but can find any “hole” in it.
But may have missed something.
If the last line in hex file is missing will IFU sense this and raise a exception?
When I load my application it’s loaded, flashed and restarted without any problem, but if there is no “complete” check of the hex file it may be a bigger problem for the firmware files as the may have start vector information at this point.
The built in CRC in system update is made for verifying your firmware and app is valid. Some customers needed this as an extra precaution step on power up. This is not what you need to check the validity of your files.
There is no way to do this and it is not needed anyway. When you send TEH new firmware to the device through IFU it is only buffered in RAM, nothing is stored on the device, till you all flash. Meaning, the CRC is on the data on flash, the old firmware data.
Hi, not looking to change the original issue behind this thread, but can I ask what if any issues could arise from having a different tinybooter? I was planning on using IFU to update all my client’s EMX applications out on site from 188.8.131.52 -> 184.108.40.206. I have tested in the office and haven’t come across any problems.