Jump to content

    
Sign in to follow this  
Guest MALLOY2

STM32F101 Rev. Z

Recommended Posts

Guest 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 что там глючного ?

Share this post


Link to post
Share on other sites
Я читать умею, у меня лежит партия ревизии Z. Хочу знать что сней не так.

У меня партия не лежит, только образцы, но на это сообщение забил, пока все работает.

Множественные фичи контроллера не использую.

Где споткнусь - не знаю.

Да, библиотеку обновил, чтобы окончательно ввести противника в заблуждение. :biggrin:

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Guest MALLOY2

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

Share this post


Link to post
Share on other sites
там обсуждают глюки 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

Edited by Sanek_spb

Share this post


Link to post
Share on other sites
Guest MALLOY2

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

 

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

 

Имеем:

 

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

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

 

IAR 5.11 - старая версия

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
Guest MALLOY2

Скачал программулину для проферки проета на глюк 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

Share this post


Link to post
Share on other sites
О... это уже что- то, спасибо.

 

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

 

Имеем:

 

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

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

 

IAR 5.11 - старая версия

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

 

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
Guest MALLOY2

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this