На производстве проверка микросхем не в таком виде происходит.
Основные электрические параметры проверяются на этапе, когда пластина ещё не разрезана на кристаллы. Она перемещается под зондом с шагом, равным расстоянию между кристаллами, затем зонд (представляющий из себя кучу тонких иголочек, подключенному к тестирующей системе) опускается на контактные площадки очередного кристалла, и несколько секунд/минут тратятся на то, чтобы замерить электрические параметры. В случае МК это может быть в том числе и прошивка какой-нибудь программой с проверкой её отработки.
Если какой-то кристалл не пройдёт тест, он будет просто помечен, и уже потом, когда пластина будет порезана на кристаллы, отбракован. Корпуса ему не достанется.
Хотя, и в корпусе можно будет затем что-то мерять, но особого смысла в этом нет - дешевле это всё делать ещё на пластине.
Мы ведь сейчас обсуждаем тестер контроллеров на брак. Кто может заранее предсказать какой именно модуль у данного конкретного контроллера поврежден. У вас вот BSRR себя ведет странно, хотя казалось бы, где там косячить.
Цитата:
Хотя, конечно, на таймеры стоило бы более активную проверку сделать (в т.ч. на режим энкодера: собираюсь
Сейчас собираетесь играться с энкодером, потом с АЦП/ЦАП, потом еще с чем-то. По-хорошему, если вы действительно пытаетесь сделать из своей платы тестер, стоит итеративно добавлять проверку новых узлов чтобы хотя бы с ними в будущем не ловить сюрпризов.
Цитата:
Чтобы сделать проверку вообще всех компонент, придется нехилую обвязку делать. Да и прошивка МК будет оочень жирной.
Теоретически, можно воспользоваться JTAG чтобы напрямую писать значения в регистры периферии, тогда сложность переедет в программу на стороне компа. А если просто не хочется протирать до дыр флешку (хотя вряд ли - пару раз переписать для тестов это ни о чем), можно через ОЗУ.
Цитата:
Основные электрические параметры проверяются на этапе, когда пластина ещё не разрезана на кристаллы. Она перемещается под зондом с шагом, равным расстоянию между кристаллами, затем зонд
Сомневаюсь, что кто-то делает зонды с 200 иголками - они слишком громоздки. Плюс не все параметры, вроде температурной стабильности или частоты, удобно проводить на большой пластине. Я бы предположил скорее корпусировку одного экземпляра и тестирование его в надежде что все кристаллы на пластине одинаковы.
Мы ведь сейчас обсуждаем тестер контроллеров на брак. Кто может заранее предсказать какой именно модуль у данного конкретного контроллера поврежден. У вас вот BSRR себя ведет странно, хотя казалось бы, где там косячить.
Там не просто якобы BSRR косячит, но еще номера партий и даже шрифты разные, т.е. похоже китайцы эти мк откуда-то выпаивали, потому они и залочены, в таком случае с большой вероятностью речь идет об оригиналах. Если это отбраковка произведенная в разных местах, то косячный во всех BSRR будет наоборот с микроскопической вероятностью, если же это перемаркировка, то надписи должны быть по крайней мере одним шрифтом и раньше китайцы действительно перемаркировывали F303, но это были другие STM32, типа F100 и ID у них тоже были другие, а в этих ID правильные... Возможно косячит как раз Eddy_Em не признающий отладчики и т.д., у него постоянно какие-то проблемы
Reflector, а не могут ли это какие-нибудь GD или CS быть? Что, если у них регистры ODR и BRR совпадают по адресу с ST'шными, а BSRR — нет? Регистр BRR работает же. Надо остальные 7 штук из этого десятка проверить. А может, какие-то близкие к 303 МК, у которых нет регистра BSRR? Во всяком случае, и st-flash, и stm32flash распознают их как Cortex-M4 a la STM32F3xx со 128кБ флеша, 40кБ ОЗУ, 8кБ спец. ОЗУ. Но после снятия защиты от записи st-flash может прошить МК только единожды(хоть я не трогаю никакие регистры, связанные с отключением SWD или защитой).
P.S. На BSRR и глюк, если в BRR писать 0xffff вместо конкретных пинов, проверял и свой велосипед, и код, предложенный WiseLord.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Беру следующий чип из бракованной партии. Та же история: в нем что-то было прошито (некоторые светодиоды светились), стояла защита записи. Защиту снял, прошил через st-link, после чего через st-link шиться отказывался: опять включилась защита. Войти в режим бутлоадера и снять защиту с первой попытки не получалось. После повторного снятия защиты все так же, как и у других: st-link долго пытается передавать данные, но отваливается:
Код:
make flash FLASH blink.bin /usr/bin/st-flash write blink.bin 0x8000000 st-flash 1.6.0 2021-07-13T21:18:20 INFO common.c: Loading device parameters.... 2021-07-13T21:18:20 INFO common.c: Device connected is: F3 device, id 0x10036422 2021-07-13T21:18:20 INFO common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 2048 bytes 2021-07-13T21:18:20 INFO common.c: Attempting to write 612 (0x264) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x08000000 erased 2021-07-13T21:18:20 INFO common.c: Finished erasing 1 pages of 2048 (0x800) bytes 2021-07-13T21:18:20 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id 2021-07-13T21:18:20 INFO flash_loader.c: Successfully loaded flash loader in sram 2021-07-13T21:18:24 ERROR flash_loader.c: flash loader run error 2021-07-13T21:18:24 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1 stlink_fwrite_flash() == -1 make: *** [Makefile:137: flash] Error 255
Однако, через бутлоадер вполне прошивалось. И опять те же грабли. Настроил пины:
Светодиоды сидят на питании, так что включаются нулем. Пытаюсь погасить так: GPIOA->BRR = 0xffff — не работает, однако вот так: GPIOA->BRR = (1<<6 | 1<<8) — работает. Вот так: GPIOA->ODR = 0 — тоже светодиоды зажигаются. А теперь — вообще фантастика: если я пишу GPIOB->BSRR = 3<<16 (пауза) GPIOB->BSRR = 3, а код для PORTA оставляю прежним (который мигал до этого), то порт B мигает, а порт А — нет! Стоит мне закомментировать GPIOB->BSRR = 3, как порт A начинает мигать!! Однако, вот такой код мигает всем:
Код:
for (i = 0; i < 100000; i++) __NOP(); GPIOA->ODR = 0; GPIOB->ODR = 3; for (i = 0; i < 100000; i++) __NOP(); GPIOB->ODR = 0; GPIOA->ODR = (1<<6) | (1<<8);
Теперь меняю GPIOB->ODR = 0 на GPIOB->BSRR = 3. И что я вижу? Светодиоды на PB0/1 один раз вспыхивают (на инициализации), после ODR=3 гаснут и больше не загораются, т.е. GPIOB->BSRR = 3 не сбрасывает их в нуль! Но только я поменяю это на GPIOB->BRR = 3, как все работает!
Запустил это с SysTick, не настроив кварц (этим займусь позже, по мануалу). Мигает:
В общем, BSRR здесь какой-то мутный, причем, во всех сериях! В заголовочном файле структура GPIO_TypeDef описана правильно, порядок соответствует порядку в мануале. Вообще, странно, что BSRR, идущий сразу за ODR, не работает как надо, а идущий в хвосте BRR — работает.
Добавлено after 10 minutes 43 seconds: И тут у меня срывает крышу. Вот этот код:
Чертовщина какая-то! В общем, буду дальше тестировать. Но явно, судя по ошибкам в загрузке через st-link, с чипами что-то не то (до этого в этой же девборде работал с F072, ни разу такой проблемы не встретил). Судя по тому, что светодиоды блымцкают 10 раз за 9 секунд, частота тактирования SysTick составляет около 8МГц, т.е. HCLK=64МГц по умолчанию.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Последний раз редактировалось Eddy_Em Вт июл 13, 2021 22:40:18, всего редактировалось 1 раз.
Теперь меняю GPIOB->ODR = 0 на GPIOB->BSRR = 3. И что я вижу? Светодиоды на PB0/1 один раз вспыхивают (на инициализации), после ODR=3 гаснут и больше не загораются, т.е. GPIOB->BSRR = 3 не сбрасывает их в нуль! Но только я поменяю это на GPIOB->BRR = 3, как все работает!
Ты уже путаешься, GPIOB->BSRR = 3 - это не сброс, для сброса нужно писать 3 << 16. В макросе pin_toggle сдвиг есть, он и работает...
А! Посыпаю голову пеплом. Я считал, что младшая половина - reset, а старшая - set. Ну, ОК тогда. Претензия пока только к косякам при записи во флеш.
Добавлено after 1 hour 49 minutes 52 seconds: Кстати, в даташите нарисовано, что SysTick тактируется от HCLK/8 (жестко). Однако, оказалось, что приходится вызывать SysTick_Config(72000), чтобы получить период в 1мс! Хотя, если бы там было 9МГц, пришлось бы писать 9000 в аргументе!
И вот, что обнаружил: если вначале не написать while(blink_ctr < 9) (в общем, не подождать немного), то "блымкают" только светодиоды на PB0/1! Похоже, какой-то косяк с инициализацией периферии, хотя я вызываю ее после StartHSE() (а эта функция ждет, пока все будет ОК):
Код:
TRUE_INLINE void StartHSE(){ __IO uint32_t StartUpCounter = 0; RCC->CR = (RCC->CR & ~RCC_CR_PLLON) | RCC_CR_HSEON; // disable PLL to reconfigure, enable HSE while(!(RCC->CR & RCC_CR_HSERDY) && (++StartUpCounter < 10000)); if(RCC->CR & RCC_CR_HSERDY){ // Enable Prefetch Buffer. Flash 2 wait states for 48..72MHz FLASH->ACR = (FLASH->ACR & ~(FLASH_ACR_LATENCY)) | FLASH_ACR_LATENCY_1 | 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 & ~(RCC_CFGR_HPRE | RCC_CFGR_PPRE1 | RCC_CFGR_PPRE2 | RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLMUL) ) | RCC_CFGR_PLLSRC_HSE_PREDIV | RCC_CFGR_PLLMUL9; RCC->CR |= RCC_CR_PLLON; // Enable PLL // Wait till PLL is ready StartUpCounter = 0; while(!(RCC->CR & RCC_CR_PLLRDY) && (++StartUpCounter < 1000)){} // 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 StartUpCounter = 0; while(((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_1) && (++StartUpCounter < 1000)){} }else{ // HSE fails to start-up RCC->CIR = 0; RCC->CR |= RCC_CR_HSION; // To adjust HSI use HSITRIM and after that wait for HSIRDY } }
Другой вариант — у меня неправильно настроены flash latency и flash prefetch (хотя, вроде это делаю по даташиту).
Но больше всего для начала меня смущает то, что у SysTick тактирование не 9МГц, когда у меня на HSI стоит кварц 8МГц, PLL с умножителем на 9, а все делители на 1.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Кстати, в даташите нарисовано, что SysTick тактируется от HCLK/8 (жестко). Однако, оказалось, что приходится вызывать SysTick_Config(72000), чтобы получить период в 1мс!
SysTick везде одинаковый и тактируется или от AHB, или от AHB/8, или, иногда, от системной частоты, как у H7, но у них она просто может быть в 2 раза больше частоты AHB. А нарисовано местами действительно только AHB/8...
Поражаюсь, что между STM32F303CBT6 и C8T6 разница не только в размере флеша/оперативки, но и в некоторых регистрах! Что ж за камень такой? А проблема с "неблымкающими" светодиодами, возможно, из-за flash latency: я ее выставлял по мануалу в 010, однако, сейчас вот методом тыка сделал 100 (как у F103), и заработало! Но в мануале вообще ничего не пишется про третий (старший) бит, там только три упомянуто (000 - ни одного цикла ожидания, 001 - 1 цикл, 010 - 2 цикла). По умолчанию оно в нуле, поэтому, видимо, когда без настроек таймеров автоматом включался HSI, и были эти косяки, что часть кода просто "не читалась"!
Блин, я фигею от этой документации!!! Либо здесь - какой-то экзотический перемаркированный МК. А насчет HCLK/8, действительно, под F0 функция настройки systick выглядит вот так:
Код:
__STATIC_INLINE uint32_t SysTick_Config(uint32_t ticks, uint32_t div8) { if ((ticks - 1) > SysTick_LOAD_RELOAD_Msk) return (1); /* Reload value impossible */
SysTick->LOAD = ticks - 1; /* set reload register */ NVIC_SetPriority (SysTick_IRQn, (1<<__NVIC_PRIO_BITS) - 1); /* set Priority for Systick Interrupt */ SysTick->VAL = 0; /* Load the SysTick Counter Value */ SysTick->CTRL = SysTick_CTRL_TICKINT_Msk | SysTick_CTRL_ENABLE_Msk; if(!div8) SysTick->CTRL |= SysTick_CTRL_CLKSOURCE_Msk; return (0); }
Надо ее в таком виде на все перенести, а то в остальных семействах в коде от ST по умолчанию считается, что SysTick тактируется напрямую от HCLK.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Но в мануале вообще ничего не пишется про третий (старший) бит, там только три упомянуто (000 - ни одного цикла ожидания, 001 - 1 цикл, 010 - 2 цикла). По умолчанию оно в нуле, поэтому, видимо, когда без настроек таймеров автоматом включался HSI, и были эти косяки, что часть кода просто "не читалась"!
Даже у F0 все три бита рабочие, можно 7 записать и код будет медленнее работать, чем с 6-ю, а с двумя тактами должно и в разгоне до 120 MHz работать, если все правильно сделано и питание нормальное...
Я считал, что F303 — сравнительно свежий чип (не старее F072). Но, судя по Errata, это просто жесть какая-то!!!
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Вот только от производителя чипов ожидаешь вменяемой документации и железа, а не цирка! Хотя вы правы, для таких как я (да и Эдди, похоже) они идеальны: всегда есть что героически превозмогать.
Там ничего принципиального для меня нет, поэтому я ее давно полистал, увидел, что мне ничего страшного не грозит (т.к. всякие экзотические режимы я не использую) и забил. А вот у F303 сразу в глаза бросается, например, "ADEN bit cannot be set immediately after the ADC calibration is done" — забавный глюк, надо иметь в виду. Вот это: "Imprecise VREFINT calibration values" не может не "радовать". Вот еще жесть: "BSY bit may stay high at the end of a SPI data transfer in slave mode". Хочешь работать в SPI slave? Отрубай SPI после каждой передачи, а как BSY упадет, можешь включать обратно!
Вроде, больше особых косяков в errata на STM32F303 не заметил. У 072 ни одного такого серьезного косяка нет!
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
А вот у F303 сразу в глаза бросается, например, "ADEN bit cannot be set immediately after the ADC calibration is done" — забавный глюк, надо иметь в виду. Вот это: "Imprecise VREFINT calibration values" не может не "радовать".
Так ведь и сам ADC у F3 намного сложнее, тем более у предыдущих серий такого не было, так что даже если бы F3 были новее это бы не сильно помогло.
Eddy_Em писал(а):
Вот еще жесть: "BSY bit may stay high at the end of a SPI data transfer in slave mode". Хочешь работать в SPI slave? Отрубай SPI после каждой передачи, а как BSY упадет, можешь включать обратно!
SPI у STM32 в принципе жесть, особенно в режиме слейва, а конкретно этот баг есть и у новых G0/G4, видимо его исправление не самая приоритетная задача.
На F072 у меня никаких проблем с SPI-slave не было, Rx/Tx по DMA.
А вот чего реально не хватает, так это каналов DMA!!! Их нужно хотя бы 32. Но лучше бы — 64. С семью каналами F072 далеко не уйдешь. Да и у F303 всего-то на 5 каналов больше. Тоже мне… Если нужно одновременно работать с обоими SPI, I2C и четырьмя USART'ами, то вариант полностью отдать ненужные потуги на DMA не прокатывает ☹ А еще ведь бывает нужно таймеру регистры менять при помощи DMA (+складывать захваченное в массив — для того же 1-wire) или генерировать ЦАПом что-нибудь…
В общем, за малое количество каналов DMA жирнейший минус ST!
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 36
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения