STM32 новичку в ARM что к чему

Reflector

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4060909#p4060909"]

RCC->AHBENR |= RCC_AHBENR_GPIOAEN | RCC_AHBENR_GPIOBEN; // for USART and LEDs
GPIOA->ODR = 0; // don't work without this!
GPIOB->MODER = GPIO_MODER_MODER0_O | GPIO_MODER_MODER1_O;

[/uquote]
Проверил, запись в MODER проходит только если перед ней хотя бы один NOP добавить, не важно от HSI тактироваться или от HSE+PLL. В общем-то ничего удивительного...

Добавлено after 3 minutes 58 seconds:
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4061437#p4061437"]Однако, фигвам! Несмотря на асмовские инструкции для FPU, МК "уходит в себя".[/uquote]
-mfpu=fpv4-sp-d16?

Реклама

iddqd

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4061539#p4061539"]Откуда ж я знаю: хардфолт там или нет? Даже если б я и хотел gdb запустить, ни один из этих 10МК не работает с SWD. Про это я уже писал: прошиваю через бутлоадер.[/uquote] Ну тогда завести в RAM флаг (магическое значение по известному адресу), в регионе RAM который бутлоадер не трогает (это важно). В обработчике hardfault и чего там - прописать желаемое значение как индикатор что это было. После этого запустить фирмвару, ресет, через бутлоадер слить RAM и посмотреть что в этом месте. Более продвинутый вариант: exec trace, несколько флагов для прохождения ключевых точек, заодно и readback всех интересных регистров рядом сложить заодно можно, и похрен что UART не работает! Когда нихрена не понятно на ранней инициализации, а дебагера под рукой нет, можно за 5 минут накодить это и через 10 получить ответ на интересовавшие вопросы ранней инициализации. Единственное условие - чтобы RAM можно было считать без ее порчи потом. Бутлоадер в ROM для этого удобен

. Дело в том что RESET# сам по себе RAM не сбрасывает, и содержимое кто-то должен явно вынести. Бутлоадер протирает только лимитированный регион которым он пользуется. Нормальная фирмвара обычно делает это в startup для получения стандартного окружения и реинициализации, но не обязана. С теми или иными вариациями, например можно делать флаги переживающие ребут, типа запроса активации своего бутлоадера после ребута и т.п.. Главное чтобы стартап их не грохал. Единственное что если hardfault сам падает, тогда будет уже именно deadlock. Проверить полный deadlock можно... ну, например, каким-нибудь IRQ типа systick'а и хранением счетчика накручиваемого им в известном месте. Если deadlock, счетчик как я понимаю застрянет. Если же умер только main thread, systick продолжит тикать и крутить счетчик. И ему довольно пофиг на живость всего остального, кроме разве что может быть стэка. И то можно обработчикам отдельный резерв стэка дать через MSP, ARM так умеет.

Что до проверки регистра, то без разницы: счётчик или содержимое регистра проверять.

Не согласен. Счетчик "однопортовый". Его читает и пишет только софт. Поэтому он целиком под контролем софта. Регистр "двухпортовый" - железо с 1 стороны, софт с другой. И если идея в том что таймаут ловит заскоки железа, ожидать конкретное поведение железки само по себе странная идея, а конкретно так можно при случае сделать очень странный TOCTOU срабатывающий не так как вы думали раз в 10 лет. Тут его вроде нет, но я бы 100% не дал, откуда я знаю как чип на самом деле может. Регистры, биты которых которых вы ждете - совершенно точно могут меняться железом.

А если регистр настроек меняется "сам по себе", то такой МК нужно выкинуть!

Довольно забавная идея сказать это, попутно ожидая пока железо ... само поменяет бит в регистре?! И оно совершенно точно меняет регистр, вы как раз именно этого и ждете.

Реклама

Eddy_Em

На 303 пока забил, есть более важные дела. Пытаюсь программно ввести STM32F042C6T6 в режим DFU. С 072 это на ура проходило, а вот с этим что-то затык вышел. Код такой:

Код: Выделить всё

#define SYSMEM03x 0x1FFFEC00
#define SYSMEM04x 0x1FFFC400
#define SYSMEM05x 0x1FFFEC00
#define SYSMEM07x 0x1FFFC800
#define SYSMEM09x 0x1FFFD800
// define SystemMem to other in MAKEFILE
#ifndef SystemMem
#define SystemMem SYSMEM04x
#endif

void Jump2Boot(){
    __disable_irq();
    void (*SysMemBootJump)(void);
    volatile uint32_t addr = SystemMem;
    // reset systick
    SysTick->CTRL = 0;
    // reset clocks
    RCC->APB1RSTR = RCC_APB1RSTR_CECRST    | RCC_APB1RSTR_DACRST    | RCC_APB1RSTR_PWRRST    | RCC_APB1RSTR_CRSRST  |
                    RCC_APB1RSTR_CANRST    | RCC_APB1RSTR_USBRST    | RCC_APB1RSTR_I2C2RST   | RCC_APB1RSTR_I2C1RST |
                    RCC_APB1RSTR_USART4RST | RCC_APB1RSTR_USART3RST | RCC_APB1RSTR_USART2RST | RCC_APB1RSTR_SPI2RST |
                    RCC_APB1RSTR_WWDGRST   | RCC_APB1RSTR_TIM14RST  |
#ifdef STM32F072xB
            RCC_APB1RSTR_TIM7RST   | RCC_APB1RSTR_TIM6RST |
#endif
                    RCC_APB1RSTR_TIM3RST   | RCC_APB1RSTR_TIM2RST;
    RCC->APB2RSTR = RCC_APB2RSTR_DBGMCURST | RCC_APB2RSTR_TIM17RST | RCC_APB2RSTR_TIM16RST |
#ifdef STM32F072xB
            RCC_APB2RSTR_TIM15RST |
#endif
                    RCC_APB2RSTR_USART1RST | RCC_APB2RSTR_SPI1RST  | RCC_APB2RSTR_TIM1RST  | RCC_APB2RSTR_ADCRST   | RCC_APB2RSTR_SYSCFGRST;
    RCC->AHBRSTR = 0;
    RCC->APB1RSTR = 0;
    RCC->APB2RSTR = 0;
    __DSB();
    // remap system flash memory to 0 (only for STM32F0)
    SYSCFG->CFGR1 = 0x01; __DSB(); __ISB();
    SysMemBootJump = (void (*)(void)) (*((uint32_t *)(addr + 4)));
    // set main stack pointer
    __set_MSP(*((uint32_t *)addr));
    // jump to bootloader
    SysMemBootJump();
}

По идее, по адресу 0x1FFFC400 должен переходить. А фигвам!!! МК настоящие, не паленые, купленные у доверенного поставщика года четыре назад. МК нулевый, т.е. в options bytes не может быть мешающего мусора. Если boot0 перед включением питания кидаю на +3.3В, в DFU выходит.
В интернетах аналогичный код у людей. Вот как так может быть?

Eddy_Em

В общем, оказалось, что программно перевести F042 в DFU невозможно: там есть эдакий механизм контроля, который запрещает программный запуск DFU, если в первых 4 байтах флеша что-то есть. А стереть первую страничку и потом активировать DFU невозможно.
☹
Буду знать. Ну их нафиг, эти 042, когда 072 намного лучше, а по цене даже дешевле иной раз выходят!

Реклама

COKPOWEHEU

А я сейчас бьюсь над сходной задачей: прошивка gd32vf103 (risc-v), который прошиваться по JTAG не хочет (а по SWD и вовсе не умеет). Зато умеет через stm32flash по UART. Но поскольку прошивку писать буду я, никакой гарантии, что попадет в загрузчик, нет. Значит, надо его ресетить, отключать от USB и выставлять boot снаружи.
Получилось устройство на stm32f103 (то VF, это F, не путать!), которое прикидывается двумя UART'ами (не лишаться же отладки из-за кривого программирования!) плюс логикой для обычных GPIO на соответственно RESET, BOOT0 и релюшку D+/D-. Ну и раз все равно пилю самодельный прогамматор, можно добавить свистелок - независимое управление 16-ю выходами и аналоговый вход, которые работают через Custom-HID, а аналоговый вход еще и как микрофон 44 кГц.
Такое вот составное устройство: CDC + CDC + HID + Audio
Основная часть уже готова, осталось только правильно настроить переключение двух UART'ов, потому что иногда заклинивает в неправильном режиме.

Реклама

jcxz

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4065498#p4065498"]В общем, оказалось, что программно перевести F042 в DFU невозможно: там есть эдакий механизм контроля, который запрещает программный запуск DFU, если в первых 4 байтах флеша что-то есть. А стереть первую страничку и потом активировать DFU невозможно.[/uquote]И что? "запрещает программный запуск DFU из ROM", но никто не запрещает в своём ПО (которое уже во флешь) реализовать этот самый DFU. Тем более, что протокол простой.

Реклама

Matr0sk1n

Добрый день или мяу ) Подскажите пожалуйста по битбандингу в cortex m0. На 18 стр этой темы было обсуждение, но я так и не могу понять, как вычислить адрес. Не могу найти в патрохах дефайн SRAM_BB_BASE. Помогите пожалуйста понять как прописать формулу дла автоматического вычисления адреса. Заранее спасибо!

Reflector

[uquote="Matr0sk1n",url="/forum/viewtopic.php?p=4073905#p4073905"]Подскажите пожалуйста по битбандингу в cortex m0.[/uquote]
Битбандинг есть только у M3/M4, остальные или слишком урезанные или там уже кеш который с битбандингом плохо совместим.

Sergi

Может поможет
https://developer.arm.com/documentation ... it-banding

FreshMan

подскажите пожалуйста, как на оф. сайте скачать CooCox CoIDE ?
https://www.st.com/en/development-tools/coide.html

Мурик

С сайта ST не получится скачать, т. к. это не их продукт. У них размещена ссылка на сайт www.coocox.org откуда качайте кокос.

FreshMan

[uquote="Мурик",url="/forum/viewtopic.php?p=4075240#p4075240"]С сайта ST не получится скачать, т. к. это не их продукт. У них размещена ссылка на сайт http://www.coocox.org откуда качайте кокос.[/uquote]

я почемуто не могу зайти на этот сайт ....
вы свободно заходите ?

Reflector

[uquote="FreshMan",url="/forum/viewtopic.php?p=4075279#p4075279"]я почемуто не могу зайти на этот сайт ....[/uquote]
Возможно потому, что на сайте ST про данный продукт написано Out of Production...

Мурик

FreshMan писал(а):не могу зайти на этот сайт....
вы свободно заходите?

Я кокосом вообще не пользуюсь.
Для STM32 мне хватает EmBitz у которого список поддерживаемых контролеров намного шире чем у кокоса https://rutracker.org/forum/viewtopic.php?t=6081172

Если нужен кокос, скачайте его с другого сайта.

Dimon456

Мурик, как у этого EmBitz при отладке отобразить хотя бы регистры, не говоря уже о переменных и т.п.?

FreshMan

[uquote="Мурик",url="/forum/viewtopic.php?p=4075290#p4075290"]

FreshMan писал(а):не могу зайти на этот сайт....
вы свободно заходите?

Я кокосом вообще не пользуюсь.
Для STM32 мне хватает EmBitz у которого список поддерживаемых контролеров намного шире чем у кокоса https://rutracker.org/forum/viewtopic.php?t=6081172

Если нужен кокос, скачайте его с другого сайта.[/uquote]
в чем преимущества этой среды по сравнению с тем же кубиком ?

Eddy_Em

[uquote="FreshMan",url="/forum/viewtopic.php?p=4075470#p4075470"]с тем же кубиком ?[/uquote]
Да тупо писать код cat > file.c будет лучше, чем в долбаном калокубе!

FreshMan

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4075508#p4075508"][uquote="FreshMan",url="/forum/viewtopic.php?p=4075470#p4075470"]с тем же кубиком ?[/uquote]
cat > file.c[/uquote]
можна сформулировать вашу мысл проще, для менее посвященных ?

a797945

просто в блокноте - т.е. без иде.

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

Мурик

Dimon456 писал(а):Мурик, как у этого EmBitz при отладке отобразить хотя бы регистры, не говоря уже о переменных и т.п.?

На рутрекере есть скрин

Спойлер

В окне Watches отображаются переменные. В окне System Registers - регистры.
Оба окна открываются из меню Debug -> Debugging windows.

FreshMan писал(а):в чем преимущества этой среды по сравнению с тем же кубиком

Не на эклиспе и работает намного быстрее и менее требовательная к железу.

FreshMan писал(а):можна сформулировать вашу мысл проще, для менее посвященных

Перевожу то что хотел сказать Eddy_Em.

Выбросьте на**ен винду и поставьте Linux.
Выбросьте все IDE и отладчики. Пользуйтесь исключительно makefile.
В терминале наберите cat > file.c