• State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 22 subscribers
  • Views 3083 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firmware transfer *bin from Android to uC

Franc Hanzic

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

Parents
  • 0 in reply to Clive Unspecified

    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.

Reply
  • 0 in reply to Clive Unspecified

    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.

Children
  • 0 in reply to Franc Hanzic

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