[Vitaliy_ARM 0]

Доброе время!

 

Было в свое время разработано устройство на микроконтроллере LPC1778 и флешке AT45DB081D-SSU. Последняя использовалась для хранения таблиц с коэффициентами. Эту флешку постранично могло обновлять программное обеспечение. Запись во флешку делается при помощи команды 0x82 (Main Memory Page Program through Buffer 1 with Built-In Erase), для чтения использую 0xD2 (Main Memory Page Read). Все работало замечательно, пока AT45DB081D-SSU не сняли с производства. На замену ей пришла AT45DB081E от Adesto, которую мы установили в новую партию. И тут начались чудеса. После создания тестовых программ, выяснилось, что данные записываются некорректно, причем может во всей памяти записаться некорректно один байт, а может и вся страница, а может и все нормально записаться. Причем это не от чего не зависит, глючит спонтанно. Даже ввели верификацию страниц и повторную запись. Однако выяснилось, что контрольная сумма данных не совпадала, даже когда постраничная верификация и перезаписть проходила на ОК. Т.е. запись одной страницы может убить данных в другой. Думали, что флешки бракованные. Купили в проверенном месте - тоже самое.

 

Подскажите, в чем может быть причина?

 

Функция записи страницы приведена ниже. (используется 264 байтная страница)

 

BOOL at45db081d::write264(WORD page, BYTE *pBuf)
{
    unsigned int i;

    if(page > MAX_PAGES)
        return FALSE;// FALSE;
    
    SET_AT45D_CS();
    reg[0] = 0x82;
    reg[1] = page >> 7;
    reg[2] = page << 1;        
    reg[3] = 0x00;
    pSpi->transfer(reg, 4);
    pSpi->transfer(buf, 264);
    CLR_AT45D_CS();
    for(i = 0xFFFFFFFF; i > 0; i--)
    {
        if(status() & 0x80)
            break;                
    }
    if(i == 0)
        return FALSE;
    if(status() & 0x20)       // EPE bit
        return FALSE;
    return TRUE;
}

[AltemirX 0]

CS после записи отпускали? Бит EPE смотрели в статусном регистре? Пока на E-серию не переходили, сидим на D, но весьма заинтересовался таким багом.

Сюда заглядывали? http://www.adestotech.com/wp-content/uploads/081E.pdf

[Vitaliy_ARM 0]

CS после записи отпускали? Бит EPE смотрели в статусном регистре? Пока на E-серию не переходили, сидим на D, но весьма заинтересовался таким багом.

 

Да, конечно. CS опускаю перед записью и поднимаю после окончания. Я привел пример кода записи в первом посте. Привожу код функции status() ниже. Если впаять 081D, то глюки пропадают принципиально. Что только не делал, не могу добиться 100% нормальной записи. Если запись была совершена некорректно, бит EPE взводится и бывает, что я эту же страницу не могу перезаписать, при попытки использовать 82-ю команду, данные не записываются корректно и взводится этот бит. Что делать, если он взводится, в мануале не написано ...

 

Сюда заглядывали? http://www.adestotech.com/wp-content/uploads/081E.pdf

Документ этот видел. Эти команды (0x82 и 0xD2) у них не отличаются. Должно все работать одинаково, но не работает.

 

P.S.: У меня напряжение питания флешки 3,3В, но не думаю, что это причина.

 

/**************************************************************
* чтение регистра статуса
*************************************************************/
BYTE at45db081d::status()
{
    // Status Register Read
    SET_AT45D_CS();                  // set CS to LOW
    reg[0] = 0xD7;
    reg[1] = 0x00;
    pSpi->transfer(reg, 2);
    CLR_AT45D_CS();                  // set CS to HIGH
    return reg[1];
}

 

P.S.2: Сейчас есть более дешевая альтернатива этой флешки: http://www.spansion.com/Support/Applicatio..._S25FL-K_AN.pdf , но тут другая распиновка.

Устройства уже выпущены и радикально переделывать что-то не особо хочется.

[alag57 1]

Документ этот видел.

 

    reg[0] = 0xD7;
    reg[1] = 0x00;
    pSpi->transfer(reg, 2);

 

AT45DB081E – New 2-byte Status Register.

[MobyDick 0]

На всякий случай отмечу, что в том документе они умалчивают об ещё одном различии:

- в ревизии "D" было "All inputs (SI, SCK, CS#, WP#, and RESET#) are guaranteed by design to be 5-Volt tolerant" (-0.6V to +6.25V);

- в ревизии "E" стало "-0.6V to VCC + 0.6V"

[mcheb 0]

Я на какой то флэшке так делал после посылки буфера

// read status register проверка окончания записи

// nop();

// printf("WR\n");

CS_SST25_L;

SpiMaster(0x05);

while(SpiMaster(0x00) & (WIP | WEL) )

{

nop();

};

CS_SST25_H;

нужен тайм-аут для окончания процесса записи

[Vitaliy_ARM 0]

    reg[0] = 0xD7;
    reg[1] = 0x00;
    pSpi->transfer(reg, 2);

 

AT45DB081E – New 2-byte Status Register.

 

Спасибо, заменил. Но это никак на ситуацию не повлияло. Глючит также. У них первый регистр статуса совместимый, наверное, теоретически, должен быть совместим и по коду.

 

 

На всякий случай отмечу, что в том документе они умалчивают об ещё одном различии:

- в ревизии "D" было "All inputs (SI, SCK, CS#, WP#, and RESET#) are guaranteed by design to be 5-Volt tolerant" (-0.6V to +6.25V);

- в ревизии "E" стало "-0.6V to VCC + 0.6V"

Это хорошее замечание, если у кого-то используется с AVR, могут наступить на грабли.

 

Я на какой то флэшке так делал после посылки буфера

// read status register проверка окончания записи

// nop();

// printf("WR\n");

CS_SST25_L;

SpiMaster(0x05);

while(SpiMaster(0x00) & (WIP | WEL) )

{

nop();

};

CS_SST25_H;

нужен тайм-аут для окончания процесса записи

 

Это немного другая флешка, фирмы SST. Похоже на чтение регистра статуса. У меня также функция ожидает завершения операции записи при помощи чтения регистра статуса и проверки соответствующего бита.

 

[alag57 1]

У них первый регистр статуса совместимый, наверное, теоретически, должен быть совместим и по коду.

    if(status() & 0x20)       // EPE bit
        return FALSE;

 

EPE бит о втором байте однако.

[jcxz 243]

У нас также выпускаются несколько устройств на LPC1778 + какая-то из AT45D (только на 16 или 32 Мбита).

В более старом устройстве на LPC2378 также используются эти же AT45D. Правда мы используем насколько помню страницы 528байт (писал уже давно, несколько лет назад).

О проблемах с ними ничего не слышал, а раз выпускаются каждый месяц сотнями шт., а я - писал для них драйвера для системы хранения, то думаю - услышал бы о проблемах первый. Если конечно наши снабженцы не нашли где-то запасы старых ИС. :-)

В пн, как появлюсь на работе, надо глянуть - какие мелкосхемки стоят в последних экземплярах....

[AltemirX 0]

Vitaliy_ARM

pSpi->transfer(buf, 264);

Можете пояснить? Всегда записывается буфер длиной 264 Байта? А не пробовали протестировать с записью 4, 128, 250 Байт, к примеру? Ошибка повторяется?

[jcxz 243]

Можете пояснить? Всегда записывается буфер длиной 264 Байта? А не пробовали протестировать с записью 4, 128, 250 Байт, к примеру? Ошибка повторяется?

Прежде чем что-то советовать, хоть даташит откройте. В AT45D невозможно записать меньше страницы.

[AltemirX 0]

Прежде чем что-то советовать, хоть даташит откройте. В AT45D невозможно записать меньше страницы.

Ступил. Предполагал то, что не могло ли писаться 264 байта при организации страниц флэшки по 256, но здесь не тот случай.

 

В пн, как появлюсь на работе, надо глянуть - какие мелкосхемки стоят в последних экземплярах....

Так что там в "последних экземплярах"?

[Vitaliy_ARM 0]

Код чтения статуса я исправил на двухбайтовый и исправил проверку EPE бита. Но результат записи с флешкой тот-же. Сегодня утром я пришел и начал тестировать эту флешку, первые 10 раз зашилась без проблем. Потом начала глючить один раз из 5 записей, потом чаще. И в итоге после записи 40 раз она сходит с ума и уже не пишется без ошибок. Если прибор полежит без питания несколько часов, она опять начинает шиться без ошибок. Какая-то ерунда ...

Первый раз такое встречаю за 10 лет работы. Одна партия была куплена на DigiKey, вторая в Компеле. Ведут себя примерно одинаково.

 

В общем вопрос работы флешки AT45DB081E в корпусе SO-8 пока открыт.

 

P.S.: Мы нашли уже другой способ избавиться от проблемы. Применили алгоритм сжатия данных и запихнули коэффициенты в сжатом виде в микроконтроллер. Это решение даже лучше, чем применять внешнюю микросхему. Но вопрос глючности флешки это не решает.

[alag57 1]

write264(WORD page, BYTE *pBuf)
{
.....
    pSpi->transfer(buf, 264);
}

 

Передаете указатель pBuf, а используете buf. Может где-то портится буфер записи?

Например в функции transfer.

[aaarrr 69]

Если прибор полежит без питания несколько часов, она опять начинает шиться без ошибок. Какая-то ерунда ...

А охладить её в процессе тестов не пробовали?