[E-sys 0]

Здравствуйте!

Имеется конечное изделие, которое продаётся мелкими сериями. Чип управления  - STM32F103VET6. Требуется помощь во внесении правки в исходный код прошивки. В данный момент устройство полностью функционально, однако в отдельных блоках необходима коррекция для более стабильной работы. Что именно нужно, опишу в почте или личке. Устройство программируется в IAR Embedded Workbench for ARM  ver.6.40.2.3992 (или 6.30.6.3387) ,  других вариантов не предоставили.

Мы находимся в Москве, м. Электрозаводская. Работа, вероятнее всего, разовая, удалённая. Упор пока делаем именно на консультацию. Оплата по результатам беседы.

e-mail: [email protected]

[Lmx2315 2]

А о какой сумме идёт речь?

[jcxz 184]

37 минут назад, E-sys сказал:

коррекция для более стабильной работы

Эта фраза настораживает. 

Когда говорят такое, значит оно вроде работает, но.... иногда непонятно глючит. В таких случаях часто единственное лечение - полное переписывание всего софта.  

[iosifk 3]

7 минут назад, jcxz сказал:

Эта фраза настораживает. 

Когда говорят такое, значит оно вроде работает, но.... иногда непонятно глючит. В таких случаях часто единственное лечение - полное переписывание всего софта.  

Я присоединяюсь. И добавлю немного о трудоемкости проекта. Если представить, процесс отладки как апериодический переходный процесс, который стремится к 1, то грубо говоря 30% результата достигается за 1 постоянную времени, 60% за две и 95% за три постоянных времени. А вот чтобы отладить остальные 5%, хотя бы до уровня 99% потребуются десятки постоянных времени. Т.е. для начала нужно найти эти места, где "необходима коррекция для более стабильной работы". А это может быть надо искать "на объекте заказчика", а вовсе даже не на столе. Да еще возможно, что это как-то связано с чем-то, например с температурой. И оно вчера - было, а сегодня - уже нет. А завтра - возможно снова появится. 

Да еще и код может быть не документирован и нет описаний режимов работы... А чтобы разобраться тоже требуется время..

Поэтому речь не идет о том, что надо "поправить 20 строк кода"...

[AlexandrY 2]

15 minutes ago, jcxz said:

Эта фраза настораживает. 

Когда говорят такое, значит оно вроде работает, но.... иногда непонятно глючит. В таких случаях часто единственное лечение - полное переписывание всего софта.  

Тут не настораживать надо , а готовиться заново провести весь R&D.
Скажем сделали недостаточно робастный PID и при смене типа нагрузки или типа привода все пошло осциллировать в разнос.
Так тут стабильности добиваются заново проведя все исследования объекта управления и поиском новых эвристик. 
 

5 minutes ago, iosifk said:

 А вот чтобы отладить остальные 5%, хотя бы до уровня 99% потребуются десятки постоянных времени.

Да те 5% никогда не отлаживаются до конца. 
Потому что требования сторонним разработчикам пишутся с запасом выше границы технической реализуемости. 
Наверняка придется проц выбирать с большей частотой. 

[E-sys 0]

7 часов назад, iosifk сказал:

Я присоединяюсь. И добавлю немного о трудоемкости проекта. Если представить, процесс отладки как апериодический переходный процесс, который стремится к 1, то грубо говоря 30% результата достигается за 1 постоянную времени, 60% за две и 95% за три постоянных времени. А вот чтобы отладить остальные 5%, хотя бы до уровня 99% потребуются десятки постоянных времени. Т.е. для начала нужно найти эти места, где "необходима коррекция для более стабильной работы". А это может быть надо искать "на объекте заказчика", а вовсе даже не на столе. Да еще возможно, что это как-то связано с чем-то, например с температурой. И оно вчера - было, а сегодня - уже нет. А завтра - возможно снова появится. 

Да еще и код может быть не документирован и нет описаний режимов работы... А чтобы разобраться тоже требуется время..

Поэтому речь не идет о том, что надо "поправить 20 строк кода"...

Под более стабильной работой я понимаю способность прибора продолжать работу в случае возникновения сбоев. Переписывать весь код - это чересчур для нас. Прибор останавливает работу с выдачей конкретного кода ошибки. Мёртвого зависания не происходит. Часть ошибок он обходит и после исчезновения причин останова продолжает работу. Оставшийся список ошибок приводит к останову работы и необходимости оператора подойти к прибору, сбросить ошибку и заново запустить прибор. Задача, чтобы самостоятельно пополнять список ошибок, после которых прибор продолжит работу, не требуя вмешательства оператора.

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

[jcxz 184]

33 минуты назад, E-sys сказал:

Прибор останавливает работу с выдачей конкретного кода ошибки.

Приведите примеры ошибок.

 

Цитата

Прибор часто останавливается на ошибке, связанной с проверкой стэка.

Что???    И это Вы называете "полностью функциональное ПО"?  

 

PS: И куда делся создатель этого чудного ПО?

[E-sys 0]

1 час назад, jcxz сказал:

Приведите примеры ошибок.

 

Что???    И это Вы называете "полностью функциональное ПО"?  

 

PS: И куда делся создатель этого чудного ПО?

Вот строки из кода:

//OnlyStackCHeck:
            // проверка стэка
            // из последовательности, выполняемой в конце цикла, это - самое начало
            bkEN;
            setLastWT(SysTimeCounter_1ms);
            bkDIS;

            if (ckBounds()) my_exit(EXIT_RUN_LOOP);
            v = ChekPinControl();
            if (v != 0) { rc = v; goto M_CyEND; }
            /// если тут что-то из проверок добавиться,

По EXIT_RUN_LOOP происходит останов. Если закомментить эти строки, устройство вместо аварийного останова намертво зависает. Частота таких ошибок - от раз в 3-4 часа до раз в неделю, т.е. может работать круглыми сутками, а может и через 4 часа выпасть. От температуры и экземпляра платы не зависит. 

Про создателей ПО я считаю неуместно здесь говорить. 

[x893 35]

а код для ckBounds() есть ?

[Den64 0]

7 hours ago, E-sys said:

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

Это же не стек процессора? (в который запихиваются адреса при входе в подпрограмму и достаются при выходе из нее)

[jcxz 184]

6 часов назад, Den64 сказал:

Это же не стек процессора? (в который запихиваются адреса при входе в подпрограмму и достаются при выходе из нее)

На Cortex-M никакие адреса не запихиваются в стек "при входе в подпрограмму". Если что.

[haker_fox 60]

6 hours ago, Den64 said:

в который запихиваются адреса при входе в подпрограмму и достаются при выходе из нее

Не, для этого регистр LR предназначен.

[pyroman 2]

10 hours ago, jcxz said:

На Cortex-M никакие адреса не запихиваются в стек "при входе в подпрограмму". Если что. 

А как же вложенные подпрограммы?

[haker_fox 60]

2 minutes ago, pyroman said:

А как же вложенные подпрограммы?

Перед вызовом из функции другой функции регистр LR сохраняется в стэк. Именно содержимое регистра. По-сути это адрес, да, но основным является LR. Т.е. адрес возврата мы в стэк напрямую не пишем. А если речь идёт о прерывании, так в этом случае в LR пишется не адрес возврата, а специальное знчение EXC_RETURN. В нём указано куда возвращатся (основная программа или другое прерывание, тип стэка и т.п.).

[Aldec 0]

Если это влияние помех или киловатный честотник запускатся потребуется еще регистратор.
Пршивку вариант заменить линуксом с все висящие стэки и регитры завести через CS,