Firmware transfer *bin from Android to uC

"Are there any compatibility problems, or settings to overcome this problem on Android PC?"

Did you even remember to tell what program you us on that android tablet? It is irrelevant what tools you use to generate the binary file on your PC, when your issue is the actual transfer of the binary to the device, using a completely different (not mentioned) program.

Next thing - that boot loader run in LPC1768 must place the received binary somewhere. Have you used any other interface (like FlashMagic with UART) to check if any data from your binary have been stored in the LPC1768?

There are no extra programs on Android tablet. The *.bin file is copied from windows PC to Android tablet via WiFi, so there are no additional software. The PC detects uC as USB flash drive and I simply copy the firmware on it.
There is no problem in USB bootloader. I only see the problem on Android OS because the whole process works on Win PC.

That seems totally irrelevant since your original post wasn't about transfer of bin file from PC to android, but claimed "from Android PC to uC NXP LPC1768".

So what do you do to transfer that binary from the tablet to the device that has the LPC1768?

Sorry for misunderstanding. Please forget about transferring from Win PC to Android PC, this works OK.
The problem is pointed in firmware transfer to the uC from Android OS.
How to transfer firmware from OS to uC – simply with file copy / paste. Like the file copy from PC to USB memory stick.

But you have already written "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.

So that would imply that you already have something on the tablet that accesses your microcontroller and sends a binary.

So - if file explorer is now to transfer the bin file to your microcontroller, have you then done what I did write earlier: Used FlashMagic or similar and checked exactly what contents your microcontroller have actually received and saved?

Debugging is the route to go. You can't stare your chip to submission.

The firmware is loaded in uC successfully. The bootloader starts user code but it seems that the user code is changed when using Android OS. The uC doesn’t work with loaded firmware. I have copied firmware from uC back to Win PC. Checked both firmware transfer versions (win OS, Android OS). The firmware was not equal anymore. It was changed after transfer from Android. So, I’m curious if someone has successfully transferred the firmware from Android to uC, using USB bootloader.

"The firmware is loaded in uC successfully."
"[...] but it seems that the user code is changed when using Android OS."

The above two statements are opposites. No transfer that damages the transmitted file can ever be classified as "successful".

So - what was the result of your comparison of the files? How did they differ? Where did they differ? Was there a change in file size? Was there some ASCII file conversion, converting end-of-line characters in the belief that it was a text-file transfer? Was random bytes damaged? And have you verified if the difference was within the used range of the binary, or if the changes was in bytes after the file was expected to have ended?

If you make the transfer twice in a row - is the resulting data in the microcontroller identical or different, i.e. is the garbling random or repeatable?

And note that an Android device have access to more than one application with file-transfer capabilities. Have you tested if it matters what application you have used?

You make it sound like this world just have "Android". The Android operating system exists in a huge number of different versions. And each hardware manufacturer packages their devices with different application programs. So "So, I’m curious if someone has successfully transferred the firmware from Android to uC, using USB bootloader." is normally a too general question to be applicable. If a specific HTC phone with a specific set of updates is able to upload a binary ok, it doesn't tell much about the results for a Samsung tablet with completely different Android version and installed apps and system tools.

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.