7
\$\begingroup\$

When I copy a binary that works on a lpc1343 to the mounted usb-device representing the lpc1343 flash, the binary file is changed and does not work. Doing the same with the flash mounted via usb on Windows or Mac OS does not have the same problem. What could be the problem, and how can it be fixed?

Edit: The problem seems to be the vfat implementation in Linux which seems to prefix 0s before the file to be transferred.

\$\endgroup\$
8
  • \$\begingroup\$ Are you 100% sure it's the same binary? How exactly do you copy the file under Ubuntu? Have you tried different ways of copying? \$\endgroup\$ Oct 2, 2010 at 15:42
  • \$\begingroup\$ Yes I am sure. I found the problem. It seems to be the way linux deals with vfat. It seems to prefix 0s before sending the file which are ignored by a lot of usb devices, but still is incompatible to the standard. \$\endgroup\$
    – txwikinger
    Oct 4, 2010 at 4:23
  • \$\begingroup\$ When you say it prefixes 0s before sending the file what do you mean? How do you know? Are you copying a working binary (that you can get working on a windows/mac) or are you copying a binary created on your Ubuntu machine? What steps do you go through to copy the binary across? What settings do you have in fstab for the usb-device? Are you doing it as root, or as a non-privileged user? Do you click and drag, or are you copying at the command line? If there is a problem with Ubuntu, executables and vfat devices why is it not more commonly known? You think there's a published standard for vfat? \$\endgroup\$
    – Amos
    Oct 4, 2010 at 22:25
  • \$\begingroup\$ We have send the same binary from a windows, a mac os, and a several linux machines. We have copied from command line, copy and past in file browser as well as drag and drop. The reason why it is not more commonly known, is because most usb devices tolerate these 0s (I guess just drop them), however, the vfat implemented on the lpc1343 does not (which is according to standard). When using mcopy from mtools in unix on the block device, instead of mounting the vfat, the file is transferred correctly. \$\endgroup\$
    – txwikinger
    Oct 5, 2010 at 3:21
  • 1
    \$\begingroup\$ Do you mean that the binary is padded with an unspecified number of 0 s at the start? You appear to have a working solution to this problem, why not post a more detailed answer below to allow others to share this knowledge more easily. I see from following the link in your profile that you've got over 10k of rep points from various SE sites so you know the drill by now. \$\endgroup\$
    – Amos
    Oct 5, 2010 at 21:57

2 Answers 2

3
\$\begingroup\$

you can solve this by using mtools (userspace fat utilities):

mdel -i /dev/sdf ::/firmware.bin
mcopy -i /dev/sdf new_firmware.bin ::/
\$\endgroup\$
3
  • \$\begingroup\$ This is how I've always done it. It's a good solution to a poorly written bootloader. \$\endgroup\$
    – Jim Paris
    Oct 11, 2012 at 21:50
  • \$\begingroup\$ what does the -i option and the :: do ? \$\endgroup\$ May 27, 2014 at 13:36
  • \$\begingroup\$ "The drive letter : (colon) has a special meaning. It is used to access image files which are directly specified on the command line using the -i options". You can read about them in manual here. \$\endgroup\$ May 27, 2014 at 17:36
2
\$\begingroup\$

Another solution is to use the simpleflash python script from the r0ket[1] git repository. It writes directly to the device instead of using "cp". I had to modify the size at line 20 from 32 to 64 to work with a LPC1347 test board...

The script can be found here.

[1] LPC1343 board

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.