¿Por qué el cambio de hora de borrado de sector en el nuevo flash Nor hace que el controlador no funcione?

Estoy trabajando en una aplicación que involucra chips flash NOR. Tuve que cambiar chips a la mitad del proceso de diseño. Las diferencias indicadas entre los chips nuevos y antiguos son solo 'ID de dispositivo' y 'tiempo de borrado de sector'. Pensé que podría arreglármelas sin volver a escribir mi controlador flash dadas las pequeñas diferencias, pero el controlador del chip antiguo no funciona con el nuevo.

¿Por qué el tiempo de borrado de sectores es tan importante para el conductor? ¿Cómo lo cambio?

Necesitaremos al menos la siguiente información: números de pieza de chips flash antiguos/nuevos, en qué plataforma está escribiendo el controlador, ¿puede mostrarnos el código del controlador, puede proporcionar hojas de datos para los chips?
Cuando dices "mi controlador flash", ¿es algo que escribiste? ¿Tienes el código fuente para ello? Debería ser bastante fácil comprobar si el código está buscando el ID de dispositivo específico del chip anterior. Es muy común que el software que administra flash verifique explícitamente las ID de los dispositivos.

Respuestas (2)

El tiempo de borrado del sector es importante para cualquier controlador porque es un poco de tiempo necesario para usar el chip correctamente. Los chips flash tienen tiempos de borrado , que es el tiempo que se debe aplicar el voltaje de borrado especial a las celdas para garantizar que se borren. Si no se cumple este tiempo mínimo, es posible que las celdas no se borren por completo, lo que en efecto es un error de datos.

Algunos chips también pueden tener un tiempo de borrado máximo. Algunos chips requieren que el hardware externo realice el tiempo de borrado, otros realizan el tiempo interno y establecen un bit de estado cuando se completa el borrado. En ese caso, un controlador tendría que esperar el tiempo de borrado máximo posible o sondear el bit para asegurarse de que el borrado se haya completado antes de continuar con otras operaciones.

Al igual que con cualquier especificación, violarla significa que ya no se puede confiar en ninguno de los otros parámetros. Si este chip cronometra automáticamente el borrado y establece un bit cuando se completa y el controlador existente sondea este bit para determinar la finalización del borrado, entonces no debería ser necesaria ninguna modificación en el controlador.

En cualquier caso, pensar que puede "arreglárselas" violando una especificación solo porque está un poco fuera de lugar es una práctica muy, muy mala y debería avergonzarse de sí mismo por siquiera considerarlo.

¿Cuántos dispositivos flash ha utilizado en los que el software tuvo que preocuparse por borrar el tiempo para otra cosa que no fuera la determinación del tiempo de espera? Solo puedo pensar en uno: el flash interno en un TI DSP. Todos los demás dispositivos flash que se me ocurren que he usado han tenido ciclos de borrado automáticos. ¿Conoce algún chip flash "independiente" estándar que no tenga borrado automático?
Probablemente todos los chips flash grandes tienen temporización interna. Cuando programa la memoria del programa de algunos PIC a través de un programador externo, el programador tiene que realizar la temporización en algunos casos. O bien, es más rápido si el programador lo hace y puede hacerlo con precisión porque el chip tiene una pendiente en su oscilador, por lo que el tiempo nominal es más largo de lo necesario. A menudo hay una especificación máxima para el tiempo de borrado interno, por lo que posiblemente un controlador podría hacer su propio tiempo sin verificar.
Por lo que he visto, las partes OTP de Microchip dependían de un programador externo para programar pulsos de tiempo, pero sus partes basadas en flash están todas internamente cronometradas; Recuerdo vagamente que algunos PIC basados ​​en flash podrían haber permitido que un programador externo controlara el tiempo de escritura de flash, pero no recuerdo ningún indicio de control sobre el tiempo de borrado de flash.
Por cierto, una característica que recuerdo del DSP que permitía el control del software de la sincronización del flash era una característica para seleccionar uno de los tres umbrales de "lectura", para permitir que la CPU distinguiera los bits que se borraron por completo, en su mayoría borrados, en su mayoría programados o completamente programados . Por lo tanto, se podría determinar si un rango de memoria tenía bits potencialmente marginales. Sé que la corrección de errores y el flash multinivel significan que los conceptos de bits individuales "parcialmente programados" no son significativos en el mismo sentido que lo fueron en la parte de TI, pero...
... todavía parecería útil si los chips flash pudieran proporcionar una indicación de si parte de un bloque se escribió marginalmente, como una pista de que el software debería intentar copiar datos en ese bloque en otro lugar y luego, una vez que la copia esté completa, borrar y reciclar el bloque.

No ha mencionado ningún número de pieza, pero los fabricantes de chips flash han cambiado con el tiempo varios pequeños detalles sobre cómo funcionan sus chips. Es posible que su controlador tenga un código que use la identificación del dispositivo, algo así como "Si ID = esto, use un nuevo método, de lo contrario, use un método". Si el chip anterior requería un "método nuevo" y el nuevo chip tiene una ID diferente pero también requiere un "método nuevo", el código no funcionará porque intentará usar el "método antiguo". También es posible que su código dependa de algún detalle de cómo el dispositivo informa cuando está listo. En algunos dispositivos antiguos, si uno estaba registrando datos y se detenía cuando el dispositivo informaba su estado "listo", el valor informado cambiaría de forma asíncrona cuando el dispositivo finalizaba la operación en curso. En los dispositivos más nuevos,

Estoy de acuerdo con el bit de identificación del dispositivo. En mi experiencia, es MUY común que el software verifique explícitamente las identificaciones de los dispositivos. Creo que es más probable que el problema esté en el lado de la identificación del dispositivo que en el tiempo de borrado ... aunque todo es posible.