Сделал новую ревизию платы, в части МК изменилось только, что BOOT1 теперь идет на EN вход внешнего DC/DC. Вроде бы не должно никак мешать, когда контроллер в сбросе или загрузчике BOOT1 притянут к земле резистором 10К.
Однако, теперь после загрузки кода по USART через встроенный загрузчик, происходит странное. Сразу после загрузки МК работает как должно. Если снять питание и снова подать, то поведение как у чистого МК со стертым флешем. Но если не дергая питания, перейти в загрузчик сделав BOOT0=1 и сброс а затем (ничего на загружая) вернуть BOOT0=0 и снова сделать сброс, то стартует прошитый ранее код из флеш. Один только сброс не помогает.
Похоже, на то, что я что-то недоиницилизирую, но и здесь я изменял только настройки тактирования под новую частоту кварца. И раньше такого не было никогда.
Пробовал зажигать светодиоды перед всей инициализацией, прямо в обработчике reset прерывания. Ничего не увидел, даже туда не доходит.
Не знаю на что подумать, что проверить.
Полная версия этой страницы: Не стартует STM32F405
Цитата(amaora @ Jun 25 2017, 22:29) 
Не знаю на что подумать, что проверить.
Может, попробовать как-то переформулировать вопрос и отказаться от нетехнической терминологии?
Будто вы описываете процесс загрузки кода в ОЗУ, и МК соответствующим образом себя ведет.
Пока проблема не видна и не понятна.
Кажется, внутренний pull-down это особенность BOOT0, про BOOT1 никто не обещал...
Ну не бывает чудес.
" Если снять питание и снова подать…" ядро успевает зафиксировать "1" на Boot0 (это быстро - 4 такта SYSCLK): явно в обвеске "залипуха".
" Если снять питание и снова подать…" ядро успевает зафиксировать "1" на Boot0 (это быстро - 4 такта SYSCLK): явно в обвеске "залипуха".
Цитата(adnega @ Jun 25 2017, 23:40)
Может, попробовать как-то переформулировать вопрос и отказаться от нетехнической терминологии?
Будто вы описываете процесс загрузки кода в ОЗУ, и МК соответствующим образом себя ведет.
Пока проблема не видна и не понятна.
Будто вы описываете процесс загрузки кода в ОЗУ, и МК соответствующим образом себя ведет.
Пока проблема не видна и не понятна.
Код есть во flash, но при подаче питания он не запускается. Если зайти в загрузчик и выйти, то начинает запускаться, все становится нормально.
Цитата
Кажется, внутренний pull-down это особенность BOOT0, про BOOT1 никто не обещал...
На обоих выводах есть резисторы на землю, по 10К.
Цитата
Ну не бывает чудес.
" Если снять питание и снова подать…" ядро успевает зафиксировать "1" на Boot0 (это быстро - 4 такта SYSCLK): явно в обвеске "залипуха".
" Если снять питание и снова подать…" ядро успевает зафиксировать "1" на Boot0 (это быстро - 4 такта SYSCLK): явно в обвеске "залипуха".
Тогда МК был бы в загрузчике, а он в этом состоянии не отвечает по USART.
Может быть не надо было в воздухе оставлять NJTRST? Как это может повлиять?
Добавка: Похоже что-то программное, т.к. вижу, что запускается генерация на OSC_IN/OSC_OUT, если стереть flash то этого нет. Есть разница от того как собрать исходники, с -flto или без. Без не работает уже никак, что странно.
Посмотрел через отладку по SWD, что там происходит. В зависимости от того как собрать ломается в разных местах. Например с теми настройками, что я обычно использую (-O2 -flto), падаем в коде FreeRTOS, а именно в prvPortStartFirstTask.
То есть прочитали из SCB->VTOR какую-то непонятную 0xbfa91300, хотя там должно быть 0x8000000. Я даже вручную это туда записываю в коде инициализации, который к этому моменту уже выполнен.
Начал разбираться, что там на самом деле пишется в тот VTOR, оказалось именно тот мусор вместо начала flash. Дальше заменил строку,
запускаю и получаю,
Как вот так может быть? Наверно уже устал, надо еще раз самому это перечитать. Да, все верно, только дальше продолжает падать, но теперь уже иначе, корректного указателя стека нет, стало сложнее. На этот раз где-то в pvPortMalloc, точнее определить сложно, надо глазами анализировать код и содержимое стека.
Может это GCC, я его недавно обновлял на 6.3.0.
Код
static void prvPortStartFirstTask( void )
{
__asm volatile(
" ldr r0, =0xE000ED08 \n" /* Use the NVIC offset register to locate the stack. */
" ldr r0, [r0] \n"
" ldr r0, [r0] \n"
" msr msp, r0 \n" /* Set the msp back to the start of the stack. */
" cpsie i \n" /* Globally enable interrupts. */
" cpsie f \n"
" dsb \n"
" isb \n"
" svc 0 \n" /* System call to start first task. */
" nop \n"
);
}
{
__asm volatile(
" ldr r0, =0xE000ED08 \n" /* Use the NVIC offset register to locate the stack. */
" ldr r0, [r0] \n"
" ldr r0, [r0] \n"
" msr msp, r0 \n" /* Set the msp back to the start of the stack. */
" cpsie i \n" /* Globally enable interrupts. */
" cpsie f \n"
" dsb \n"
" isb \n"
" svc 0 \n" /* System call to start first task. */
" nop \n"
);
}
Код
Breakpoint 2, 0x08004158 in prvPortStartFirstTask.lto_priv.84 () at freertos/port.c:490
490 }
(gdb) disassemble
Dump of assembler code for function prvPortStartFirstTask.lto_priv.84:
0x08004154 <+0>: ldr r0, [pc, #476]; (0x8004334)
0x08004156 <+2>: ldr r0, [r0, #0]
=> 0x08004158 <+4>: ldr r0, [r0, #0]
0x0800415a <+6>: msr MSP, r0
0x0800415e <+10>: cpsie i
0x08004160 <+12>: cpsie f
0x08004162 <+14>: dsb sy
0x08004166 <+18>: isb sy
0x0800416a <+22>: svc 0
0x0800416c <+24>: nop
End of assembler dump.
(gdb) info registers
r0 0xbfa91300 -1079438592
r1 0xf00000 15728640
...
490 }
(gdb) disassemble
Dump of assembler code for function prvPortStartFirstTask.lto_priv.84:
0x08004154 <+0>: ldr r0, [pc, #476]; (0x8004334)
0x08004156 <+2>: ldr r0, [r0, #0]
=> 0x08004158 <+4>: ldr r0, [r0, #0]
0x0800415a <+6>: msr MSP, r0
0x0800415e <+10>: cpsie i
0x08004160 <+12>: cpsie f
0x08004162 <+14>: dsb sy
0x08004166 <+18>: isb sy
0x0800416a <+22>: svc 0
0x0800416c <+24>: nop
End of assembler dump.
(gdb) info registers
r0 0xbfa91300 -1079438592
r1 0xf00000 15728640
...
То есть прочитали из SCB->VTOR какую-то непонятную 0xbfa91300, хотя там должно быть 0x8000000. Я даже вручную это туда записываю в коде инициализации, который к этому моменту уже выполнен.
Начал разбираться, что там на самом деле пишется в тот VTOR, оказалось именно тот мусор вместо начала flash. Дальше заменил строку,
Код
//SCB->VTOR = (unsigned long) &ldSvectors;
SCB->VTOR = (unsigned long) 0x80000000;
SCB->VTOR = (unsigned long) 0x80000000;
запускаю и получаю,
Код
0x0800be28 <+156>: ldr r4, [pc, #108]; (0x800be98 <halStart+268>)
0x0800be2a <+158>: add r2, pc
0x0800be2c <+160>: mov.w r6, #2147483648; 0x80000000
0x0800be30 <+164>: str r0, [r2, #0]
0x0800be32 <+166>: ldr.w r0, [r3, #136]; 0x88
0x0800be36 <+170>: ldr r2, [pc, #100]; (0x800be9c <halStart+272>)
0x0800be38 <+172>: orr.w r0, r0, #15728640; 0xf00000
=> 0x0800be3c <+176>: str.w r0, [r3, #136]; 0x88
0x0800be40 <+180>: str r6, [r3, #8]
0x0800be42 <+182>: ldr r0, [r3, #12]
0x0800be44 <+184>: movw r6, #63743; 0xf8ff
0x0800be48 <+188>: ands r0, r6
0x0800be4a <+190>: orrs r2, r0
0x0800be4c <+192>: str r2, [r3, #12]
0x0800be4e <+194>: ldr r3, [r5, #0]
0x0800be50 <+196>: orr.w r3, r3, #240; 0xf0
0x0800be54 <+200>: str r3, [r5, #0]
0x0800be56 <+202>: ldr r3, [r1, #48]; 0x30
0x0800be58 <+204>: orr.w r3, r3, #7
0x0800be5c <+208>: str r3, [r1, #48]; 0x30
0x0800be5e <+210>: ldr r3, [r4, #0]
0x0800be60 <+212>: bic.w r3, r3, #64512; 0xfc00
0x0800be64 <+216>: orr.w r3, r3, #21504; 0x5400
0x0800be68 <+220>: str r3, [r4, #0]
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) si
155 SCB->VTOR = (unsigned long) 0x80000000;
1: *((int* ) 0xE000ED08) = 0
(gdb) si
NVIC_SetPriorityGrouping () at hal/cmsis/core_cm4.h:1467
1467 reg_value = SCB->AIRCR; /* read old register configuration */
1: *((int* ) 0xE000ED08) = -2147483648
(gdb)
(gdb) info registers
r0 0xf00000 15728640
r1 0x40023800 1073887232
r2 0x5fa0300 100270848
r3 0xe000ed00 -536810240
r4 0x40020400 1073873920
r5 0x40007000 1073770496
r6 0x80000000 -2147483648
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x1000fff4 0x1000fff4
lr 0x800bf6f 0x800bf6f <ccmComp+8>
pc 0x800be42 0x800be42 <halStart+182>
xpsr 0x61000000 1627389952
fpscr 0x0 0
msp 0x1000fff4 0x1000fff4
psp 0x0 0x0
special 0x0 0
0x0800be2a <+158>: add r2, pc
0x0800be2c <+160>: mov.w r6, #2147483648; 0x80000000
0x0800be30 <+164>: str r0, [r2, #0]
0x0800be32 <+166>: ldr.w r0, [r3, #136]; 0x88
0x0800be36 <+170>: ldr r2, [pc, #100]; (0x800be9c <halStart+272>)
0x0800be38 <+172>: orr.w r0, r0, #15728640; 0xf00000
=> 0x0800be3c <+176>: str.w r0, [r3, #136]; 0x88
0x0800be40 <+180>: str r6, [r3, #8]
0x0800be42 <+182>: ldr r0, [r3, #12]
0x0800be44 <+184>: movw r6, #63743; 0xf8ff
0x0800be48 <+188>: ands r0, r6
0x0800be4a <+190>: orrs r2, r0
0x0800be4c <+192>: str r2, [r3, #12]
0x0800be4e <+194>: ldr r3, [r5, #0]
0x0800be50 <+196>: orr.w r3, r3, #240; 0xf0
0x0800be54 <+200>: str r3, [r5, #0]
0x0800be56 <+202>: ldr r3, [r1, #48]; 0x30
0x0800be58 <+204>: orr.w r3, r3, #7
0x0800be5c <+208>: str r3, [r1, #48]; 0x30
0x0800be5e <+210>: ldr r3, [r4, #0]
0x0800be60 <+212>: bic.w r3, r3, #64512; 0xfc00
0x0800be64 <+216>: orr.w r3, r3, #21504; 0x5400
0x0800be68 <+220>: str r3, [r4, #0]
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) si
155 SCB->VTOR = (unsigned long) 0x80000000;
1: *((int* ) 0xE000ED08) = 0
(gdb) si
NVIC_SetPriorityGrouping () at hal/cmsis/core_cm4.h:1467
1467 reg_value = SCB->AIRCR; /* read old register configuration */
1: *((int* ) 0xE000ED08) = -2147483648
(gdb)
(gdb) info registers
r0 0xf00000 15728640
r1 0x40023800 1073887232
r2 0x5fa0300 100270848
r3 0xe000ed00 -536810240
r4 0x40020400 1073873920
r5 0x40007000 1073770496
r6 0x80000000 -2147483648
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x1000fff4 0x1000fff4
lr 0x800bf6f 0x800bf6f <ccmComp+8>
pc 0x800be42 0x800be42 <halStart+182>
xpsr 0x61000000 1627389952
fpscr 0x0 0
msp 0x1000fff4 0x1000fff4
psp 0x0 0x0
special 0x0 0
Как вот так может быть? Наверно уже устал, надо еще раз самому это перечитать. Да, все верно, только дальше продолжает падать, но теперь уже иначе, корректного указателя стека нет, стало сложнее. На этот раз где-то в pvPortMalloc, точнее определить сложно, надо глазами анализировать код и содержимое стека.
Может это GCC, я его недавно обновлял на 6.3.0.
Цитата(amaora @ Jun 25 2017, 23:29)
Сделал новую ревизию платы, в части МК изменилось только, что BOOT1 теперь идет на EN вход внешнего DC/DC. Вроде бы не должно никак мешать, когда контроллер в сбросе или загрузчике BOOT1 притянут к земле резистором 10К.
Может начать с самого начала?
Предполагаю, что на старой ревизии платы всё работало.
Осциллографом посмотреть сигнал BOOT1, Посмотреть документацию на DC/DC, нет ли там на входе ENABLE pull-up резистора, который пересиливает Ваши 10к.
По симптомам очень похоже, что при сбросе через отладчик сигнал не успевает подняться от нулевого уровня из за емкости дорожки и всё работает. А при подаче питания BOOT1 уже равен 1.
Цитата(amiller @ Jun 27 2017, 08:17)
Может начать с самого начала?
Не надо…
"Во всём виноваты программисты"
а у ТС всё в порядке.
Перешел на GCC 7.1.0, попробовал разные варианты оптимизации, ничего не меняется. Сейчас постоянно падает при запуске из GDB. В пределах одной сборки падает стабильно в одном месте.
Похоже неполадки в freertos/heap_4.c, pvPortMalloc возвращает некорректные адреса. Но как здесь вход в загрузчик мог повлиять непонятно. Все очень странно. Да и от чего бы этому коду сломаться.
Как можно здесь прочитать в uxAddress нулевое значение? Но получается именно так если верить GDB, с этого начинаются проблемы.
Похоже неполадки в freertos/heap_4.c, pvPortMalloc возвращает некорректные адреса. Но как здесь вход в загрузчик мог повлиять непонятно. Все очень странно. Да и от чего бы этому коду сломаться.
Код
extern uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
...
static void prvHeapInit( void )
{
BlockLink_t *pxFirstFreeBlock;
uint8_t *pucAlignedHeap;
size_t uxAddress;
size_t xTotalHeapSize = configTOTAL_HEAP_SIZE;
/* Ensure the heap starts on a correctly aligned boundary. */
uxAddress = ( size_t ) ucHeap;
if( ( uxAddress & portBYTE_ALIGNMENT_MASK ) != 0 )
{
uxAddress += ( portBYTE_ALIGNMENT - 1 );
uxAddress &= ~( ( size_t ) portBYTE_ALIGNMENT_MASK );
xTotalHeapSize -= uxAddress - ( size_t ) ucHeap;
}
...
...
static void prvHeapInit( void )
{
BlockLink_t *pxFirstFreeBlock;
uint8_t *pucAlignedHeap;
size_t uxAddress;
size_t xTotalHeapSize = configTOTAL_HEAP_SIZE;
/* Ensure the heap starts on a correctly aligned boundary. */
uxAddress = ( size_t ) ucHeap;
if( ( uxAddress & portBYTE_ALIGNMENT_MASK ) != 0 )
{
uxAddress += ( portBYTE_ALIGNMENT - 1 );
uxAddress &= ~( ( size_t ) portBYTE_ALIGNMENT_MASK );
xTotalHeapSize -= uxAddress - ( size_t ) ucHeap;
}
...
Как можно здесь прочитать в uxAddress нулевое значение? Но получается именно так если верить GDB, с этого начинаются проблемы.
Была подобная ситуация, только такое поведение наблюдалось когда BOOT1 был затянут в 1 (system memory), но ПО запускал через отладку, причина была в срабатывании необрабатываемого прерывании.
ИМХО, причина не в компиляторе, я бы на Вашем месте залогировал все обработчики прерываний, даже те которые не используете, и те которые не маскируемые.
Возможно Вы эти этапы уже прошли, но я бы прошелся по следующим шагам:
1. Временно выключил основной функционал прошивки, оставить только светодиодную индикацию, чтобы понимать, что ПО работает, частотой моргания диода подтвердить рабочую частоту. Если на плате нет диода, дергаем какой-либо пин, контролируем его каким либо осцилоскопом.
2. Зашить и проверить работоспособность ПО на первом устройстве, рабочем устройстве!
3. Зашить второе устройство убедиться в НЕ работоспособности.
3.1 Если вдруг случайно заработает, добавляем пошагово необходимый функционал, ищем причину.
4. Если Вы пишите что добавлен только резистор, чтобы убедиться что проблема в нем, демонтировав его, порезать линию управления EN (DC\DC)
4.1 Резистора нет, но ПО НЕ грузится искать другие отличия в схеме.
5. Без резистора ПО грузится? Снять и опубликовать на форуме осциллограммы сигналов: питание, reset, boot1.
ИМХО, причина не в компиляторе, я бы на Вашем месте залогировал все обработчики прерываний, даже те которые не используете, и те которые не маскируемые.
Возможно Вы эти этапы уже прошли, но я бы прошелся по следующим шагам:
1. Временно выключил основной функционал прошивки, оставить только светодиодную индикацию, чтобы понимать, что ПО работает, частотой моргания диода подтвердить рабочую частоту. Если на плате нет диода, дергаем какой-либо пин, контролируем его каким либо осцилоскопом.
2. Зашить и проверить работоспособность ПО на первом устройстве, рабочем устройстве!
3. Зашить второе устройство убедиться в НЕ работоспособности.
3.1 Если вдруг случайно заработает, добавляем пошагово необходимый функционал, ищем причину.
4. Если Вы пишите что добавлен только резистор, чтобы убедиться что проблема в нем, демонтировав его, порезать линию управления EN (DC\DC)
4.1 Резистора нет, но ПО НЕ грузится искать другие отличия в схеме.
5. Без резистора ПО грузится? Снять и опубликовать на форуме осциллограммы сигналов: питание, reset, boot1.
В любом электротехникуме есть предмет на первом курсе - Поиск неисправностей в электрических устройствах. Записаться и прослушать его. Или посмотреть на youtub'e.
В конце июня (; актуальный совет, особенно участникам с '08 или '09.
Причина все таки в компиляторе, точнее в моем его непонимании. Новые версии зачем-то собирают PIC код, хотя я указываю -static. Появились новые секции, .got и .got.plt, а я их не обработал в ld скрипте. Была не инициализированная память.
Но зачем это все? Не понимаю, я же не shared object собираю.
Но зачем это все? Не понимаю, я же не shared object собираю.
Новые версии GCC были собраны с --enable-default-pie, в этом была причина. Всем спасибо.
amaora, Вы их где берёте?
Вроде б на launchpad'е всё тихо и спокойно (а 7-й версии нет совсем).
Вроде б на launchpad'е всё тихо и спокойно (а 7-й версии нет совсем).
Цитата(esaulenka @ Jul 3 2017, 10:35)
amaora, Вы их где берёте?
Вроде б на launchpad'е всё тихо и спокойно (а 7-й версии нет совсем).
Вроде б на launchpad'е всё тихо и спокойно (а 7-й версии нет совсем).
В Gentoo есть такой пакет crossdev, который помогает собрать любой кросскомпилятор, в пределах возможностей GCC. Впрочем, для перехода на новую (или старую) версию он уже и не нужен, это происходит само при общем обновлении системы.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.