Здравейте на всички във форума. Имам проблем и ще съм много благодарен ако някой ми помогне.
Изходни данни:
Windows XP
IAR Embedded Workbench 6.40.4
Debugger:ARM-USB-OCD
Boards: STM32-H103, STM32-P103

(Schematic STM32-H103 - https://www.olimex.com/Products/ARM/ST/ ... 03-sch.gif)

(Schematic STM32-P103 - https://www.olimex.com/Products/ARM/ST/ ... 03-sch.gif)

MCU:STM32F103RBT6 - http://www.st.com/web/catalog/mmc/FM141 ... 5/PF164487
На горния сайт, в таба Design Resources се намира връзката към примера описан по-долу.

Datasheet - http://www.st.com/st-web-ui/static/acti ... 161566.pdf
Reference Manual - http://www.st.com/st-web-ui/static/acti ... 171190.pdf
Programming Manual - http://www.st.com/st-web-ui/static/acti ... 228163.pdf

Example: STM32 ADC modes and their applications - http://www.st.com/web/en/catalog/tools/PF257864
По отношение на примерите, със STM32-P103 съм ползвал ScanContinuous, а със STM32-H103 съответно SingleChannelContinuous.

По важни настройки на средата по подразбиране
Options->General Options->Target->Processor Variant->Device-> ST STM32F103xE
Options->Debugger->Setup->Driver->J-Link/J-Trace
Options->Debugger->Download->Use flash loader(s) (само това е отметнато)-> $TOOLKIT_DIR$\config\flashloader\ST\FlashSTM32F10xxЕ.board
По важни настройки на средата така като съм ги избрал
Options->General Options->Target->Processor Variant->Device-> ST STM32F103xB
Options->Debugger->Setup->Driver->GDB Server (със съответни настройки localhost,3333)
Options->Debugger->Download->Use flash loader(s), Verify Download, Override default .board file (само това е отметнато)-> $TOOLKIT_DIR$\config\flashloader\ST\FlashSTM32F10xxB.board

Ще се опитам да си припомня първата конфигурация която съм флашнал. Не съм напълно сигурен по отношение на това дали наистина (това важи само за STM32-P103) описаното по-долу беше най-първата конфигурация която съм флашнал.
За STM32-P103 и съответно ScanContinuous по важните промени са

ADC_RegularChannelConfig(ADC1, ADC_Channel_11, 1, ADC_SampleTime_41Cycles5);
ADC_RegularChannelConfig(ADC1, ADC_Channel_17, 1, ADC_SampleTime_239Cycles5);
ADC_RegularChannelConfig(ADC1, ADC_Channel_16, 2, ADC_SampleTime_239Cycles5);
// ADC_RegularChannelConfig(ADC1, ADC_Channel_14, 4, ADC_SampleTime_1Cycles5);
и
/* Configure PC.01 and PC.04 (Channel11 and Channel14) as analog input -----*/
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1;// | GPIO_Pin_4;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN;
GPIO_Init(GPIOC, &GPIO_InitStructure);
Ако се вгледате в схематика на STM32-P103 ще видите защо съм изключил 11 канал. Пълната версия на оригинала се намира в примера описан по горе (STM32 ADC modes and their applications). Тук описвам само промените които съм въвел.

За STM32-H103 и съответно SingleChannelContinuous по важните промени са
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5;
Този пин беше настроен с GPIO_Pin_4. Аз го промених на 5 заради USB_P (справка - Schematic STM32-H103).
Съответно трябваше да променя и
ADC_RegularChannelConfig(ADC1, ADC_Channel_14, 1, ADC_SampleTime_28Cycles5);
на ADC_Channel_15 но забравих и първата конфигурация която флашнах на STM32-H103 беше тази. Пълната версия на оригинала се намира в примера описан по горе (STM32 ADC modes and their applications). Тук описвам само промените които съм въвел.

След цялото това описание дойде ред и това какъв същност е проблема. При първото пускане всичко работи и изглежда нормално. При всяко следващо пускане се получава следното:

Debug Log

Tue Apr 09, 2013 15:52:52: Loaded macro file: F:\INSTALL\IAR Systems\Embedded Workbench 6.4 Kickstart\arm\config\flashloader\ST\FlashSTM32F10xxx.mac
Tue Apr 09, 2013 15:52:52: -I- execUserFlashInit!
Tue Apr 09, 2013 15:52:52: 456 bytes downloaded and verified (5.71 Kbytes/sec)
Tue Apr 09, 2013 15:52:52: Warning:
Verify error at address 0x20000040, target byte: 0x41, byte in file: 0x00
Tue Apr 09, 2013 15:52:52: Warning:
Verify error at address 0x20000041, target byte: 0x0E, byte in file: 0x20
Tue Apr 09, 2013 15:52:53: Fatal error: There were warnings during download of FLASH loader, see Log Window Session aborted!
Tue Apr 09, 2013 15:52:53: Failed to load flash loader: F:\INSTALL\IAR Systems\Embedded Workbench 6.4 Kickstart\arm\config\flashloader\ST\FlashSTM32F10xxxRAM16K.out
Tue Apr 09, 2013 15:52:53: Failed to load flash loader: F:\INSTALL\IAR Systems\Embedded Workbench 6.4 Kickstart\arm\config\flashloader\ST\FlashSTM32F10xxB.flash

Това е дебъг лога който получавам от STM32-H103, същото но с повече съобщения започаващи с Verify error, получавам и със STM32-P103.
Резултата от всичко това е че не мога да флашна, не мога да изтрия паметта, не мога и да дебъгвам. На практика двете платки са напълно неизползваеми.

Във макро файла се прави описание (разпределение) на паметта. Опитах да го променя така че да се заобикаля опоменатия участък 0x20000000 (bit-band областта на този процесор) и да видя дали ще има някъкъв резултат, нищо не се промени.
Направих някои промени и във файла описан в настройките на линкера $PROJ_DIR$\STM32F10x_FLASH.icf. Отново с цел да се заобиколи тази област, нищо не се промени.
Разбира се, всички тези промени ги правех в резервни копия, а не в оригиналния макро и icf файл.
Правих опити и с различни конфигурации за флашване (различни настройки на пиновете, някои от които включваха и 11 канал на АЦП). Извърших тези опити след като проблема вече беше наличен. Отново нищо не се промени.

В крайна сметка съм в задънена улица, с две неизползваеми платки, едната от които повредих преди 4-5 дена, а другата преди малко (т.е. днес). Много ще се радвам ако някой ми помогне поне да разбера къде е проблема, защо се получава така. Още по-добре ще е разбира се да се намери начин да се оправят за да не се налага да ги плащам.
Прикачения файл съдържа същото описание, но ми струва че там е по четливо.

Опитай да вкараш процесора в boot режим преди да пуснеш флашването. За целта предварително трябва да дръпнеш пин BOOT0 към '1'. Гледам че OLIMEX са сложили джъмпер който ще ти свърши работа.
Според мен всичко с двете платки е наред - нищо не си повредил. Просто докато се опитваш да стартираш флашването, процесора изълнява флашнатия пример, който също драска по RAM-а. Вкарвайки процесора в boot режим всъщност ще направиш така че работата на флашнатата програма да не се сблъсква с качването на лоудър-а.

След това за да тръгне флашнатата програмка съответно трябва да дръпнеш BOOT0 към '0'.

EDIT: Може да се наложи да направиш power cycle или Reset между съответните манипулации на BOOT0 пин-а. Прочети в user manual-a за функцията на BOOT0 и ще ти стане ясно защо.

Отдавна не съм ползвал IAR и не знам доколко се разбира с ОЦД-то... и от лог-а не мога да се ориентирам дали не се опитва да си качи флаш лоадер, което едва ли е нужно.

При всички случаи обаче по-добре да се елиминират проблемите един по един. Остави IAR- а пусни оцд-то и се закачи с телнет на порт 4444 или там който порт е сложен. Отвори си документацията на ОпънОЦД и виж командичките. Трябва да има за target reset, както и команди за четене, писане и триене на флаша.
При ресет трябва ти показва че се е ресетнало и че още има връзка с таргета. Ако това не минава нищо друго няма да мине. След ресет може да има или да се наложи да имаш юзер процедури за ресет и инициализация. Причината е, е че не винаги може да се получи "девствен" чип след ресет. Ако изобщо има хардуерен ресет вързан, щото някои платки нямат. Някои чепове пък не спират на първата инструкция... А може пък ти да не искаш или да си му казал да не прави хардуерен ресет.
Та така де, прави се някакъв ресет (хардуерен и/или само на jtag tap) и се прави опит да се спре проца (ако не е спрял сам). И тъй като няма гаранция, че избщо е имало ресет и ако имало дали след него не е успяло да барне периферията... та затова може да се наложи софтуерно да си ресетнеш каквото ти трябва. Примерно добре е да знаеш, че всички ДМА-та са спряни, щото ако не са - те може да мажат по паметта. Затова ресет скрипта трябва да погрижи да спре ДМА и перифериите. Евентуално ако имаш мапинг на паметите да го направи, защото ти може да се опитваш да флашваш, ама ако той не е мапнат където очакваш няма да стане...
Общо взето след ресет пробваш четене и писане първо по RAM, после по флаша. И ако всичко е наред, тогава пробваш с IAR или друг дебъгер.

Благодаря за съветите, някои от тях наистина бяха полезни.
Накратко:
Установих че все пак контролера работи ако вляза не с Download and Debug но с Debug without downloading. За да го накарам да сработи и в останалите случаи (Erase Memory, Download and Debug и др.) се наложи да сложа един брейкпойнт в началото, да го пусна с f5(Go) и след това да му дам хардуерен ресет (с бутона на контролера) за да се върне отначало. Без ресета, само с брейкпойнт не става. Впоследствие всичко си работи, с едно малко условие.

Все пак реших да видя откъде идва грешката, това че намерих начин да я поправя не означава че всичко е приключило. Проверих изпълнението на целия main стъпка по стъпка и установих нещо много странно. При пускането на RCC_AHBPeriphClock, RCC_APB2PeriphClock (а също и при ADC_SoftwareStartConvCmd) се наблюдава "мацане" в регистрите на процесора, по специално R0, R1 и R2. Това съм показал и на прикрепените файлове. Стойността на локалната променлива NewState се променя вътре във функцията, като тя се ползва само за референция. Вследствие if-ът се изпълнява погрешно.

Изпробвах варианта с телнет-а. Дадох му reset_config trst_and_srst и после reset. Установих две неща. Първо, ако не съм му флашнал файла от ИАР-а дава грешка свързана с msp, програмния брояч и xPSR (има .png файл в прикачените). Второ, съобщението което дава след успешен ресет е почти същото с това което дава OpenOCD-то и при стартиране на дебъгера, което ме навежда на мисълта че ресета се прави още при стартиране.

Ще съм благодарен ако някой може да помогне с това писане в регистрите.

Първи и втори .png файл са последователни, т.е. снети са след f10 по време на дебъгване. Трети и четвърти .png файл се припокриват с първи и втори но инфото е показано по друг начин.

Само да допълня че това писане в регистрите се получава само при проектите, които са част от пакета с примери STM32 ADC modes and their applications - http://www.st.com/web/en/catalog/tools/PF257864.

аз не виждам никакво "мацане"...
По-скоро работиш с оптимизиран код и дебъгера не ти позиционира правилно сорса (нормално)... Подобен код се дебъгва само като гледаш асемблера и *него* изпълняваш стъпка по стъпка, а той е:



крайният резултат на тоя код е, че се вдига младшия бит на RCC_AHBENR, т.е. пуска се клока на DMA1.
Просто не гледай къде дебъгера ти маркира сорса (не и когато работиш с оптимизиран код)....

Благодаря за съветите. Странния начин на изпълнение се е дължал на липсата на full assert. Основния проблем (грешката при повторно флашване ) се оказа че се дължи на DMA-то. DMA контролера осъществява достъп до една клетка от паметта , променлива която се заделя от компилатора на адрес на които той си прецени. При първото флашване това работи. При всяко следващо флашване или опит за достъп до паметта (прочитане, изтриване и т.н.) обаче се прави опит да се осъществи достъп до клетка от паметта която се ползва от DMA контролера. Този проблем явно трябва да се реши чрез промяна на настройките на DMA контролера. Понеже не ми се занимаваше с това просто заделих тази променлива на точно определен адрес (при ICCARM компилатора това става с @), т.е. налучках, след няколко опита, адрес от паметта който е описан в .icf файла на линкера като RAМ и в същото време не се ползва при флашването. И всичко работи.

фул какво?


Този проблем се решава само по един начин - ресет скрипта на емулатора ти. Не може да оставиш пуснати DMA-та и да флашваш... ти няма и да можеш да дебъгваш като хората ако ти е разбутана периферията...

Обикновено след конектване при всички М3 (изключая луминари) се ресетва всичко... Просто пишеш 0x05FA0007 на адрес 0xE000ED0C (NVIC -> Application Interrupt and Reset Control).
При OpenOCD командичката трябва да е "mww 0xE000ED0C 0x05FA0007" само трябва да видиш в кой от конфигурационните файлове трябва да я сложиш...