Вопрос по errata.

Description
Compilers with improved optimizations for the STM32F10xxx have been recently released
on the market. Revisions Z and B of the medium-density STM32F10xxx devices
(STM32F10xx8/B) do not support some of the sequences associated with the high-level
optimizations done in these compilers. Revision Y is not affected by this limitation.

Workaround
This behavior is fully deterministic, and should be detected during firmware development or
the validation phase. Consequently, systems already developed, validated and delivered to
the field with previous silicon revisions are not affected.
For code update of revision Z and B devices already in the field, do not use these new
compilers. To date, compilers known to generate these sequences are:
● IAR EWARM rev 5.20 and later
● GNU rev 4.2.3 and later
For new developments associated with these compilers, revision Y of the STM32F10xx8/B
must be used.


Есть ли более подробное описание этого глюка ? а то с ерраты ничего не понятно...

У меня IAR5.20 как этот глюк проявляется и как нанего и скакой вероятностью на него можно наступить ?
Я вобще не понимаю этого описания.... как можно советовать использовать компилятор более раних версий, получается как бы виноват компилятор, но тут виноват контроллер, следовательно глюк у него и причем тут тогда компилятор если я буду писать на чистом ASM ? Вывод если это ошибка камня то по чему она не описана.... К примеру у TMS320C5502 тоже есть глюки ядра которые тоже зависят от ревизии но там четко написано что после этой команды надо поставить NOP к примеру....

Кто пробывал работать на IAR5.20 c камнями ревизии Z что там глючного ?

Revision Y is not affected by this limitation.

You should get a latest Y revision STM32F device if you need to use:
● IAR EWARM rev 5.20 and later
● GNU rev 4.2.3 and later

Я читать умею, у меня лежит партия ревизии Z. Хочу знать что сней не так.

У меня партия не лежит, только образцы, но на это сообщение забил, пока все работает.
Множественные фичи контроллера не использую.
Где споткнусь - не знаю.
Да, библиотеку обновил, чтобы окончательно ввести противника в заблуждение.

По этому глюку сказать ничего не могу, да и вообще кейлом пользуюсь, а он в еррате не упоминается.

Меня сейчас другой вопрос мучит: вот тут http://electronix.ru/forum/index.php?act=S...t=0#entry516481 товарищ Sanek_spb обнаружил в олимексовских примерах описание ошибки DMA, причем весьма существенной ошибки. При этом нигде более она не упоминается. Уж и не знаю теперь, что с этим делать.

Нарыл такой документ, тоже не очем.

Может всетаки глюки какието с хидерами или отладкой...., так хочется верить в лучшее.

Я поначалу забил на это предупреждение и довольно долго пользовался версией 5.20 со старыми камнями. Потом, когда уже забыл об этом предупреждении, программа заглючила: стала подвисать где-то еще до вызова main(). Поиски причины ни к чему не привели и я вспомнил предупреждение. Откатываться на старую версию не хотелось, успел привыкнуть к новой. Тогда я скопировал всю папку LIB из версии 5.0 в 5.20. С тех пор прошло месяца полтора, глюков пока не наблюдаю.

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

Подробно не смотрел, но может здесь найдёте что-нибудь полезное?

там обсуждают глюки JLink в этой тиматике (IAR 5.20 && Rev.Z) позиция ST похоже такая - фиг что мы вам раскажем

И это тоже...
Если покопаться поглубже, то можно найти причину нашего обсуждения:
1. Проблема всего в одной инструкции, причем не у ST, а у всех кортексов
2. Workaround for Cortex-M3 CPU errata. Errata present in some Cortex-M3 cores can cause data corruption when overlapping registers are used in LDRD instructions. The compiler avoids generating these problematic instructions when the -mfix-cortex-m3-ldrd or -mcpu=cortex-m3 command-line options are used. The Sourcery G++ runtime libraries have also been updated to include this workaround.
Т.е. новые компилеры знают про эту ошибку и будут генерить нормальный код. Кейл эту проблему у себя победил и ...
3. Для ознакомления http://www.keil.com/support/docs/3442.htm
4. Чтобы окончательно стало понятно почему у некоторых так, а у других по другому
1) This limitation does not affect the STM32 code execution when fetching
from embedded FLASH (standard use of the product).
2) The limitation may affect the STM32 code execution when fetching from:
- Embedded RAM
- External memory (via FSMC for the STM32 High Density ). This applies
to applications requiring large amount of code (more than the embedded Flash size ).

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

ЗЫЖ To finish, as the limitation is based on asynchronous event (interrupt) on a specific code sequence (LDRD) not executed from STM32 embedded flash, there is very limited chance to get end-customer application fault.

Nevertheless, all our Compilers partners (Keil, IAR, GNU CodeSourcery, Hitex etc..) already provide a "Detection" tool for code deployed in the field with previous/old revisions of compilers that may generate this sequence

Сообщение отредактировал Sanek_spb - Dec 16 2008, 10:02

О... это уже что- то, спасибо.

Но тут тоже калабур.

Имеем:

CPU Rev Z. - старая версия
CPU Rev Y. - новая версия

IAR 5.11 - старая версия
IAR 5.20 - новая версия

1) Из выше приведенного текста выходит что старый иар незнает о LDRD - то какже оно работает с ревизией Z ? значит тут глюк не в LDRD.

2) Сатрый иар знает об этой ошибке и генерирует правельный код, для простоты не использует LDRD, это более правдободобно.

3) Новый иар уже думает что работает с исправленным ядром и использует команды LDRD из за этого возникают проблемы с ревизией Z - вывод ревизия Y уже сделана на новом ядре. Но выше приведенном тексте написано что новые компиляторы умееют обходить LDRD, а не то что выпущена новая ревизия ядра с исправленным глюком непонятно...

или я не так чето понял, и 3 пунк является самым правельным ?

Скачал программулину для проферки проета на глюк LDRD но счас нет озможности ее проверить, может кто потестит ?

The attached EXE file scans a disassembly listing for opcodes of the offending form.

CM3Errata602117.exe
===================

This tool scans q text file to locate instances of LDRD that are
susceptible to the Cortex-M3 LDRD erratum (erratum #602117). First
create a disassembly text file using your toolchain. For example:
* RVCT or RVMDK: fromelf -c
* GNU or IAR EWARM: objdump -d
* IAR EWARM: ielfdumparm --code --disassemble
Then pass that file to CM3Errata602117.exe.

Usage: CM3Errata602117.exe DisassemblyFile.txt

Please check the errata list to verify whether Erratum 602117 applies to your specific Cortex-M3 instance.


Походу, в петче 5.20.3 для IAR как раз идет речь об этом LDRD может после этого патча и Rev.Z нормально работает на 5.20 ? если конечно это с этим связано
Errata октябрем месяцем сделана, а патч ноябрьский....

http://infocenter.arm.com/help/topic/com.a...rrata602117.zip

5.20 не работает с Z, тогда 5.20 это и был новый ИАР и по предположения авторов текста приведенного в первом посте все остальные ИАРы по идее должны будут уметь компелить оптимальный код, но ребята в ИАРе и останых конторах заметили багу и понавыпускали патчи к своим продуктам.

Всеравно ничего не понятно, что они сделали в ревизии Y, просмотрев документы на ядро Cortex я увидел что глюк c LDRD не исправлен и на текущий момент присутствует во всех ядрах. Может это вовсе не связано с LDRD ....