Problemas al programar el microcontrolador LPC1343 en Ubuntu

Cuando copio un binario que funciona en un lpc1343 al dispositivo USB montado que representa el flash lpc1343, el archivo binario cambia y no funciona. Hacer lo mismo con el flash montado vía usb en Windows o Mac OS no tiene el mismo problema. ¿Cuál podría ser el problema y cómo se puede solucionar?

Editar: el problema parece ser la implementación de vfat en Linux, que parece tener un prefijo 0 antes del archivo que se va a transferir.

¿Estás 100% seguro de que es el mismo binario? ¿Cómo se copia exactamente el archivo en Ubuntu? ¿Has probado diferentes formas de copiar?
Sí, estoy seguro. Encontré el problema. Parece ser la forma en que Linux trata con vfat. Parece prefijar 0 antes de enviar el archivo que muchos dispositivos USB ignoran, pero aún es incompatible con el estándar.
Cuando dice que antepone 0 antes de enviar el archivo, ¿qué quiere decir? ¿Cómo lo sabes? ¿Está copiando un binario que funcione (que puede hacer funcionar en Windows/Mac) o está copiando un binario creado en su máquina Ubuntu? ¿Qué pasos sigues para copiar el binario? ¿Qué configuraciones tienes en fstab para el dispositivo usb? ¿Lo haces como root o como usuario sin privilegios? ¿Haces clic y arrastras, o estás copiando en la línea de comando? Si hay un problema con Ubuntu, ejecutables y dispositivos vfat, ¿por qué no es más conocido? ¿Crees que hay un estándar publicado para vfat?
Hemos enviado el mismo binario desde Windows, Mac OS y varias máquinas Linux. Hemos copiado desde la línea de comandos, copiado y pegado en el navegador de archivos, así como arrastrar y soltar. La razón por la que no es más conocido es porque la mayoría de los dispositivos USB toleran estos 0 (supongo que simplemente los descartan), sin embargo, el vfat implementado en el lpc1343 no lo hace (que es de acuerdo con el estándar). Al usar mcopy de mtools en unix en el dispositivo de bloques, en lugar de montar el vfat, el archivo se transfiere correctamente.
¿Quiere decir que el binario se rellena con un número no especificado de 0 s al principio? Parece que tiene una solución funcional para este problema, ¿por qué no publica una respuesta más detallada a continuación para permitir que otros compartan este conocimiento más fácilmente? Al seguir el enlace en su perfil, veo que tiene más de 10k de puntos de repetición de varios sitios de SE, por lo que ya conoce el ejercicio.
Creo que está relleno con 1024 0s. Al menos me lo han dicho. Escribiré una respuesta aquí con la solución cuando tenga tiempo.
¿Tener tiempo? :PI estaría muy interesado en la solución. Gracias.
No creo que Linux esté haciendo nada que esté fuera de la especificación de almacenamiento masivo USB; es realmente culpa del gestor de arranque simplista del chip. Al menos esa fue la conclusión a la que llegué cuando analicé el mismo problema hace uno o dos años.

Respuestas (2)

puede resolver esto usando mtools(utilidades fat de espacio de usuario):

mdel -i /dev/sdf ::/firmware.bin
mcopy -i /dev/sdf new_firmware.bin ::/
Así es como siempre lo he hecho. Es una buena solución para un gestor de arranque mal escrito.
¿Qué hacen la opción -i y ::?
"La letra de unidad: (dos puntos) tiene un significado especial. Se usa para acceder a archivos de imagen que se especifican directamente en la línea de comando usando las opciones -i". Puede leer sobre ellos en el manual aquí .

Otra solución es usar el script de python simpleflash del repositorio r0ket[1] git. Escribe directamente en el dispositivo en lugar de usar "cp". Tuve que modificar el tamaño en la línea 20 de 32 a 64 para trabajar con una placa de prueba LPC1347...

El guión se puede encontrar aquí .

[1] placa LPC1343