Firmware transfer *bin from Android to uC

So your original post was meaningless. The only thing you wanted to know was "yes" or "no" to the question "have anyone managed a file transfer from Android" - without telling you how you can duplicate it if the answer was "yes"...

So why waste time with Keil version then, instead of explicitly saying that the above is the only thing you have time to be interested in?

So your original post was meaningless. The only thing you wanted to know was "yes" or "no" to the question "have anyone managed a file transfer from Android" - without telling you how you can duplicate it if the answer was "yes"...

So why waste time with Keil version then, instead of explicitly saying that the above is the only thing you have time to be interested in?

I don’t understand your point of meaningless. All is based from Keil uVision. The *.bin file is generated from uVision. I have awaited answer like, you have to change configuration in bin generation like this or simply this bin transfer works only on windows OS.
I have to know if this is problem within Android OS or I do something wrong.
I didn’t expect that this problem is new on Keil forum.

If your problem is that the file breaks on final transfer from Android tablet to your uC, then the file generation step using Keil is irrelevant.

A file transfer program in an Android device don't care if you used Keil or IAR or any other program to generate that bin file. It cares even less what version you have of the Keil tools, or what compilation options you used. A bin file by definition have to be fully binary - so be allowed to make use of all values between 0 and 255 for each individual byte. So a bin file must always be handled by programs that are binary-safe. It is only if the boot loader used in the uc supports multiple file formats (such as binary + Intel hex) that different build options in the Keil tools can matter.

An analysis of what where/how the file broke during the transfer could give an indication if the software in the Android did some specific error, or if there are random transfer errors involved. Have you even verified that the transfer PC->Android is correct - does the file on the tablet have the same MD5 as the file you started with on the PC.

If you run your car full speed into a wall, it is irrelevant if you selected solid green or blue metallic paint. You will still break the car and likely yourself.

"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. It seems that the problem is only in USB transfer from Android to uC. The transfer from uC to Android tablet is OK.

"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.