¿Cómo puede agregar datos a un segmento en la memoria flash un error en la sincronización de un programa?

Question

Tengo una aplicación incrustada en tiempo real con el ciclo principal en funcionamiento a 10 KHz. Se ejecuta en un TI TMS320C configurado para arrancar desde flash. Recientemente agregué una matriz inicializada a un archivo de origen y, de repente, la sincronización se ha estropeado (de una manera demasiado compleja para explicar bien, esencialmente una escritura de puerto serie ya no se completa a tiempo).

Las cosas sobre esto que me desconciertan:

• ni siquiera accedo a los nuevos datos , solo declaro una matriz inicializada.
• Es dependiente del tamaño: el problema solo aparece si la matriz tiene > 40 palabras.
• Sé que no estoy desbordando ningún segmento de datos en el mapa de enlace.
• No hay almacenamiento en caché de datos, por lo que no se debe a la interrupción de la consistencia del caché.

¿Alguna idea sobre cómo el simple hecho de aumentar el tamaño del segmento .cinit en flash puede afectar la sincronización de su código?

Información adicional:
Consideré que tal vez el código se había movido, pero está bien separado de los datos. Verifiqué a través del mapa de memoria que todos los segmentos de código tienen las mismas direcciones antes y después del error. También verifiqué que ninguno de los segmentos está lleno: las únicas direcciones que cambian en el mapa son unas pocas en la sección .cinit. Esa sección contiene valores de datos utilizados para inicializar variables en ram (como mi matriz). Nunca se debe acceder a él después de llamar a main ().

Answer 1

Después de más de un día mirando rastros y generando ensamblaje, creo que lo descubrí. El problema de la causa raíz resultó ser un problema de diseño que causó fallas solo si el ISR que activó la escritura del puerto serie chocó con una de mayor prioridad. El momento en que ocurrió fue que solo tomó agregar algunas instrucciones adicionales a un bucle para hacer que las dos interrupciones colisionen.

Entonces, la pregunta es: ¿cómo los datos adicionales almacenados en la memoria flash almacenan, pero no acceden, a la ejecución de instrucciones adicionales?

Parece que la respuesta está relacionada con las sugerencias de Frosty y Frederico, pero no de la misma manera. La nueva matriz mueve algunas variables existentes, pero no a través de los límites de la página o hacia regiones más lentas (en este tablero, los tiempos de acceso deben ser los mismos para todas las regiones). Pero sí cambia las compensaciones de algunas estructuras a las que se accede con frecuencia, lo que hace que el optimizador emita secuencias de instrucciones ligeramente diferentes para acceder a ellas. Una alineación de datos puede causar un bloqueo de la tubería de un ciclo, mientras que el otro no. Y esas pocas instrucciones cambiaron el tiempo lo suficiente como para exponer el problema subyacente.

Answer 2

Mis sospechas apuntarían a un cambio en la alineación entre sus datos / código y los medios / memoria subyacentes. Agregar a sus datos cambiaría las ubicaciones de la memoria en su montón (dependiendo del modelo de memoria) y podría poner su código a través de un límite de 'página' en el dispositivo flash, lo que causaría una latencia que no existía antes.

Answer 3

¿Quizás la nueva matriz asignada estáticamente empuja los datos existentes a regiones de memoria más lentas, lo que hace que los accesos a esos datos sean más lentos?

Answer 4

¿El problema se repite si la matriz es lo último en su parte del espacio de direcciones? Si no es así, mirando en su mapa, intente mover la declaración de matriz para que, una por una, las cosas colocadas después de ella se barajen para que estén en su lugar. De esta manera, puede localizar el objeto relevante y comenzar a averiguar por qué moverlo causa el retraso.

Answer 5

Me arriesgaría a mí mismo y afirmaría que aquí no tiene un problema de rendimiento, sino un tipo de corrupción de memoria que se presenta como un problema de rendimiento. Añadiendo una matriz a su ejecutable cambiando la imagen de la memoria. Entonces, supongo que tendrá una corrupción de memoria que, en su mayoría, es inofensiva (es decir, la sobrescritura que no se utiliza en parte de la memoria) y el hecho de desplazar la memoria más de 40 bytes hace que la corrupción de la memoria genere un problema mayor. Cual es una pregunta real

Answer 6

¿Podría la inicialización sobrescribir otro fragmento de código adyacente? ¿Hay alguna estructura o variable que use la matriz, que ahora es más grande y podría causar un stackoverflow?

Answer 7

También podría haber un conflicto de banco o página en. Tal vez tenga dos rutinas que se llaman con bastante frecuencia (interruptores de interruptores o algo así) que han estado en la misma página y ahora están divididas en dos páginas.