IAP в LPC, баянистый вопрос наверное... Опции

[Romario]

нужно ли копировать код, который вызывает функцию IAP в раму? или не обязательно.
в даташите явно это не написано. мнения разделись. хочется наверняка знать и успокоится.
чтобы не было граблей.

я вот тут попробовал и....

[AlexandrY]

Грабли будут по любому

нужно ли копировать код, который вызывает функцию IAP в раму?

Если прямо на вопрос, то толку вызавать IAP из RAM если сам IAP передаст управление опять во FLASH?

А если взглянуть шире, то к любым слухам стоит прислушаться.
IAP в LPC вещь очень ненадежная и странная.
На мой взгляд у них серьезные проблемы с модулем Error Correction Code или контроллером FLASH.
Я например знаю последовательность данных запись которых во FLASH через IAP гарантировано приведет к искажению информации в соседних ячейках. Выражаться будет в том, что в соседней ячейке с записанным 0 и которую при записи совершенно не трогаем возникнет бит 1, который нельзя будет в последствии перезаписать в 0! (ну не считая полного стирания сектора)
Ни отключение MAM, ни отключение PLL, ничего от этого эффекта не помогает. Проверено на нескольких LPC2148, и в разных секторах.
Использование IAP полностью корректное, прерывания отключены, питание стабильное, эффект тоже очень стабильный - 100%-ый.
Процедура использования IAP сверена с тем как делается в примерах у IAR и у Keil, в файловой системе Keil-а и как рекомендует сам Philips. Тонкость в том, что в файловых системах применяется многократная дозапись страниц в сектора FLASH-и. Если писать страницы сразу и не трогать потом, эффект не заметил пока. Но, скажем, знаю разработчиков которые имели проблемы и с однократной постраничной записью.

[zltigo]

Грабли будут по любому
....
А если взглянуть шире, то к любым слухам стоит прислушаться.
...

Я например знаю последовательность данных запись которых во FLASH через IAP гарантировано приведет к искажению информации в соседних ячейках.

Ну вот кто-то где-то что-то сказал :-(

1. Давайте сюда эту жуткую последовательность.
2. Городить файловую систему (32K блоки после стирания восстанавливать :-( ) на встроенном FLASH на запись - наверное не стоит по любому.
3. ISP загрузчик сам через ISP (естественно без дозаписи 512 байтовыми страницами а сразу сектором) работает с абсолютно разной информацией и никаких проблем......

[AlexandrY]

Грабли будут по любому
....
А если взглянуть шире, то к любым слухам стоит прислушаться.
...

Я например знаю последовательность данных запись которых во FLASH через IAP гарантировано приведет к искажению информации в соседних ячейках.

Ну вот кто-то где-то что-то сказал :-(

1. Давайте сюда эту жуткую последовательность.
2. Городить файловую систему (32K блоки после стирания восстанавливать :-( ) на встроенном FLASH на запись - наверное не стоит по любому.
3. ISP загрузчик сам через ISP (естественно без дозаписи 512 байтовыми страницами а сразу сектором) работает с абсолютно разной информацией и никаких проблем......

Ну например:
При чистом FLASH секторе т.е. где все 0xFF делаете так:
Организуете в RAM буфер скажем на 1024 байт (или 512 , это ничего не изменит )
Весь буфер заполняем 0xFF в конец только припишем по смещению 0x3F8 массив {0x0C, 0x00, 0x00, 0x00}
Записываем буфер (1024 байт) во FLASH по адресу 0x1FС00 используя IAP
Теперь обратно из FLASH по адресу 0x1FC00 считываем в буфер те же 1024 байта и дописываем в буфер по смещению 0x3FС массив {0xF0, 0xF0, 0xF0, 0xF0}
Снова записываем буфер во FLASH по адресу 0x1FС00 используя IAP
Теперь проверяем че там во FLASH записалось и видим по адресу 0x1FFFB байт 0x01
Попытки забить это байт 0-ем ни к чему не приведут.

Таких вариантов могу привести кучу. Эффект проявлялся как в конце сектора FLASH так и в начале и в разных секторах

[AlexandrY]

Выяснил проблему.
Оказывается Philips всех лоханул.
ECC то его работает на 128 битах, а в мануалах они везде пишут что шить можно по 4-е байта, а на самом деле надо по 16-ть.
На это повелся Keil и написал нерабочую файловую систему для LPC
А за ними и я.
Итак вывод: Во FLASH LPC надо писать блоками данных кратными 16-и байтам и повторно в эти блоки больше ничего записывать нельзя даже если там осталось много FF.
Отсюда видно, что файловую систему типа той что написал Keil в принципе нормально реализовать нельзя для LPC .

[Romario]

Выяснил проблему.
Оказывается Philips всех лоханул.
ECC то его работает на 128 битах, а в мануалах они везде пишут что шить можно по 4-е байта, а на самом деле надо по 16-ть.
На это повелся Keil и написал нерабочую файловую систему для LPC
А за ними и я.
Итак вывод: Во FLASH LPC надо писать блоками данных кратными 16-и байтам и повторно в эти блоки больше ничего записывать нельзя даже если там осталось много FF.
Отсюда видно, что файловую систему типа той что написал Keil в принципе нормально реализовать нельзя для LPC .

опередили!:))) аккурат я об этом и хотел сегодня написать в этот топик.
вчера проводил эксперимент)

p.s. т.к. что то уж смутно верилось в то, что филипок так облажался.

Сообщение отредактировал Romario - May 5 2006, 15:20

[zltigo]

p.s. т.к. что то уж смутно верилось в то, что филипок так облажался.

Ну насчет 'облажался' - разве они где-то написали, что можно писать поверх записанного блока???

ECC то его работает на 128 битах, а в мануалах они везде пишут что шить можно по 4-е байта, а на самом деле надо по 16-ть.

Ну когда я читал в последний раз мануалы, там было 512 байт и далее кратно.....
В последних на 213x/4x 256 и кратно, так что на счет "везде пишут 4 байта" - нет такого.

Посему наибольшую лажу спорол Keil, родив 'файловую систему'.

[AlexandrY]

Ну когда я читал в последний раз мануалы, там было 512 байт и далее кратно.....
В последних на 213x/4x 256 и кратно, так что на счет "везде пишут 4 байта" - нет такого.

Не, видать не поняли. В IAP - да, совать надо страницами по 512 и т.д. байт. Но для файловой системы важнее грануляция секторов на немодифицируемые в дальнейшем ячейки. Для обычных флешей можно модифицировать каждый байт забивая 1-цы нулями. Филипс утверждает что в его флеши это 4-е последовательных байта (смотрите внимательнее мануал где про FLASH) А на самом деле 16-ть и реверс ихнего IAP-а показывает, что за раз они шьют по 16-ть байт.
И была у меня своя линейная файловая система и черт дернул на халяву поиметь совместимую с С99 FS

[amusin]

Не, видать не поняли. В IAP - да, совать надо страницами по 512 и т.д. байт. Но для файловой системы важнее грануляция секторов на немодифицируемые в дальнейшем ячейки. Для обычных флешей можно модифицировать каждый байт забивая 1-цы нулями. Филипс утверждает что в его флеши это 4-е последовательных байта (смотрите внимательнее мануал где про FLASH) А на самом деле 16-ть и реверс ихнего IAP-а показывает, что за раз они шьют по 16-ть байт.

Действительно, у них в мануале на LPC213x есть ошибка:
A byte of ECC corresponds to every consecutive 128 bits of the user
accessible Flash. Consequently, Flash bytes from 0x0000 0000 to 0x0000 0003 are
protected by the first ECC byte, Flash bytes from 0x0000 0004 to 0x0000 0007 are
protected by the second ECC byte, etc.
Пока все нормально: 4 слова = 16 байт = 128 бит.
Therefore, for the implemented ECC mechanism to perform properly, data must be written
into the Flash memory in groups of 4 bytes (or multiples of 4), aligned as described above.
А вот здесь они опечатались, т.к. described above 16 байт, а не 4.
Спасибо за информацию.

[GetSmart]

Скажите, кто-нибудь пробовал при программировании флэша в LPC2000 одновременно обрабатывать прерывания? Разумеется обработчик должен быть в ОЗУ. И ещё, я знаю, что есть какое-то недокументированное прерывание (в регистре VICIntEnable, да и в других подобных) для обработки флэша. Кто-нибудь знает какое? Просто я знаю, что все свободные биты в этом регистре (аналогично быту 1) можно использовать для эмуляции аппаратных прерываний. Так вот, мне это надо знать чтобы случайно не напороться на это самое прерывание.