STM32F101 Rev. Z Опции

[MALLOY2]

Вопрос по 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 что там глючного ?

[MALLOY2]

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

[Sanek_spb]

там обсуждают глюки 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