| Микроконтролери и електроника http://mcu-bg.com/mcu_site/ |
|
| Проблем със STM32-P103 (STM32F103RB) http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=11266 |
Страница 1 от 1 |
| Автор: | Георги [ Вто Апр 09, 2013 6:25 pm ] | ||
| Заглавие: | Проблем със STM32-P103 (STM32F103RB) | ||
Здравейте на всички във форума. Имам проблем и ще съм много благодарен ако някой ми помогне. Изходни данни: 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 дена, а другата преди малко (т.е. днес). Много ще се радвам ако някой ми помогне поне да разбера къде е проблема, защо се получава така. Още по-добре ще е разбира се да се намери начин да се оправят за да не се налага да ги плащам. Прикачения файл съдържа същото описание, но ми струва че там е по четливо.
|
|||
| Автор: | Zdrav [ Вто Апр 09, 2013 6:46 pm ] |
| Заглавие: | Re: Проблем със STM32-P103 (STM32F103RB) |
Опитай да вкараш процесора в boot режим преди да пуснеш флашването. За целта предварително трябва да дръпнеш пин BOOT0 към '1'. Гледам че OLIMEX са сложили джъмпер който ще ти свърши работа. Според мен всичко с двете платки е наред - нищо не си повредил. След това за да тръгне флашнатата програмка съответно трябва да дръпнеш BOOT0 към '0'. EDIT: Може да се наложи да направиш power cycle или Reset между съответните манипулации на BOOT0 пин-а. Прочети в user manual-a за функцията на BOOT0 и ще ти стане ясно защо. |
|
| Автор: | miro_atc [ Вто Апр 09, 2013 9:16 pm ] |
| Заглавие: | Re: Проблем със STM32-P103 (STM32F103RB) |
Отдавна не съм ползвал IAR и не знам доколко се разбира с ОЦД-то... и от лог-а не мога да се ориентирам дали не се опитва да си качи флаш лоадер, което едва ли е нужно. При всички случаи обаче по-добре да се елиминират проблемите един по един. Остави IAR- а пусни оцд-то и се закачи с телнет на порт 4444 или там който порт е сложен. Отвори си документацията на ОпънОЦД и виж командичките. Трябва да има за target reset, както и команди за четене, писане и триене на флаша. При ресет трябва ти показва че се е ресетнало и че още има връзка с таргета. Ако това не минава нищо друго няма да мине. След ресет може да има или да се наложи да имаш юзер процедури за ресет и инициализация. Причината е, е че не винаги може да се получи "девствен" чип след ресет. Ако изобщо има хардуерен ресет вързан, щото някои платки нямат. Някои чепове пък не спират на първата инструкция... А може пък ти да не искаш или да си му казал да не прави хардуерен ресет. Та така де, прави се някакъв ресет (хардуерен и/или само на jtag tap) и се прави опит да се спре проца (ако не е спрял сам). И тъй като няма гаранция, че избщо е имало ресет и ако имало дали след него не е успяло да барне периферията... та затова може да се наложи софтуерно да си ресетнеш каквото ти трябва. Примерно добре е да знаеш, че всички ДМА-та са спряни, щото ако не са - те може да мажат по паметта. Затова ресет скрипта трябва да погрижи да спре ДМА и перифериите. Евентуално ако имаш мапинг на паметите да го направи, защото ти може да се опитваш да флашваш, ама ако той не е мапнат където очакваш няма да стане... Общо взето след ресет пробваш четене и писане първо по RAM, после по флаша. И ако всичко е наред, тогава пробваш с IAR или друг дебъгер. |
|
| Автор: | Георги [ Сря Апр 10, 2013 8:44 pm ] |
| Заглавие: | Re: Проблем със STM32-P103 (STM32F103RB) |
Само да допълня че това писане в регистрите се получава само при проектите, които са част от пакета с примери STM32 ADC modes and their applications - http://www.st.com/web/en/catalog/tools/PF257864. |
|
| Автор: | miro_atc [ Чет Апр 11, 2013 9:47 am ] | ||||||||||||||||||
| Заглавие: | Re: Проблем със STM32-P103 (STM32F103RB) | ||||||||||||||||||
аз не виждам никакво "мацане"... По-скоро работиш с оптимизиран код и дебъгера не ти позиционира правилно сорса (нормално)... Подобен код се дебъгва само като гледаш асемблера и *него* изпълняваш стъпка по стъпка, а той е:
крайният резултат на тоя код е, че се вдига младшия бит на RCC_AHBENR, т.е. пуска се клока на DMA1. Просто не гледай къде дебъгера ти маркира сорса (не и когато работиш с оптимизиран код).... |
|||||||||||||||||||
| Автор: | Георги [ Пет Апр 19, 2013 5:04 pm ] |
| Заглавие: | Re: Проблем със STM32-P103 (STM32F103RB) |
Благодаря за съветите. Странния начин на изпълнение се е дължал на липсата на full assert. Основния проблем (грешката при повторно флашване ) се оказа че се дължи на DMA-то. DMA контролера осъществява достъп до една клетка от паметта , променлива която се заделя от компилатора на адрес на които той си прецени. При първото флашване това работи. При всяко следващо флашване или опит за достъп до паметта (прочитане, изтриване и т.н.) обаче се прави опит да се осъществи достъп до клетка от паметта която се ползва от DMA контролера. Този проблем явно трябва да се реши чрез промяна на настройките на DMA контролера. Понеже не ми се занимаваше с това просто заделих тази променлива на точно определен адрес (при ICCARM компилатора това става с @), т.е. налучках, след няколко опита, адрес от паметта който е описан в .icf файла на линкера като RAМ и в същото време не се ползва при флашването. И всичко работи. |
|
| Автор: | miro_atc [ Пет Апр 19, 2013 6:38 pm ] | ||||||||||||||||||
| Заглавие: | Re: Проблем със STM32-P103 (STM32F103RB) | ||||||||||||||||||
фул какво?
Този проблем се решава само по един начин - ресет скрипта на емулатора ти. Не може да оставиш пуснати DMA-та и да флашваш... ти няма и да можеш да дебъгваш като хората ако ти е разбутана периферията... Обикновено след конектване при всички М3 (изключая луминари) се ресетва всичко... Просто пишеш 0x05FA0007 на адрес 0xE000ED0C (NVIC -> Application Interrupt and Reset Control). При OpenOCD командичката трябва да е "mww 0xE000ED0C 0x05FA0007" само трябва да видиш в кой от конфигурационните файлове трябва да я сложиш... |
|||||||||||||||||||
| Страница 1 от 1 | Часовете са според зоната UTC + 2 часа [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|