Флоаты в STM32F303

[VladislavS]

Сделать бинарь проверить железку? Какая частота кварца у тебя?

[Eddy_Em]

VladislavS писал(а):

Какая частота кварца у тебя?

8МГц. Да я подозреваю, что бинарь-то будет нормально работать. Это я где-то умудрился накосячить. Хоть выводи MCO для проверки… Но эта функция нормально завершается:

Код:

TRUE_INLINE int StartHSE(){ // system bus 72MHz from PLL
    __IO uint32_t StartUpCounter = 0;
#define WAITWHILE(x)  do{StartUpCounter = 0; while((x) && (++StartUpCounter < 0xffffff)){nop();}; if(x) return 0;}while(0)
    RCC->CR = (RCC->CR & ~RCC_CR_PLLON) | RCC_CR_HSEON; // disable PLL to reconfigure, enable HSE
    WAITWHILE(!(RCC->CR & RCC_CR_HSERDY));
    // Enable Prefetch Buffer. Flash 4 wait states for 48..72MHz
    FLASH->ACR = (FLASH->ACR & ~(FLASH_ACR_LATENCY)) |
            FLASH_ACR_LATENCY_2 | FLASH_ACR_PRFTBE;
    // HCLK = SYSCLK (AHB prescaler = 1), PCLK1 = HCLK (APB1 prescaler = 1), PCLK2 = HCLK (APB2 prescaler = 1)
    // PLLCLK = HSE * 9 = 72MHz
    RCC->CFGR = RCC_CFGR_PLLSRC_HSE_PREDIV | RCC_CFGR_PLLMUL9;
    RCC->CR |= RCC_CR_PLLON; // Enable PLL
    // Wait till PLL is ready
    WAITWHILE(!(RCC->CR & RCC_CR_PLLRDY));
    // Select PLL as system clock source
    RCC->CFGR = (RCC->CFGR & ~RCC_CFGR_SW) | RCC_CFGR_SW_PLL;
    // Wait till PLL is used as system clock source
    WAITWHILE((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_1);
#undef WAITWHILE
    return 1;
}

[VladislavS]

Много судорога.

Код:

FLASH->ACR = FLASH_ACR_PRFTBE | _VAL2FLD(FLASH_ACR_LATENCY,2); 

RCC->CR = _VAL2FLD(RCC_CR_HSITRIM,16) | RCC_CR_HSION | RCC_CR_HSEON;
while(!(RCC->CR & RCC_CR_HSERDY));
 
RCC->CFGR = RCC_CFGR_MCO_NOCLOCK
          | RCC_CFGR_I2SSRC_SYSCLK
          | RCC_CFGR_USBPRE_DIV1_5
          | RCC_CFGR_PLLMUL9
          | RCC_CFGR_PLLSRC_HSE_PREDIV
          | RCC_CFGR_PPRE2_DIV1
          | RCC_CFGR_PPRE1_DIV2
          | RCC_CFGR_HPRE_DIV1
          | RCC_CFGR_SW_HSI;
           
RCC->CR = _VAL2FLD(RCC_CR_HSITRIM,16) | RCC_CR_PLLON | RCC_CR_HSEON | RCC_CR_HSION;
while(!(RCC->CR & RCC_CR_PLLRDY));
 
RCC->CFGR = RCC_CFGR_MCO_PLL
          | RCC_CFGR_I2SSRC_SYSCLK
          | RCC_CFGR_USBPRE_DIV1_5
          | RCC_CFGR_PLLMUL9
          | RCC_CFGR_PLLSRC_HSE_PREDIV
          | RCC_CFGR_PPRE2_DIV1
          | RCC_CFGR_PPRE1_DIV2
          | RCC_CFGR_HPRE_DIV1
          | RCC_CFGR_SW_PLL;


Последний раз редактировалось VladislavS Вс фев 13, 2022 23:05:27, всего редактировалось 2 раз(а).

[Eddy_Em]

VladislavS, приведенный код от моего вообще ничем не отличается (кроме множителей: у меня везде 1). Зачем указывать флаги, которые равны нулю?
P.S. У меня подтяжка на PA15, ты про это не спросил почему-то. Ведь у 303 нет аппаратной подтяжки DP.

[VladislavS]

Eddy_Em писал(а):

Зачем указывать флаги, которые равны нулю?

Чтобы по коду видеть все запрограммированные значения.

Eddy_Em писал(а):

P.S. У меня подтяжка на PA15, ты про это не спросил почему-то. Ведь у 303 нет аппаратной подтяжки DP.

Легко.

Код:

ConfigList<PinMode::PushPull_LowSpeed<1>, PA_15,               // Подтяжка
           PinMode::AF_PushPull_HighSpeed<14>, PA_11, PA_12,   // PA11=USBDM, PA12=USBDP
           PinMode::AF_PushPull_HighSpeed_PullUp<0x0>, PA_13,  // PA13=SWDIO
           PinMode::AF_PushPull_LowSpeed_PullDown<0x0>, PA_14, // PA14=SWCLK
           PinMode::Input_Floating, CfgCmd::AllUnusedPins
          >::pwr_config();


Последний раз редактировалось VladislavS Вс фев 13, 2022 23:26:34, всего редактировалось 1 раз.

[Eddy_Em]

Забыл сказать: т.к. там PNP-транзистор, активируется он нулем.

[VladislavS]

Нулём так нулём.

f303-CDC.zip

(2.9 KiB) Скачиваний: 112

ЗЫ: Народ, в архиве только бинарь. Зря не качайте.

[Eddy_Em]

Спасибо, работает: эхо введенных данных. Что и требовалось доказать: виноваты мои кривые руки.
Судя по тому, что после USB_ISTR_RESET вообще не появляется USB_ISTR_CTR, я накосячил с инициализацией тактирования.

Последний раз редактировалось Eddy_Em Вс фев 13, 2022 23:48:38, всего редактировалось 1 раз.

[VladislavS]

Ну тогда ищи. Разницы со 103 там вообше никакой кроме названия прерываний.

[Reflector]

jcxz писал(а):

Естественно:

Код:

addr = 1000DB44; SP = 1000CF98; m = 1000CFA0
1: y1 = 1.000000; y2 = 2.000000
2: y1 = 1.000000; y2 = 2.000000

Пробуем минималистичный пример на M0+:

Код:

void Zf2()
{
   uint32_t m[8];
   memset(m, 0xEE, sizeof(m));
   __set_MSP(__get_MSP() + 4);
   printf("y1 = %f; y2 = %f", 1.0f, 2.0f);
   __set_MSP(__get_MSP() - 4);
}

И тоже получаем нули, а с +8 работает правильно, выходит и M0 требует выравнивания стека на 8? Конечно нет, этого требует printf, а на ПК где есть SSE она будет требовать выравнивания на 16, даже если у конкретного проца этого SSE нет, более того можно хоть для AVR написать функцию требующую любое выравнивание... Выравнивание стека на 8 - это требование ABI, не самой архитектуры cortex-m.

[jcxz]

Reflector писал(а):

Конечно нет, этого требует printf, а на ПК где есть SSE она будет требовать выравнивания на 16, даже если у конкретного проца этого SSE нет, более того можно хоть для AVR написать функцию требующую любое выравнивание... Выравнивание стека на 8 - это требование ABI, не самой архитектуры cortex-m.

Да вполне возможно. Я и писал что "не знаю кто именно, но кто-то требует на >=M4F выравнивания на 8" (с более младшими ядрами я не работаю - не в курсе и не интересно).
Но по-моему не факт, что эти требования printf() не обусловлены какими-то аппаратными возможностями CPU. Потому как - если бы это были только требования реализации printf(), которую можно было бы реализовать и без этих требований, то это очень странно: одна printf() всё таки - очень частный случай, может и вообще не использоваться ни разу в проекте. И из-за этого частного случая вносить такую кучу ограничений в генерацию кода! Вы посмотрите в листинги - сколько там лишних сохранений в стек из-за необходимости этого выравнивания! А это ведь и лишние расходы памяти и быстродействия. Причём вообще для всего кода. Даже для того, где требуется максимальное быстродействие и printf() и близко не лежит - всё равно будут лишние PUSH/POP.
Имхо: такие существенные минусы можно оправдать только или аппаратными ограничениями системы команд/архитектуры (их никак не обойти) или принципильной невозможностью реализации функций стандартной бибилиотеки без этого выравнивания.

[Eddy_Em]

Интересное кино: если я вначале выставляю тактирование от HSI, то HSE потом не включается (хоть функция возвращает true)!
Вот HSI:

Код:

TRUE_INLINE void StartHSI(){ // system bus 48MHz from PLL
    __IO uint32_t StartUpCounter = 0;
#define WAITWHILE(x)  do{StartUpCounter = 0; while((x) && (++StartUpCounter < 0xffffff)){nop();}}while(0)
    RCC->CR = (RCC->CR & ~RCC_CR_PLLON) | RCC_CR_HSION;
    // To adjust HSI set value of HSITRIM here
    WAITWHILE(!(RCC->CR & RCC_CR_HSIRDY));
    FLASH->ACR = (FLASH->ACR & ~(FLASH_ACR_LATENCY)) |
            FLASH_ACR_LATENCY_0 | FLASH_ACR_PRFTBE;
    RCC->CFGR = RCC_CFGR_PLLSRC_HSI_DIV2 | RCC_CFGR_PLLMUL12 | RCC_CFGR_USBPRE_DIV1 | RCC_CFGR_PPRE1_DIV2;
    RCC->CR |= RCC_CR_PLLON; // Enable PLL
    // Wait till PLL is ready
    WAITWHILE(!(RCC->CR & RCC_CR_PLLRDY));
    // Select PLL as system clock source
    RCC->CFGR = (RCC->CFGR & ~RCC_CFGR_SW) | RCC_CFGR_SW_PLL;
    // Wait till PLL is used as system clock source
    WAITWHILE((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL);
#undef WAITWHILE
}

А вот - HSE:

Код:

// @return 1 if OK, 0 if failed
TRUE_INLINE int StartHSE(){ // system bus 72MHz from PLL
    __IO uint32_t StartUpCounter = 0;
#define WAITWHILE(x)  do{StartUpCounter = 0; while((x) && (++StartUpCounter < 0xffffff)){nop();}; if(x) return 0;}while(0)
    RCC->CR = (RCC->CR & ~RCC_CR_PLLON) | RCC_CR_HSEON; // disable PLL to reconfigure, enable HSE
    WAITWHILE(!(RCC->CR & RCC_CR_HSERDY));
    // Enable Prefetch Buffer. Flash 4 wait states for 48..72MHz
    FLASH->ACR = (FLASH->ACR & ~(FLASH_ACR_LATENCY)) |
            FLASH_ACR_LATENCY_2 | FLASH_ACR_PRFTBE;
    // HCLK = SYSCLK (AHB prescaler = 1), PCLK1 = HCLK/2 (APB1 prescaler = 2, max freq = 36MHz),
    // PCLK2 = HCLK (APB2 prescaler = 1), PLLCLK = HSE * 9 = 72MHz
    RCC->CFGR = RCC_CFGR_PLLSRC_HSE_PREDIV | RCC_CFGR_PLLMUL9 | RCC_CFGR_PPRE1_DIV2;
    RCC->CR |= RCC_CR_PLLON; // Enable PLL
    // Wait till PLL is ready
    WAITWHILE(!(RCC->CR & RCC_CR_PLLRDY));
    // Select PLL as system clock source
    RCC->CFGR = (RCC->CFGR & ~RCC_CFGR_SW) | RCC_CFGR_SW_PLL;
    // Wait till PLL is used as system clock source
    WAITWHILE((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL);
#undef WAITWHILE
    return 1;
}

Но, судя по тому, что в терминале с USART - тарабарщина, системными часами остается HSI (48МГц супротив 72).

[Reflector]

jcxz писал(а):

Но по-моему не факт, что эти требования printf() не обусловлены какими-то аппаратными возможностями CPU. Потому как - если бы это были только требования реализации printf(), которую можно было бы реализовать и без этих требований, то это очень странно: одна printf() всё таки - очень частный случай, может и вообще не использоваться ни разу в проекте. И из-за этого частного случая вносить такую кучу ограничений в генерацию кода!

Я потратил достаточно много времени пытаясь найти почему же именно нужно выравнивание на 8, если оно действительно нужно. И везде встречаю только разные интерпретации строк из "ARMv7-M Architecture Reference manual":

The ARMv7-M architecture guarantees that stack pointer values are at least 4-byte aligned. However, some software standards require the stack pointer to be 8-byte aligned, and the architecture can enforce this alignment.

Твой пример с printf() лишь подтверждает вышесказанное, чтобы доказать наличие именно архитектурных ограничений нужно что-то весомее неправильно работающих функций. У меня свое форматирование и с ним все работает(на M7):

Код:

void Zf2(double* p)
{
   uint32_t m[32];
   memset(m, 0xEE, sizeof(m));
   __set_MSP(__get_MSP() + 4);
   rtt.println<"y1 = {}; y2 = {}">(p[0], p[1]);      // y1 = 1; y2 = 2
   __set_MSP(__get_MSP() - 4);
}

[VladislavS]

Eddy_Em, Проверь в заголовочном файле определение RCC_CFGR_PLLSRC_HSE_PREDIV. Там в разных версиях, походу, блуд у них.

Добавлено after 7 minutes 11 seconds:

Reflector писал(а):

Твой пример с printf() лишь подтверждает вышесказанное

Ну это очевидно. У меня прямо сейчас нет M4 под рукой. Но было бы достаточно посмотреть в стеке данные после вот этой пары команд

Код:

 0xED94 0x0B02      VLDR     D0,[R4, #+8]
 0xED8D 0x0B00      VSTR     D0,[SP, #+0]

Больше чем уверен, что всё выгрузится как надо. А раз ограничение не аппаратное, то это дело тулчейна такие вещи разруливать. Программисту остаётся лишь не мешать ему. Я вот стек руками не двигаю от слов совсем никогда.

[Reflector]

Eddy_Em писал(а):

Интересное кино: если я вначале выставляю тактирование от HSI, то HSE потом не включается (хоть функция возвращает true)!

Вероятно это не тот случай, но если бы перед вызовов StartHSE() этот HSE уже завелся, то с большой вероятностью были бы проблемы из-за того, что выключая PLL ты не дожидаешься его реального отключения(проверяя флаг PLLRDY), в таком случае запись в регистры PLL может быть заблокирована.

[Eddy_Em]

Действительно, PLL нужно было не просто отключить для перенастройки, а сначала очистить RCC_CFGR_SW в RCC->CFGR, чтобы назначить системным таймером HSI, а не HSE. И не просто бит выставить, а еще и подождать RCC_CFGR_SWS…
Вот только к USB это дело никакого отношения не имеет. Судя по значениям RCC->CR и RCC->CFGR, тактирование у меня правильно настроено: RCC->CR=0x03035583 (PLL on and ready, HSE on and ready, HSICAL=0x55, HSITRIM=0x10, HSI on and ready), а RCC->CFGR=0x001d0404a (PLLMUL=0b111 - x9, PLLSRC=HSE, PPRE1=PLL/2, HSE selected and used as sysclock). То бишь частота USB в полтора раза ниже, составляя 48МГц. А вот какого ляда оно не работает с полностью перенесенным из F103 кодом (за исключением названия прерывания и инициализации подтяжки) - ХЗ..

[Reflector]

Код:

// USBPRE bit must be valid before enabling the USB clock!

Не оно?

[Eddy_Em]

В общем, проблема оказалась в моем рукожопии, как обычно. Вот как я инициализировал периферию:

Код:

    GPIOA->MODER = (GPIOA->MODER & (~GPIO_MODER_MODER15_Msk | GPIO_MODER_MODER11_Msk | GPIO_MODER_MODER12_Msk)) |
            GPIO_MODER_MODER11_AF | GPIO_MODER_MODER12_AF | GPIO_MODER_MODER15_O;
    // USB - alternate function 14
    GPIOA->AFR[1] = (GPIOA->AFR[1] & ~(GPIO_AFRH_AFRH4_Msk | GPIO_AFRH_AFRH5_Msk)) |
            (14 << (4 * 4)) | (14 << (5 * 4));


А надо было:

Код:

(14 << (3 * 4)) | (14 << (4 * 4));

Надо на будущее накатать макрос какой-нибудь, чтобы не было таких приколов, что я ноги 11 и 12 нумерую в H-регистре как 4 и 5!
USB заработал.

[VladislavS]

Eddy_Em писал(а):

Действительно, PLL нужно было не просто отключить для перенастройки, а сначала очистить RCC_CFGR_SW в RCC->CFGR, чтобы назначить системным таймером HSI, а не HSE.

Каким образом он у тебя включенным оказался? По ресету у тебя включен только HSI и от него всё затактировано. Включаешь HSE и ждёшь пока запустится, конфигурируешь PLL, включаешь PLL и ждёшь пока запустится, переключаешься на PLL. Всё - мат в три хода. Как ты без куба так наблудить то умудряешься?

А насчёт конфигурации ног... Я когда на форуме вижу примеры/вопросы со всеми этими манипуляциями битами MODER-ов, то аж передёргивает. С этим надо что-то делать любым доступным тебе способом.

[Eddy_Em]

Каким образом он у тебя включенным оказался?

Так я сначала HSI включил с тактированием PLL от него. А потом стал переключать на HSE… Просто эксперимента ради.

С этим надо что-то делать любым доступным тебе способом.

Конечно, буду макрос рисовать. Или true inline функцию. Не дело так - с magick numbers - писать.

Добавлено after 1 hour 35 minutes 52 seconds:
Что-то gcc дурью мается. Конструкцию

Код:

 GPIOA->MODER = (GPIOA->MODER & ~(GPIO_MODER_MODER15_Msk | GPIO_MODER_MODER11_Msk | GPIO_MODER_MODER12_Msk))

(получается GPIOA->MODER & ~0xc3c00000) gcc выполняет зачем-то в два этапа:

Код:

 800119c:   f022 4243   bic.w   r2, r2, #3271557120 ; 0xc3000000
 80011a0:   f422 0240   bic.w   r2, r2, #12582912   ; 0xc00000


Даже с оптимизацией -O3 он пишет именно так вместо bic.w r2, r2, 0xc3c00000