Изучаем STM32 Cortex M3

[NewWriter]

Но там же в мануале написано - "дополнительные функции управляются самой периферией".

[eddy]

Мужики, а было у кого-нибудь такое, чтобы USB сдыхало аппаратно? Причем, сижу, никого не трогаю; заливаю новую прошивку через st-link, переподключаю USB (т.к. плату криво развел и пришлось временно постоянную подтяжку сделать) — бдыщ, начал каждые несколько секунд отваливаться (явно не из-за вотчдога, т.к. в дебаг-режиме он у меня отключен). Жамкаю reset — и вообще устройство не появляется. Я, конечно, еще прозвоню и гляну в дебаггере, но сомневаюсь, что мне дебаггер поможет. А МК 100-ногий, я на пайку такой заразы минимум полчаса убью (а, скорей всего, даже и час) - не хотелось бы для тестов вторую плату распаивать или на этой МК менять…
Надо, блин, заказать на работе "кроватки" под LQFP-100 и LQFP-64, чтобы подобную девборду замутить — и можно без пайки на разных МК тренироваться…

Но странно, что USB так взял, да отвалился (причем, я-то работал не над ним, а над эмуляцией eeprom во flash). Как его могла убить статика, если на входе два резистора 22Ом и ESD-защита?
// если кому интересно, что за штука, вот она.

И тут до меня дошло: ведь у меня подтяжка постоянная! А это значит, что при втыкании в разъем USB этой штуки, ПК должен был инициировать энумерацию. А в dmesg — пусто! Надеюсь, что тупо отвалилась "сопля", которая подтяжку реализует (там пришлось соскрести немного лака и подпаяться прямо к дорожке).

[realid]

Мужики, а было у кого-нибудь такое, чтобы USB сдыхало аппаратно?

Никогда не сталкивался с таким.

[Yuri222]

было у кого-нибудь такое, чтобы USB сдыхало аппаратно?

у фирменных - бывало, но оочень редко.
у по случаю купленных - довольно частое явление (попалась одна партия).

Но у них же подтяжка к 3 вольтам к DP - внутри реализована...

[eddy]

Но у них же подтяжка к 3 вольтам к DP - внутри реализована...

Это лишь у некоторых (скажем, F0x2), а у F303, к сожалению, нужно внешнюю подтяжку городить. Пришлось одной ногой пожертвовать ради подтяжки (не городить же 144-ногий корпус из-за такой мелочи).

[NewWriter]

У ЮСБ разъема, бывает, что контакты дохнут. В смысле, отгибаются и плохо контачат, питание выдают сильно зашумленное. Бывает, что не сами контакты, а корпус разъема разгибается и болтается, не поджимает как надо.
А еще, поскольку USB электрически неизолированный интерфейс, случаются неприятности из-за разности потенциалов в устройствах, запитанных с разных розеток и не имеющие заземляния.

[eddy]

У меня все оказалось достаточно хорошо: просто "сопля", которой 1.5кОм подпаял к дорожке USB DP, имела хреновый контакт. Пока прозванивал, оно опять восстановилось. Надо будет перепаять.

Пытаюсь "общаться" с TMC2209. Настроил onewire USART на STM32F303 (если кому интересно, вся разработка здесь). Оба (USART2 и USART3) настраиваются одинаково:

static volatile USART_TypeDef *USART[2] = {USART2, USART3};

static void setup_usart(int no){
    USART[no]-›ICR = 0xffffffff; // clear all flags
    USART[no]-›BRR = 72000000 / 256000; // 256 kbaud
    USART[no]-›CR3 = USART_CR3_HDSEL; // enable DMA Tx/Rx, single wire
    USART[no]-›CR1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE; // 1start,8data,nstop; enable Rx,Tx,USART
    uint32_t tmout = 16000000;
    while(!(USART[no]-›ISR & USART_ISR_TC)){if(--tmout == 0) break;} // polling idle frame Transmission
    USART[no]-›ICR = 0xffffffff; // clear all flags again
}

void pdnuart_setup(){
    RCC-›APB1ENR |= RCC_APB1ENR_USART2EN | RCC_APB1ENR_USART3EN;
    setup_usart(0);
    setup_usart(1);
}

Сначала пытался с DMA, но понял, что с конечными автоматами в этом случае совсем запутаюсь, пришлось делать блокирующие запись/чтение. Ноги Tx подтянул через 1.5кОм к 3.3В (встроенной подтяжки не хватает, т.к. каждый драйвер подтягивает 20кОм к земле; возможно, и 1.5кОм будет маловато). Пишу: пишется (на осциллографе смотрю), читается (проверяю, что в RDR), однако, почему-то драйвер не отзывается даже на операции запроса чтения содержимого регистров. Эти же драйвера в MKS Monster вполне отзывались и ток менялся.

Кто-нибудь с TMC2209 работал? Вроде бы, в даташите не написано, что для активации UART нужны какие-то пляски с бубном. Но не отвечает, зараза! Думал: вдруг выбор адреса (MS0/MS1) инвертирован, воткнул драйвер в разъем нумер три (там адрес уже не 0, а 3, соответственно, распаян перемычками) — все равно тишина...

UPD: а, сорян!
Работает. Просто оказывается, нужно обязательно "высокое" напряжение тоже подключать. Я думал, что и без него логика драйвера обязана работать. А вона как оно, оказывается…

Поднимаю 7 интерфейсов USB CDC на STM32F303CBT6. Уже столкнулся с нехваткой памяти (буфер де-юре 512 байт, а де-факто доступно лишь 256 из-за дебильной адресации как к uint32_t, что половину полезной памяти отправляет в /dev/null): пришлось делать EP0 по 16 байт, а для остальных - 14 и 8 байт.
И вот столкнулся с тем, что если о подключении терминала к конкретному интерфейсу легко узнать по SET_CONTROL_LINE_STATE, то факт отключения вообще никак не регистрируется системой! Скажем, в PL2303 при отключении посылается BREAK, но вот в данном случае, похоже, разработчики модуля CDC ядра Linux не озаботились этим.
Может, кто-нибудь придумал, как определить, что конкретный интерфейс не имеет "с той стороны" открытого терминала?
Если да, можете поднять себе карму на StackOverflow.

Наткнулся при работе с SPI на F303, что у этой собаки и Rx, и Tx буферизуются отдельным FIFO!
И эта собака доставляет уйму проблем. Вот, скажем, читаю я четыре байта. Должно быть 0x9c,0,0,0 (по осциллограмме вижу), а у меня:

got 0x00
got 0x00
got 0x00
got 0x9c
Sregx10=0x9c000000
got 0x00
got 0x00
got 0x9c
got 0x00
Sregx10=0x9c0000
got 0x00
got 0x9c
got 0x00
got 0x00
Sregx10=0x9c00
got 0x9c
got 0x00
got 0x00
got 0x00
Sregx10=0x9c

Причем, этот косяк проявляется как при блокирующем чтении, так и с использованием DMA!
Я даже буфер пытаюсь очищать перед чтением:

    (void) SPI2-›DR;
    while(SPI2-›SR & SPI_SR_RXNE) (void) SPI2-›DR;

но не помогает…
Вот такая функция блокирующего чтения:

int spi_read(uint8_t *data, uint32_t n){
    if(spi_status != SPI_READY){
        DBG("not ready");
        return 0;
    }
    // clear SPI Rx FIFO
    (void) SPI2-›DR;
    while(SPI2-›SR & SPI_SR_RXNE) (void) SPI2-›DR;
    for(uint32_t x = 0; x ‹ n; ++x){
        WAITX(!(SPI2-›SR & SPI_SR_TXE));
        SPIDR = 0;
        WAITX(!(SPI2-›SR & SPI_SR_RXNE));
        data[x] = SPIDR;
        USB_sendstr("got "); USB_sendstr(uhex2str(data[x])); newline();
    }
    return 1;
}

Макрос WAITX просто ждет с таймаутом и возвращает 0, если произошла проблема. А макрос SPIDR есть обращение к DR как к uint8_t.

Ладно, забью пока: это работа с дисплеем на неизвестном чипе (т.к. оно как бы ILI934[01], но некоторые регистры невозможно прочитать, а в некоторых откровенный бред). Я надеялся брать данные из буфера экрана для модификации, но при заполнении, скажем, цветом 0x1818, я считываю нечто вроде 18 00 c4 18 00 c4 18 00 c4 и т.д. (хотя по логике вещей должен те же 1818 считать).

[Dtolok]

подскажите по переносу программы с stm32f103 на stm32g431 - споткнулся об таймера! в добавок не могу разобраться и нигде не могу найти CMSIS для G431 - только HAL ?

[j-Roger]

CMSIS для G431

Dtolok, от STMicroelectronics на Гитхабе.
Drivers-›CMSIS - оно?

Вот тут на Гитхабе без нагромождений - "чисто" CMSIS

[eddy]

Dtolok, я здесь брал. В репы от самих ST стараюсь вообще не заглядывать, чтобы инфаркт от их быдлокода меня не хватил!