Cargar datos en memoria Flash EDU-CIAA

[Santiago Aupi]

Buenas tardes, estoy trabajando con la EDU-CIAA NXP y necesito hacer uso del segundo banco flash que tiene. 

El micro LPC4337 cuenta con 2 bancos flash de 512KB cada uno, por la cantidad que voy a almacenar, aprox 500KB, si o sí necesito utilizar uno de esos bancos para guardar los datos. 

Para lograr esto agrego 

__RODATA(Flash2) al declarar la variable de datos con el objetivo de que sea escrita en la Flash 2. Este es el apodo que tiene el banco MFlashB512. 

El programa compila al ejecutar make all. Pero al utilizar make download para bajarlo a la placa me aparece el siguiente error.

Los warnings que marqué son los que me preocupan pues según el manual del LPC4337 en esas direcciones es donde están los bancos que se encuentran disponibles.

(Los copio por si cuesta leer con el fondo oscuro de Eclipse)

Warn : no flash bank found for address 1a080000

Warn : no flash bank found for address 1b080000

Estoy utilizando el firmware_v3. 

Miré el archivo /scripts/openocd/lpc4337.cfg y me encuentro conque dentro de ese archivo se llama al lpc4337_old.cfg. (No se llama al lpc4337_new.cfg porque no tengo el comando dap según entiendo).

En el lpc4337_old.cfg está declarado el banco flash A y aún así también me aparece el warning. Probé agregar estas lineas, que saqué del lpc4337_new.cfg

flash bank lpc4337.flasha lpc2000 0x1a000000 0x80000 0 0 lpc4337.m4 lpc4300 96000 calc_checksum
flash bank lpc4337.flashb lpc2000 0x1b000000 0x80000 0 0 lpc4337.m4 lpc4300 96000 calc_checksum

Pero sigue apareciendo el mismo warning. 

El Makefile que utilizo es el del firmware_v3. Probé ver si se solucionaba al agregar 

"flash write_image erase $< 0x1B000000 bin"

en la sección .download_flash pero no tuve éxito. Sin embargo si no hago esa modificación

el 2do warning no aparece, supongo que porque directamente ni intenta utilizar dicha región.

Cualquier consejo que me puedan brindar será de gran ayuda.

Saludos,

Santiago.-

[Santiago Aupi]

Resubo la imágen para mayor legibilidad.

Saludos,

Santiago.-

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/5eSR80MKTtU/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/def0bd6d-cf47-4cb8-a081-88c615298737n%40googlegroups.com.

[Carlos Ignacio Mancón]

Buen día,

No sé si voy a poder ayudar a resolver pero me impulsa la curiosidad sobre el problema.

Por lo que veo, los warnings son estrictamente correctos.

Me refiero con esto a que el mapa de memoria que adjuntas y que corroboré en el user manual, dice que a partir de 0x1A08_0000 y  0x1B08_0000 hay dos sectores de 0xF8_0000 de tamaño que son reservados y a los que no podes acceder.

A partir de lo anterior, hay que determinar por qué se está queriendo acceder a estos sectores. Sin analizarlo mucho, se me ocurren dos razones: 1. La sección de memoria está mal dimensionada, 2. La sección de memoria está mal ubicada.

Sugiero que revises el linker script o cualquier otro archivo de salida que permita indagar sobre cómo están definidos los bancos de memoria que querés usar/manipular.

Otra razón que se me ocurre ahora, y basada en mi ignorancia, es que en algún lado estén mal nombrados los sectores a utilizar y al no utilizar el segundo banco quiere allocar un tercero en las direcciones contiguas a los sectores definidos. En este caso explicaría por qué dice no encontrar un banco en  0x1*08_0000, pero no sé si esa es la lógica con la que trabaja.

Saludos!
Carlos

[Santiago Aupi]

Gracias por tu respuesta Carlos. 

Efectivamente el warning es correcto. Según la captura que subí tengo 524288 bytes para escribir, considerando que el banco flash A, por ejemplo, arranca en la dirección 0x1a000000, que quiera escribir en 0x1a080000 indica que está queriendo escribir allí la totalidad de los bytes. Cuando se supone que yo estoy haciendo uso de __RODATA(FlashB) para utilizar otra sección flash. La pregunta que no logro responder sería por qué ignora dicha instrucción. 

Los sectores de memoria a utilizar están bien nombrados, eso lo pude verificar. Pero coincido en que el problema debe andar con el linker script, actualmente estoy investigando por ese lado. -.-

Saludos!

Santiago.-

[Carlos Ignacio Mancón]

Buenas noches Santiago,

claramente estoy (muy) oxidado en el tema, pero en el sentido de mi mensaje anterior, tal vez el intercambio de mensajes te hace ver algo de otra manera y se te ocurre una idea de lo que pueda estar sucediendo.

Desempolvé un viejo proyecto. Yo uso MCUXpresso y el proyecto sería un managed linker script por parte del IDE, pero seguro que tenés las mismas definiciones salvo por la RAM externa que había definido para la CIAA-NXP:

Para hacer un poco de pie, fui al archivo donde tenía incluido "cr_section_macros.h" y puse arbitrariamente:

__RODATA(Flash2) uint8_t flash2data[0x40000] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};

compiló con el warning setting incorrect section attributes for .rodata.$Flash2 supongo que por no usar const para un RO y la salida del linker (-print-memory-usage) fue la siguiente:

Memory region         Used Size  Region Size  %age Used
      MFlashA512:      317528 B       512 KB     60.56%
      MFlashB512:        256 KB       512 KB     50.00%
        RamLoc32:       32152 B        32 KB     98.12%
        RamLoc40:         40 KB        40 KB    100.00%
        RamAHB32:         32 KB        32 KB    100.00%
        RamAHB16:          8 KB        16 KB     50.00%
    RamAHB_ETB16:          2 KB        16 KB     12.50%
         RAM_EXT:          0 GB         8 MB      0.00%

y consecuentemente en el *.map:

.text_Flash2    0x000000001b000000    0x40000
 FILL mask 0xff
 *(.text_Flash2*)
 *(.text_MFlashB512*)
 *(.text.$Flash2*)
 *(.text.$MFlashB512*)
 *(.rodata.$Flash2*)
 .rodata.$Flash2
                0x000000001b000000    0x40000 ./project/src/bsp/bsp.o
                0x000000001b000000                flash2data
 *(.rodata.$MFlashB512*)

Por alguna razón que me elude a esta hora y con lo fuera de tema que estoy, agregarle const hace desaparecer al símbolo... no lo mueve a otra sección simplemente deja de aparecer en el map. Será porque lo optimiza? Sin embargo le agregué un breve código que hace uso de flash2data como precaución...

Volviendo al tema, sería interesante ver qué salidas genera el gcc después de compilar. Ya sea el uso de secciones de memoria o buscar el/los símbolo/s que estás ubicando en Flash2 dentro del *.map. En una de esas da un indicio de qué puede estar pasando o descarta un problema en el binario.

Saludos! 

[Santiago Aupi]

Hola Gonzalo,

Muchas gracias por tomarte el tiempo. De hecho me haces darme cuenta que el error es más extraño de lo que pensaba.

Agregué ese flag para ver la memoria a la salida del linker luego de compilar y obtengo lo que esperaba: el contenido en la Flash2 (la B512)

Memory region         Used Size  Region Size  %age Used

      MFlashA512:      119400 B       512 KB     22.77%
      MFlashB512:      431424 B       512 KB     82.29%
        RamLoc32:       17736 B        32 KB     54.13%
        RamLoc40:       32000 B        40 KB     78.13%
        RamAHB32:          0 GB        32 KB      0.00%
        RamAHB16:          0 GB        16 KB      0.00%
    RamAHB_ETB16:          0 GB        16 KB      0.00%

Sin embargo cuando me dirijo al .map correspondiente me llevo una sorpresa, pueso sólo veo 69540b alocados en memoria. En el ejemplo tuyo tenés los 0x40000 que alocaste.

.text_Flash2    0x1b000000    0x69540
                0x1b000000                __core_m0app_START__ = .

 FILL mask 0xff
 *(.text_Flash2*)
 *(.text_MFlashB512*)
 *(.text.$Flash2*)
 *(.text.$MFlashB512*)
 *(.rodata.$Flash2*)
 .rodata.$Flash2

                0x1b000000    0x69540 examples/TPF_AUPI/TP/adc_test/out/examples/TPF_AUPI/TP/adc_test/src/bla_modelo.o
                0x1b000000                blaFonemas
 *(.rodata.$MFlashB512*)

Con lo cual el problema debe estar al hacer el download a la placa. Alguna pista por donde desentrañar el asunto? O cómo podría verificar si efectivamente se subieron los datos? Con el debuger de eclipse no logré ver la memoria. 

Gracias nuevamente, 

Saludos,

Santiago.-

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/610f2ad0-6d7c-4468-a22a-26a12c9fd1abn%40googlegroups.com.

[Carlos Ignacio Mancón]

Buen día Santiago,

ojo que  0x69540 == 431424d, así que el map te está mostrando en hexa el tamaño de blaFonemas. Además, como decís, está bien allocado en el inicio de la Flash2.

Para verificar podés iniciar una sesión de openOCD y mandarle los comandos a mano. Recomiendo que te fijes en la doc del openOCD.

• Verificar la descarga del programa: podes usar flash verify_image <filename> 0x1A000000 bin. (El make download hace flash write_image erase <filename> 0x1A000000 bin )

• Verificar el contenido de la Flash2: asumiendo que usas el .cfg con sufijo _new o que tenés el viejo pero con la declaración del banco 2 de memoria, podés hacer flash read_bank 1 flash2Bin.bin 0 0x69540 y debiera crearte un archivo raw/binario del contenido de ese banco. Después lo podés abrir con un editor hexa y verificar los datos. En esto último tené en cuenta el endianness.
  

Una sesión típica podría ser:

init
halt 0

flash banks (Para ver si están declarados ambos bancos)

flash read_bank 1 flash2Bin.bin 0 0x69540 (Asumiendo que los bancos están numerados 0 y 1)

Otras cuestiones a considerar:

1. Considerá utilizar una versión más nueva del openOCD para descartar que estés teniendo problemas por algo que no está bien implementado. El 0.10 alguna vez me arrojó error al debuggear y usé la 0.11 (La discusión está en este foro).
2. Fijate la explicación del comando  flash write_image. Cito: " Write the image filename to the current target’s flash bank(s). Only loadable sections from the image are written. A relocation offset may be specified, in which case it is added to the base address for each section in the image.  The flash bank to use is inferred from the address of each image section. ". Estaría bueno si se pudiera "ver cómo está armado" el .bin que se descarga. Supongo que idealmente los vectores estarían en la posición 0 y que blaFonemas comenzaría en  0x100_0000 lo que haría que el openOCD entienda que tiene que usar la Flash2 (potencialmente banco 1). Si el .bin estuviera... "todo contiguo" explicaría por qué trata de escribir en 0x1A08_0000.
3. No conozco la estructura interna del .bin. Consideraría que fuera lo más raw posible, como un clón del mapa de memoria en el área en cuestión. Pero en ese caso, blaFonemas iniciando en 0x100_0000 haría que el archivo tuviera un tamaño de como 17Mb, no?. Entiendo que este tipo de archivo u otro declararan "lugar y contenido" de cada "porción de programa". Una prueba a hacer en este sentido sería usar el formato .elf en vez de .bin.
4. Como solución de compromiso temporal, podés intentar ingresar los valores manualmente en la flash y no "a través del programa". Ahí tendrías que remar un poco y crear un binario con los datos de blaFonemas y grabarlo con flash write_bank, dejando que el programa se grabe en la Flash1 sin intentar cargar nada en la Flash2.

Actualmente estoy bastante convencido de que el formato .bin no sería el indicado para hacer lo que te proponés porque entiendo que no tiene ninguna estructura interna y está orientado a espacios de memoria contiguos, pero al no estar seguro, no lo digo como posible solución.

Espero que todo esto te genere alguna idea.

Saludos,

Carlos

[Santiago Aupi]

Hola Carlos,

Muchas gracias por tu ayuda. Actualmente verifiqué el contenido de una forma menos profesional (y está correcto), sin embargo la idea de exportarlo a binario para luego verificar es muy útil y lo haré para quitarme todas las dudas.

Nuevamente te agradezco por toda tu ayuda,

Un saludo!

Santiago.-

--

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/5eSR80MKTtU/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/38514f92-8199-4b68-a364-fedff24a9a65n%40googlegroups.com.