Autor Tema: Consulta sobre Placa de desarrollo de Rdss utilización del bootloader (LPC1343)  (Leído 5597 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado guiyie

  • PIC10
  • *
  • Mensajes: 3
Hola a todos,
Soy nuevo en el tema de ARM, estoy haciendo un desarrollo utilizando el kit de prueba desarrollado por la empresa Rdss.
Mi consulta es si alguien ha desarrollado algo con esta placa y me puede ayudar a saber como grabar utilizando el bootloader. Puesto que sigo las instrucciones del fabricante y sin embargo mi programa no se graba, y al apretar el botón de reset vuelve el firmware anterior.

PD: el programa que utilizo es el codelite y utilizo un ejemplo que lo dan en esta pagina, siendo mas especifico trato de hacer titilar un led.
http://www.microbuilder.eu/projects/LPC1343ReferenceDesign/LPC1343CodeLiteTutorial.aspx

Si me podrian ayudar estoy en un pozo. Desde ya muchas gracias.

Desconectado BrunoF

  • Administrador
  • DsPIC30
  • *******
  • Mensajes: 3865
Hola.

Si te refieres al bootloader que trae el LPC1343 de fábrica, pues te recomiendo que utilices el bootlooader USB, que genera un USB mass-storage device y te permite realizar drag & drop del firmware desde tu sistema operativo.

Para lograrlo creo recordar que intervienen 4 pines: 2 para el USB, 1 para seleccionar si el boot es desde puerto serie o USB y el otro para meterlo en modo bootloader.

Espero te sea de ayuda, no he trabajado con kits de esa empresa.

Saludos.
"All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value."  -- Carl Sagan

Sólo responderé a mensajes personales, por asuntos personales. El resto de las consultas DEBEN ser escritas en el foro público. Gracias.

Desconectado guiyie

  • PIC10
  • *
  • Mensajes: 3
Hola.

Si te refieres al bootloader que trae el LPC1343 de fábrica, pues te recomiendo que utilices el bootlooader USB, que genera un USB mass-storage device y te permite realizar drag & drop del firmware desde tu sistema operativo.

Para lograrlo creo recordar que intervienen 4 pines: 2 para el USB, 1 para seleccionar si el boot es desde puerto serie o USB y el otro para meterlo en modo bootloader.

Espero te sea de ayuda, no he trabajado con kits de esa empresa.

Saludos.

Gracias, pero ya lo utilizo el problema es que lo cargo al programa y parece que no me lo toma, y esto lo hago siguiendo las instrucciones que me da el fabricante pero parece no funcionar, con respecto a soft tome un ejemplo hecho por la pagina que pase anteriormente y solo modifique para que se prendan y apaguen los leds que estan mapeados en los puertos GPIO de esta placa.

Desconectado RdSS

  • PIC10
  • *
  • Mensajes: 1
    • RdSS Electrónica
Hola,

Soy Sebastián, soporte de RdSS Electrónica. ¿Podrías confirmarme si es que cuando grabas un programa nuevo entra siempre al modo bootloader (queda encendido el led de azul de USB) y lo reconoce como un dispositivo de almacenamiento masivo mostrando el archivo firmware.bin? Por lo que veo sea un problema de CRC. Los micros LPC1XXX son muy exquisitos en cuanto al chequeo del CRC del archivo con el que se van a grabar. Aparentemente el CRC calculado y colocado tanto por los compiladores Keil como GCC, para generar el .bin (el CRC sólo se usa en esta extensión), son calculados "mal" según NXP y deben ser recalculados correctamente antes de ser grabados en el microcontrolador. Por ello, luego de generar su .bin normalmente, debe recalcular y corregir el CRC del archivo .bin. Esto se hace con un programa llamado lpcrc.exe, que está incluido en el CD que acompaña al producto (buscalo en la sección de arcihvos de los proyectos para MicroBuilder).

Si es eso es muy sencillo de solucionar:

Si utilizas Keil uVision 4:

Ir al menú "Flash", luego en la opción "Configure Flash Tools...". Una vez allí seleccionar a la solapa "User", y en ella buscar (en la zona inferior de la pantalla) y tildar las opciones dentro del marco "Run User Programs After Build/Rebuild" escribiendo los siguientes comandos (tenga en cuenta en su caso las rutas para los comandos):

Run #1:
C:\Keil\ARM\BIN40\fromelf.exe --bin -o ./obj/firmware.bin ./obj/blinky.axf

Run #2:
C:\Keil\ARM\BIN40\lpcrc.exe ./obj/firmware.bin

Si utilizas CodeLite:

Debes configurar el Makefile para que al finalizar la compilación ejecute el programa lpcrc, pasándole como argumento la ruta donde esta el archivo .bin que generaste. Allí se recalculará el CRC y se guardará bien en el archivo .bin. Podés ver como se hace la modificación del Makefile tomando como base el archivo que esta en el ejemplo para MicroBuilder (ejemplo que viene precargado en la placa).

Para que te sirva de referencia, siempre que se grabe un programa "corrupto", con mal cálculo de CRC, o que no cumpla con alguna trama de inicialización básica del archivo (.bin ficticio), el microcontrolador NO va a ejecutar lo almacenado sino que va a directamente inicializar el bootloader (en tu caso el USB ya que está con el cable conectado a la PC). Esto es lo que le está ocurriendo cuando comentas de que la placa no reconoce el soft y le vuelve a aparecer en la PC el dispositivo de almacenamiento masivo (esperando de que le grabe algo válido). Todas estas salvedades son aplicables únicamente a la generación y grabación de los archivos .bin. Si trabajas con .hex no hay que tener ningún reparo.

Espero esto sirva para solucionar tu problema sino esperamos tu feedback para continuar indagando porque no logras grabarlo. Así también te recordamos que podés comunicarte por teléfono o mail con nuestro soporte.

Saludos,

Sebastián
RdSS Electrónica - Kits de desarrollo para electrónica microcontrolada

Desconectado guiyie

  • PIC10
  • *
  • Mensajes: 3
Hola,

Soy Sebastián, soporte de RdSS Electrónica. ¿Podrías confirmarme si es que cuando grabas un programa nuevo entra siempre al modo bootloader (queda encendido el led de azul de USB) y lo reconoce como un dispositivo de almacenamiento masivo mostrando el archivo firmware.bin? Por lo que veo sea un problema de CRC. Los micros LPC1XXX son muy exquisitos en cuanto al chequeo del CRC del archivo con el que se van a grabar. Aparentemente el CRC calculado y colocado tanto por los compiladores Keil como GCC, para generar el .bin (el CRC sólo se usa en esta extensión), son calculados "mal" según NXP y deben ser recalculados correctamente antes de ser grabados en el microcontrolador. Por ello, luego de generar su .bin normalmente, debe recalcular y corregir el CRC del archivo .bin. Esto se hace con un programa llamado lpcrc.exe, que está incluido en el CD que acompaña al producto (buscalo en la sección de arcihvos de los proyectos para MicroBuilder).

Si es eso es muy sencillo de solucionar:

Si utilizas Keil uVision 4:

Ir al menú "Flash", luego en la opción "Configure Flash Tools...". Una vez allí seleccionar a la solapa "User", y en ella buscar (en la zona inferior de la pantalla) y tildar las opciones dentro del marco "Run User Programs After Build/Rebuild" escribiendo los siguientes comandos (tenga en cuenta en su caso las rutas para los comandos):

Run #1:
C:\Keil\ARM\BIN40\fromelf.exe --bin -o ./obj/firmware.bin ./obj/blinky.axf

Run #2:
C:\Keil\ARM\BIN40\lpcrc.exe ./obj/firmware.bin

Si utilizas CodeLite:

Debes configurar el Makefile para que al finalizar la compilación ejecute el programa lpcrc, pasándole como argumento la ruta donde esta el archivo .bin que generaste. Allí se recalculará el CRC y se guardará bien en el archivo .bin. Podés ver como se hace la modificación del Makefile tomando como base el archivo que esta en el ejemplo para MicroBuilder (ejemplo que viene precargado en la placa).

Para que te sirva de referencia, siempre que se grabe un programa "corrupto", con mal cálculo de CRC, o que no cumpla con alguna trama de inicialización básica del archivo (.bin ficticio), el microcontrolador NO va a ejecutar lo almacenado sino que va a directamente inicializar el bootloader (en tu caso el USB ya que está con el cable conectado a la PC). Esto es lo que le está ocurriendo cuando comentas de que la placa no reconoce el soft y le vuelve a aparecer en la PC el dispositivo de almacenamiento masivo (esperando de que le grabe algo válido). Todas estas salvedades son aplicables únicamente a la generación y grabación de los archivos .bin. Si trabajas con .hex no hay que tener ningún reparo.

Espero esto sirva para solucionar tu problema sino esperamos tu feedback para continuar indagando porque no logras grabarlo. Así también te recordamos que podés comunicarte por teléfono o mail con nuestro soporte.

Saludos,

Sebastián

Gracias Sebastián, hice lo del lpcrc y me funciono al parecer ese era el problema. Ahora me surge una nueva duda, yo comence a probar esto con un ejemplo y todo lo que hice fue modificar el programa y el .bin me aparecia solo. Cuando comienzo un nuevo workspace en el codelite esto ya no sucede. Mi pregunta sería ¿Cómo genero el .bin tengo que tocar algo o solo el compilador me lo genera? El programa que utilizo es el codelite. Tengo que decirte que estoy muy conforme con el producto.

Desconectado fantabuloso

  • PIC10
  • *
  • Mensajes: 24
Te aso el link que me dejo Suky, que aca te explica muchas mas cosas, y esto te va a servir, saludos

http://www.ucontrol.com.ar/forosmf/arm/%28aporte%29-comenzando-con-lpc-%28lpc1343%29/