error de flash en atmel sam

[juaperser1]

NEcesito ayuda con esto, no consigo hacer que funcione, la escritura de la flash solo parece funcionar bien a partir de la direccion 0x0 o valores muy bajos, pero me borra el programa principal, por lo tanto el programa de estar en esa zona.

Ademas no me deja guardar en la sección flash 0x00400000, esa zona de memoria no se puede ni desbloquear ni borrar ni guardar, por culpa de las condiciones dentro de las funciones, que por cierto si se borran no funciona igualmente.

he probado a reservar memoria con la instruccion keep pero el compilador me ignora los atributos:

Sin título.png
(9.43 kB, 581x283 - visto 429 veces)

lo raro es que en el Linker script "nunca he profuncidado nunca aquí"  tenemos lo siguiente:

/* Memory Spaces Definitions */
MEMORY
{
    rom (rx)    : ORIGIN = 0x00400000, LENGTH = 0x00080000 /* rom, 524288K */
    ram (rwx)   : ORIGIN = 0x20400000, LENGTH = 0x00040000 /* ram, 262144K */
}

/* The stack size used by the application. NOTE: you need to adjust according to your application. */
STACK_SIZE = DEFINED(STACK_SIZE) ? STACK_SIZE : DEFINED(__stack_size__) ? __stack_size__ : 0x0400;

/* The heapsize used by the application. NOTE: you need to adjust according to your application. */
HEAP_SIZE = DEFINED(HEAP_SIZE) ? HEAP_SIZE : DEFINED(__heap_size__) ? __heap_size__ : 0x0200;

dice que la rom esta en la direccion 0x00400000 cuando se supone que esta en 00800000:

alguien se le ocurre la solución o que esta pasando, yo me estoy quedando sin ideas.

[juaperser1]

Haciendo ingenieria inversa a las librerias y condiciones que me iba encontrando a en la depuración he sacado que la maxima memoria accesibe es la direccion 0x80000=512MB de la flash que dice que tiene (como maxima), por lo tanto he restado, y las regiones de borrado y escritura son de 512X16=8192 (también ingeniería inversa). Así que desde la dirección 7C000 puedo escribir mis 512 de la pagina.

Parece que así funciona, ahora la explicación de por que la direccion de la flash es distinta en la hoja de datos, ni idea, si alguien sabe por que que lo comente.

un saludo

[KILLERJC]

El linker toma la Flash y la ROM ambas como "ROM" en el linker, de todas formas el linker no es el problema. Ya que sino tendrias un problema al compilar/linkear tu programa.

Haciendo ingenieria inversa a las librerias y condiciones que me iba encontrando a en la depuración he sacado que la maxima memoria accesibe es la direccion 0x80000=512MB de la flash

Y esa es la maxima direccion que podes escribir. Ya que la ROM es otra cosa. No es programable

Internal ROM
The SAM S70 embeds an Internal ROM for the SAM Boot Assistant (SAM-BA®), In Application Programming functions (IAP) and Fast Flash Programming Interface (FFPI).
At any time, the ROM is mapped at address 0x0080 0000

[juaperser1]

Y esa es la maxima direccion que podes escribir. Ya que la ROM es otra cosa. No es programable

Esa es la cosa, que la rom empieza en el 0x800000 no en la 0x80000 (fijate en los ceros).

Internal ROM
The SAM S70 embeds an Internal ROM for the SAM Boot Assistant (SAM-BA®), In Application Programming functions (IAP) and Fast Flash Programming Interface (FFPI).
At any time, the ROM is mapped at address 0x0080 0000

Ademas, en el linker script te dice que la rom empieza en la 0x00400000:

rom (rx)    : ORIGIN = 0x00400000, LENGTH = 0x00080000 /* rom, 524288K */

Cuando no es así, la rom empieza en la 0x00800000, en la 0x00400000 empieza la flash, la cual es inaccesible, ya que solo puedes acceder hasta la direccion 0x80000(con 4 ceros) te quedas dentro de la zona de ITCM, osea que algo esta mal, muy mal, no se para que ponen esa parte de flash si la toman como rom en el linker para que no puedas grabar nada ahi

[planeta9999]

Ufff, yo los SAM los descarté pronto, hace ya bastante tiempo. No me gustó nada el entorno de desarrollo, ni tampoco los asistentes para crear el programa, ni lo pobre que es el conjunto de fuentes de ejemplo que dan con el ASF. Parece todo como dejado caer de cualquier manera, y sin ningún tipo de actualización para mejorar el producto, desde hace tiempo.

El micro es muy barato, pero el resto es una castaña. Muy diferente es con los RT1020 de NXP, una maravilla en todos los aspectos, además son mucho más potentes (Cortex M7 a 500Mhz), muy baratos y puedes conectar Flash y SDRAM externa con mucha más capacidad que los micros que la integran dentro. Tengo ahora un diseño que instalará una SDRAM de 512 Megabit y una QSPI de 32 ó 64 Mbit para el arranque, luego se copia el programa él solo a la SDRAM y se ejecuta todo desde allí a la velocidad del rayo.

El SDK de los RT es fantástico, tienes fuentes de ejemplo para todo, y muy bien documentados. MCUXpresso es también genial, con asistentes para configurar Puertos, Reloj y Periféricos, que no tiene nada que envidiarle al Cubemx de ST. Es mucho mejor porque integra la importación de fuentes de ejemplo desde el SDK, cosa que no ofrece ST, en eso ST patina dejando al usuario a su suerte para que cree los programas por su cuenta, sin un miserable programa de ejemplo en el que inspirarte para crear el tuyo. Para mi, una buena librería de programas modelo de ejemplo es fundamental, como tiene Arduino, pero con NXP está mejor organizado.

[juaperser1]

Yo lo he usado en este proyecto, pero no los volveré a utilizar a no se que no tenga opción, es increible la cantidad de cosas que están mal o inacabadas, el driver del RTC no te permite leer los registros del día de la semana, ni configurar el formato de 12h o 24h he tenido que modificar los fuentes para añadirle las funciones , el buffer circular de la recepción de la uart se pisa con el de envio por que tiene la interrupciones cruzadas, el periférico del RTT no tiene driver, he tendido que crearlo yo, las interrupciones externas del puerto D no funcionan, ahora la memoria flash estas cosas...fatal todo, raro es lo que funciona bien, o la primera. En un seminario de microchip nos dijeron que iban a quitarse de enmedio todas las herramientas de atmel, que en dos años no iba a estar ni el atmel studio ni las herramientas de programación, pero de ahí a que ocurran estas cosas.... pff no recomiendo a nadie que utilice estos micros, al menos hasta que microchip los integre en su sistema y empiecen a darle soporte, y aun así, yo ya no los volveré a usar, al igual que los PIC.

Como están los RT en cuanto a disponibles? ¿les pasa lo mismo que a los kinetis? todo el entorno y librerías como comentas es mas o menos como el de kinetis no? con que herramienta los programas.

Yo estoy testeando para nuevos proyectos médicos los renesas (synergy) y los texas instrumens (C2000 y hercules), la calidad y fiabilidad de estos micros no tienen comparación, para pasar las normativas son los mejores ya que muchas librerías ya tienen varias certificaciones, pero la calidad se paga, son bastante caros.

[planeta9999]

Los RT1020, ahora mismo están disponibles en LQFP100 en Mouser y otros distribuidores, el LQFP144 estará para finales de año. Tengo ya en fase de montaje dos prototipos con LQFP100, pero para poder usar la SDRAM externa necesito un LQFP144, y como no están aún, lo voy a sacar de una de las placas de evaluación que compré, que estas si que montan uno de 144 pines.

De momento no hay problemas de stock, incluso creo que NXP ya da samples gratuitos. El entorno de trabajo gratuito es el mismo en los Kinetis,  LPC e i.MX, se usa MCUXpresso con SDK bajados de la web de NXP, salvo los LPC que están integrados en MCUXpresso (no necesitan SDK).

Por ahora, voy a confiar en los i.MX, son muy baratos, muy potentes, y todo lo que he visto y probado me ha gustado mucho, mi idea es migrar todo lo que tengo con Kinetis a i.MX RT1020. Lo que en principio parecía un problema, que es necesitar flash externa, es justo lo contrario, es una gran ventaja, porque puedes montar Hyperflash o QSPI con mucha más memoria de la que te puede ofrecer cualquier otro micro que la lleve integrada. En la compilación, puedes configurar para que compile una imagen encriptada del programa, de esa manera aunque esté en memoria externa no te lo pueden fusilar, porque se carga y desencripta internamente en tiempo de ejecución.

Tengo aquí compradas varias QSPI de 32 y 64 Mbit, y SDRAM de 256Mbit y 512Mbit para ir probando. Se puede configurar para que arranque desde SD, Flash paralelo, QSPI o SPI Octal, que me han contado que vuela. Tienes la posibilidad de poder conectar una SDRAM externa con un montón de megas, y puedes configurar para que compile con arranque de RAM, que hace que al iniciar desde SD, QSPI o Hyperflash se copie automaticamente el programa a la SDRAM y se ejecute desde allí, una maravilla.

Por ahora no le encuentro ningún defecto, ya veremos cuando empiece los desarrollos en serio, ahora estoy leyendo mucha documentación, principalmente el Manual de Referencia y mirando los fuentes de ejemplo que trae el SDK. Ya hice acopio de material y tengo los PCB para montar los prototipos.

[juaperser1]

Entonces de momento no me sirven, donde trabajo necesitamos un buen stock de lo contrario podemos tener problemas, precisamente los kinetis los tuve que descartar por eso mismo (aunque no se que es peor con el atmel este)

Así que para testear los RT esperare hasta que hasta que se comercialicen normalmente, por que aunque me sirvieran ahora, no podría usarlos.

un saludo

[planeta9999]

No hay ningún problema de stock. LQFP100 está disponible, y LQFP144 aún no se comercializa, lo liberan a final de año.

[juaperser1]

a pensaba que ninguno se estaba comercializando mas alla de las muestras o poco mas.

que herramienta usas para depurar?

[planeta9999]

a pensaba que ninguno se estaba comercializando mas alla de las muestras o poco mas.

que herramienta usas para depurar?

De LQFP100 puedes pedir muestras gratuitas a NXP, yo hace un rato he pedido de MK66 que son los que sigo usando en lo que monto para clientes,  y los RT1020 también estaban disponibles para samples. De RT1020 tengo de sobra los que compré a Digikey y algunos más que compré más tarde a Mouser.

Lo trabajo todo con MCUXpresso, puedes usar Jlink o Multilink, con ambos funciona igual para Programar y Depurar.

Lo interesante es usar una salida por COM virtual para sacar variables y textos en tiempo de ejecución a una ventana tipo hiperterminal usado el printf, como lo hace Arduino, es más interesante que los breakpoints y el paso a paso. Yo desde que usé Arduino, me acostumbré a depurar de esa manera, y es mucho mejor, ya no lo cambio por el viejo sistema de puntos de ruptura.

Jlink te crea un COM virtual, Multilink no lo se, el que más estoy usando es Jlink V9.

Otra cosa interesante es usar estos conectores de programación para JTAG o SWD, no necesitas conector en la placa, solo poner la huella en el PCB, el conector se lastra con unas pestañas de plástico y unos pines con amortiguador tocan sobre los pads del PCB. Los tengo puestos en un par de prototipos y van de fábula.