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
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.
View all questions in Keil forum