WHILE

Cпасибо. Так заработало.

Здравствуйте. Не бей больно, моя первая попытка поработать с STM32. Никогда раньше не редактировал линкерные файлы, но вот понадобилось... Нужно во внутренней флэш-памяти STM32F051 создать для очень редко изменяемых калибровочных констант свою секцию. Для этого определяю в icf: define symbol __PAGE_SIZE_FLASH = 0x400; define symbol MY_EEP_start_adress = __ICFEDIT_region_ROM_end__ - __PAGE_SIZE_FLASH + 1; define region MY_EEP_region = mem:[from MY_EEP_start_adress to __ICFEDIT_region_ROM_end__]; place in MY_EEP_region {readonly section .iapMem}; do not initialize {section .iapMem}; export symbol __PAGE_SIZE_FLASH; export symbol MY_EEP_start_adress; в сpp. файле extern const uint32_t MY_EEP_start_adress; __no_init const uint16_t data_cal_adc[CH_ADC_MAX]@".iapMem"; Если судить по map-файлу, то вроде бы все создается : MY_EEP_start_adress {Abs} 0x800'fc00 "P3": place in [from 0x800'fc00 to 0x800'ffff] { ro section .iapMem }; Но в срр файл константа MY_EEP_start_adress передается как 0xFFFFFFFF. При попытке чтения uint16_t TFlash_Eep:: Read_Data (const uint32_t index) { return (*(__IO uint32_t*) (MY_EEP_start_adress + index)); } я падаю в хардфаулт. и проверочный printf("adr=%x\r\n", MY_EEP_start_adress); таки тоже выдает 0xFFFFFFFF. Где я лажанулся?

Извиняюсь за подъем старой темы, но я сейчас думаю над такой-же проблемой. Уважаемый Alechek, вы эту проблему как-то решили?

Присоединяюсь к Александру. Сравните с этой корейской писаниной mbed-овский стэк для WIZNET.

Я работал с W7500. Примеров с ним они дают вдвое меньше чем вы перечислили.Да и насчет прекрасной библиотеки и отлаженного кода у меня совсем другое впечатление сложилось. Сделано на отвяжись, и самое хреновое что написано все в жестком однопоточном варианте, который там просто прибит гвоздями. При работе с РТОС практически все надо переписывать.

Унутре W7500p неонка абсолютно стандартный кортекс М0. IAR кстати про W7500P ничего и не знает.Все компилируется в режиме ядро М0 + icf файл от производителя. Вы будете смеяться но TCP стэк я дернул таки из mbed, потому что тот софт что дают в качестве примеров корейцы совсем уж унылое гамно. Ну и да, варианты с двумя NV памятями с двумя-тремя-четырьмя копиями прошивки, имхо, перебор.

Спасибо, примерно понятно

Вы производителям железа совсем не доверяете? В частности errate? З.Ы. Встроенная собака в нем работает нормально. Да я и в AVR не жаловался...

2 Arlleex - а зачем из основного приложения деинить контроллер и перешивать. Установить признак во флэше и уйти на перезагрузку - а при старте смотреть кого стартовать-бутлоалер или рабочее приложение?

Народ, вся прелесть этой железки что эзернет железный и ресурсов практически не жрет-только буфер в ОЗУ для считывания принятого пакета из сокета.

Запускать обмен по ARP, устанавливать TCP-сессию и прочее-прочее - всё равно нужно. То что "унутри железный" - это наоборот минус. Когда обнаружится баг в нём железном, то исправить Вы его уже не сможете. Поэтому такое "железное" лучше не использовать. Ни ARP поддерживать, ни устанавливать TCP сессию на нем не надо. Все это реализует железка. Для TCP cервера надо поднять серверный сокет( прописать его MAC, IP и порт для прослушивания.И активировать парочку клиентских сокетов. Дальше или ручной опрос сокетов на наличие данных или включить прерывания.

Ну для моего контроллера это не проблема. IP стэк поднимать не надо, он унутри железный. Прием пакетов что по TCP, что по UDP занимает достаточно мало места.

Раздел " Embedded Flash memory" в даташите я как раз изучаю второй день. Уже даже сектор флэша стер-записал. Но от рабочего проекта "на посмотреть" я-бы тоже не отказался...

Т.е для загрузчика внешняя, а тем более энергонезависимая память в общем-то и не нужна. Нужно только только хранить признак что бутлодер уже стартовал и при перезагрузке надо стартовать в него, а н ев основное приложение? Которое возможно уже и потерто.

2 Arlleex. Самописная программа на РС начальству не очень понравится, я думаю. Но идею я понял, спасибо. Насколько устойчив ваш загрузчик к сбоям? Например, в процессе обновления произойдет отвал канала связи или бросок по питанию? Пакеты какого размера вы посылаете контроллеру? Равные одной секции флэша? И после приема храните их в ОЗУ контроллера или в энергонезависимой внешней памяти?