Hello
I use USB bootloader for NXP uC for firmware upload. But now I have problem with firmware upload (*.bin) from Android PC to uC NXP LPC1768. The point is that the android PC find the uC memory and I can transfer the firmware. But after reset the uC doesn’t accept firmware. The whole firmware upload process works on windows PC without any problems. Are there any compatibility problems, or settings to overcome this problem on Android PC?
I’m using: uVision 4.53 for programming and *.bin generation Android tablet PC: Galaxy Tab 10.1 for firmware upload
Best regards
"The firmware was not equal anymore. It was changed after transfer from Android."
And how did that happen? Did this Android have a problem downloading for the interwebs, or from an email attachment? If the image create by Keil is valid, the question becomes how/why Android managed to screw it up. Hence Per asked about the nature of the corruption, as it might suggest a cause.
Perhaps you should have packaged the firmware in a manner which protects, and confirms, it's integrity.
I made some file compare (CompareIt! 4.2).
First compared file: transferred to uC from windows PC and works. The file was copied back to PC from uC for analysis.
Second compared file: transferred to uC from Android tablet, non working. The file was copied back to PC from uC for analysis.
Analysis results: Second file was drastically changed. The hex viewer shows some changes from address 0x00000400 to 0x00000C00. There was also some additional code inserted from 0x00000C00 to 0x00001000. So, this file contains additional nonsense code.
This happens only by file transfer to uC via USB. I have randomly copied the file on the Android tablet and then back to windows PC. The file was not changed.
Strange, when I transfer the file from Win PC to uC, and then copy file from uC back to Android tablet the file is OK. It seems that the problem is only in USB transfer from Android to uC. The transfer from uC to Android tablet is OK.
The answer from NXP support:
The tiny FAT file system emulation in the bootcode uses a fixed translation from FAT cluster number to flash address. Once the old firmware has been deleted in the file browser (Explorer) on the host, all clusters are available for following write operations. Windows seems to use them sequentially starting at the first available cluster. However, Linux seems to start at the second cluster, and this leads to the code ending up at the wrong location (here: 1 KB shifted, since a cluster contains two file system sectors of 512 bytes).
Both Windows and Linux do it perfectly right, because they can use clusters in any sequency they like. However, since the bootcode is translating the cluster no. directly into Flash sector no., it may not working with different OS.
I will test it with Linux PC if the transfer works, like mentioned from NXP support. I will be grateful if someone will solve this problem on Android. The firmware transfer from cheap tablet PC is good solution for servicemen.
"Strange, when I transfer the file from Win PC to uC, and then copy file from uC back to Android tablet the file is OK."
What is strange?
If the issue is with decided allocations, it doesn't affect reads. When reading, the reader don't have any options but reading the cluster chain in the order it has been specified.