Значи имам постановка от два микроконтролера (STM32), вързани през изолиран UART (2 жици RX,TX). Единия е мастер другия е слейв, като освен UART-а имам и Reset линия от мастера към слейва.

Та идеята е мастера да може да ъпгрейдне фирмуера на слейва. Възможностите са:

1. Да пиша мой бутлоадер, който да се активира по серийния канал. Честно казано основния проблем тук е че не ми се занимава.
2. Да ползвам вградения, ама как да го активирам:
2.1 Да го викам софтуерно от моя код - ще се наложат една камара софтуерни еквилибристики. Най вече заради това, че в юзерския код трябва да има части обслужващи бутлоадера, а това не ми харесва. Щото при проблем с юзерския код, може да се стигне до там, че да не може и да се активира бутлоадера, т.е. да умре устройството при клиента.

2.2. Да го активирам хардуерно. Чипа си има заложен пин който се сканира след рисет и ако е 1, тръгва бутлоадера, иначе юзеркода. Сега проблема е, че нямам свободна линия между двата контролера да бъзикам тоя пин. И ми дойде щурата идея - да вържа TX (посока мастер-слейв) на тоя пин. Така ако искам да ъпдейтвам, активирам си UART-а на мастера (това ще вдигне TX в 1) и правя рисет. Слейва ще тръгне в бутлоадер режим и си наливам фирма. Ако искам да тръгне нормално, правя TX на мастера в 0, рисетвам, чакам там някакво време и после пускам нормално UART-a на мастера.

На идея ми изглежда като да работи. Ама не съм го пробвал. Някой да е пробвал подобни щуротии? Един потенциален проблем е какво прави този пин в останалото време след рисет. Нищо не пише в дейта шита - само че се сканира след ресет. Ако нищо не прави - е ОК.

Не го познавам добре Mr. STM32, затова говоря малко наизуст ...
Свързваш този пин с още едно GPIO. Връзката към TxD я правиш през резистор. При активен RESET GPIO е вход ( дай Боже ! ) и не пречи. След като свалиш RESET, твоят софтуер трябва да вдигне GPIO в 1 и да го направи изход. От този момент нататък входът ще се чете като 1. След още малко пауза "за страх" можеш да започнеш да предаваш. Ако може да стане, Slave да предаде нещо, когато си вдигне GPIO, така че Master да знае кога е готов.
Надявам се, че когато решеиш да ползваш BootLoader-а, той няма да пипа това GPIO.

Не съм сигурен, че разбирам съвсем какво искаш да кажеш. Защо ми е да свързвам още едно GPIO от към мастера???

Идеята е когато искам да запаля слейва в бутлоадерен режим - прости си конфигурирам порта като UART TX, това ще го вдигне в 1, реципрочно откъм слейва на RX и пина за селекция ще отиде тая 1-ца. Релисвам рисета на слейва и съм готов направо да предавам данни към бутлоадера на слейва.

Ако искам да го запаля в юзер режим, правя UART TX на мастера на нормално GPIO и го ръгам в 0. Релисвам ресета, слейва си запалва в нормален режим. След малко време да съм сигурен, че слейва е запалил, си конфигурирам порта на мастера като UART TX, той си отива в 1-ца и си почвам нормална комуникация.

Е може да има малък проблем откъм слейва, че като запали в нормален режим, на RX ще има за малко 0 и после ще мине в 1, ще го прочете като фрейм еррор неговия UART, ама това се лекува софтуерно.

Не сме се разбрали - на Slave се прави този номер, за да си удържиш пина за вкл на бутлоадера в 1.

Е ако е от към слейва:


1. За да може слейва сам да си държи пина, трябва някакъв софтуер да запали след рисет. Ако е юзерския софт - полза никаква, аз искам да се ръгна направо в бутлоадера. Ако е бутлоадера - той си е в РОМ-а, няма как да го накарам да върши каквото и да е.

2. Не мога да схвана какви дивиденти ще ми донесе това? Аз пина ще го държа в 1-ца насилствено откъм мастера.

Може да е за безумни идеи... ама... Вкарваш и държиш в ресет слейва (дано пиновете му са входове в тоя случай). Преконфигурираш на мастера пиновете на UART-a и по единия пускаш клок а по другия данни... От към слейва някакъв малък контролер 6-8 краков (който се активира да чете от RESET-a) почва да ги приема и като приеме правилната комбинация вдига в 1-ца въпросния пин на слейва. Ако искаш да си 100% сигурен, че си го задействал може тоя малкия контролер да го направиш да ти върне обратно някаква контрола и като я приемеш освобождаваш ресет-а, малкия задържа още известно време сетнат изхода си в 1-ца и я сваля в 0-ла, връщаш си конфига на UART-a и натам ясно... То и с насипна логика може да стане, ама ще е по-голяма играчка...

Не съм забелязал да има проблем. Примерния софтуер от ST за зареждане през RS има опция, да стартира програмата след зареждане, и съм я ползвал. След презареждане, на узерския софтуера му се предава управления и той работи без да се сменя потенциала на пина. Ако е необходимо ново зареждане, само се ресетва и отново е в ботлоадер.

Аз съм правил такива гимнастики с Кортекс на Луминари само че по CAN интерфвйса, ама всичко ставаше с команди и мой си боотлоадер. Имах една външна памет в която тъпчех новия код, после записвах на определено място в нея определена стойност и ресетвах слейв процесора софтуерно и той като тръгне си проверяваше въпросния байт във външната памет и ако с определената стойност си ъпдейтваше фърмуера, нулираше байта и се ресетваше пак. И си работеше безгрижно доста време, даже после го направих същото само че през GPRS връзка. Ама така ти трябва външна памет и твой си боотлоадер .
ПП. Опаа, сега видях, че ти реално нищо не искаш да пишеш и да променяш, а ако може да стане автоматично .

Аха де. Ако искам да го направя по сложния начин, ясно има 1001 варианта. Аз ще пробвам да го направя мързеливо, т.е да не правя почти нищо

А какво става, когато двата процесора работят нормално - в юзърски режим, Тх на мастера ти е в "1" (съответноо пина на слейв процесора за активиране на бутлоудера е активен) и примерно браун аут или WDT ресет ти ресетнат само слейв процесора ? Дали след това той няма да се окаже в бутлоудерски режим ?

Провери дали след браун аут или WDT ресет може слеив процесора ти да влезе в бутлоудерски режим. Ако е така - идеята ти е неработеща.

Не съм писал STM32, но подобен проблем съм решавал с просто CRC16 върху целия юзерски код, bootloader-а винаги се изпълнява в началотои проверява въпросния CRC дали съвпада с този на кода. CRC го лепвам винаги в края на code space и го драскам от самия чип при правилно флашване. Доста опити съм правил да го счупя и не съм успявал... А ако юзерския код е лесно-трошим, примерно има опасност да зацикли, може да се остави един pin, който да force-ва boot режим при reset.

Какво прави пина след като тръгне процесора - ми нищо не прави. Мога да си го клатя колкото си искам. Пробвах...
Все тая...

По интересно е какво прави, след друг тип ресет - ама и това може да се провери сигурно.

Иначе идеята ми е следната - разбах че има и ресет към слейв процесора. Ми тогава най-добре някаква елементерна логика, ма то май най-добре едно конреолерче, 6 пиново примерно, което също да гледа ресета и ТХ идващи от мастера. Докато мастера дава ресет на слеива - на това контролерче през ТХ му се казва как да държи пина при махане на ресета. Нещо такова...

В общи линии идеята е ресета да помаха и той в цялата постановка.

Че клатенето на пина за влизане в BOOT режим след като мине ресета на процесора не пречи на работата му - Цецо го е написал. Нещо повече - вързал го е към Rx пина на въпросния процесор и следователно към Tx пина на мастер процесора. Лошото в случая е, че Tx-а на мастера държи този сигнал нормално в "1" (когато няма комуникация между процесорите) и трябва да се види дали WDT или браунаут ресет на слеив процесора няма да го вкара НЕЖЕЛАНО в бутлоуд режим.

От опита ми с други процесори не ми е известно как самия пеоцесор може да си провери дали е в бутлоудерски режим. В случая говорим за хардкоднатия бутлоудер в процесора, а не за писан бутлоудер от потребителя.

Ситуацията може да се хване, ако мастера периодично полира слеив процесора и примерно го разпитва за статуса му. Ако слеив проц-а е изпаднал в бутлоуд режим - няма да отговори на заявката за статуса на мастера и мастера ще го ресетира и вкара в нормален режим. Не че не става, ама това ми изглежда много дървеняшко, а и не винаги е приложимо. Зависи от приложението и конкретния случай ... Цецо си знае най-добре

А идеята да сложим допълнително още един, а защо не два и повече процесори ми изглежда като шега

@emilvtc - мислим в една посока явно На мен лично дървеняшкото решение ми допада, ама още не мога да осмисля какви неприятности ще ми донесе в бъдеще.

@juzisound - какъв допълнителен контролер или логики бе човек Говорим за най-оптималното решение, не за най-мазохистичното.

@Predator - решението ти при всички положения включва юзерски код който трябва винаги да е в процесеора. Това е равносилно да си напиша сам бутлоадера (или да правя преход към вградения или нещо от сорта). Нищо лошо. Проблема на такова решение е, че при рефлашване, винаги има една част от паметта която грантирано трябва да е защитена от потребителя. И ако нещо се случи с тази част, устройството е мъртво. Шанса да и се случи нещо е минимален естествено. Ако се вземат достатъчно мерки, юзера не би трябвало да може да я прецака, ако приемем и че самия код няма пробойна с която да се самопрецака.... Остава възможността да се самозатрие флаша... абе решението си е екстра.

От опит знам, че писането на бутлоадер не е проблем като софтуер, а в това да предвидиш всички възможни проблеми и дупки. Идеята на бутлоадера е да код лишен от грешки, защото той не може да се поправи, за разлика от юзерския код. А да напишеш и 2К код бъг фрии си е предизвикателство, щото имаш комуникация, писане на флаш, абе въобще купчина код, където можеш да си самозаложиш капан. А после като иде на другия край на света и светне проблема в бутлоадера.... си ..... майката.

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

Аз от бутлоадера сменях потребителския код, а от потребителския код можех да сменям бутлоадера .