0x435641

ясное дело, что при цене 100р время дороже. но дело принципа как при обновлении он сам смог себя так залочить? Про hot-plug: The ”Hot Plug” option allows to connect to the target without halt or reset. This is useful to update the RAM addresses or the IP registers while the application is running. для чего оно вообще (в смысле практического применения, особенно без остановки)?

работает только соединение hot-plug. естественно st-link utility options bytes не работают что с камнем? в stm32l0 есть rdp level 2, с которым точно меткость попадания тренировать, а здесь я не вижу причин такого состояния...

Добры день! Прошу помощи по возврату к жизни STM32F103 Предистория: стоял в ST-LINK V2, после обновления прошивки перестал определяться ПК. Зашил аналогичный контроллер с отладочной платы, поменял их местами - в итоге стлинк работает, а отладочник нет st-link не видит его ни в normal, ни в under-reset. По uart бутлоадер так же молчит. Единственное что работает - определение по swd в режиме hot-plug В какое состояние впал камень? Судя по даташитам у него есть только RDP Level 1, который должен убираться с очисткой кристалла PS. такого пациента наблюдаю уже не первого

>выходит при вызове sprintf так же нужно запрещать прерывания(если в них присутствуют new/delete) ??? >или здесь имеется ввиду параллельный вызов sprintf из основного потока и прерывания? меня интересует сейчас конкретно sprintf. он в основном потоке. я могу в прерывании пользовать new/delete, или тоже синхронизация нужна? в потрохах sprintf не ковырялся

нашел, спасибо за наводку! выходит при вызове sprintf так же нужно запрещать прерывания(если в них присутствуют new/delete) ??? или здесь имеется ввиду параллельный вызов sprintf из основного потока и прерывания?

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

столкнулся со странными вылетаниями программы в swi_handler и data_handler в проекте активно используется динамическая память, Ethernet, USB долгими мучительными копаниями удалось найти причину - параллельное выполнение сабжевых операторов, которые используются как в основном цикле, так и в прерываниях на данный момент решил вопрос отключением прерываний, если new и delete вызываются вне прерывания в нете не нашел инфы по спицифике использования этих операторов в IAR если кто-то обладает знаниями - просьба поделиться

всем привет. есть рабочий проект в Keil под NicheLite(USB хост, не мой), все работает. сейчас есть потребность избавиться от OS. всю работу с USB переписываю с нуля. инициализация хоста проходит нормально, девайс определяется, начинаю инициализировать его по приходу RHSC. но при посылке первого же пакета(SETUP) прилетает одновременно UE и WDH, при чем DoneHead = 0 HccaFrameNumber перестает обновляться, но сам HcFmNumber продолжает расти. вообще в доке по OpenHCI по поводу UE написано "The Host Controller sets the UnrecoverableError bit when it detects a system error not related to USB or an error that cannot be reported in any other way." совсем не понятно в каком случае это происходит. частота возникновения SOF 1мс, как и положено, структуры HCCA, EndpointDescriptor, TransferDescriptor выровнены как и положено. что не так? уже сравнивал содержимое дескрипторов при работе своей и старой прошивки буду благодарен за любую информацию!

Вопрос снят

int __packed * p; A pointer to a packed integer. int * __packed p; A packed pointer to an integer. __packed int * p; A packed pointer to an integer. спасибо за наводку. оказывается есть разница где атрибут ставить... в том то и дело что ложится в одно место так: 44 33 22 11 NA NA NA NA NA NA NA NA NA СПАСИБО! тема закрыта, __packed в правильном месте помог )

я работаю в IAR. кейл только для проверки использовал. __packed int *pi1 = (int*)&arr[0]; __packed int *pi2 = (int*)&arr[1]; __packed int *pi3 = (int*)&arr[2]; __packed int *pi4 = (int*)&arr[3]; *pi1 = 0x11223344; *pi2 = 0x11223344; *pi3 = 0x11223344; *pi4 = 0x11223344; в симуляторе с теми же сообщениями, но память заполнилась правильно. через J-Link опять все легло поверх в одно место кстати в ASM листинге без изменений - те же инструкции

Доброго времени суток. начну с кода: char arr[16]; int *pi1 = (int*)arr[0]; int *pi2 = (int*)arr[1]; int *pi3 = (int*)arr[2]; int *pi4 = (int*)arr[3]; *pi1 = 0x11223344; *pi2 = 0x11223344; *pi3 = 0x11223344; *pi4 = 0x11223344; среда IAR 6.30.1 в результате запись происходит по адресам со сдвигом влево до границы кратной размеру адресуемого типа. это смотрел через J-Link в листинге каждая запись производится инструкцией STR R0, [Rx]... при чем в Rx лежат правильные значения с шагом в 1 байт. тот же результат в uVision 4 если же запустить отладку в симуляторе, то при каждой записи по не кратному адресу вылетает сообщение "STR instruction at addr: 0x40006835 made an illegal unaligned access to 0x40006835" информации о том, что адрес должен быть выровнен для STR/LDR по 4 байтам для STRH/LDRH по 2 байта я не нашел. пусть даже должен быть выровнен. почему компилятор не преобразует команду записи по указателю в набор инструкций с побайтовой записью, учитывая специфику адресации?

Всем привет! Суть проблемы в следующем: при установленном бите CRC ENABLE в регистре MAC2 - каждый кадр, судя по документации, обязан дополняться CRC, но этого почему-то не происходит. снифер WireShark вполне логично сообщает о неверном CRC. пакет приходит с заявленной длиной, как и прописано в поле Size TX дескриптора, последние 4 байта без изменений. куда копнуть? не хотелось бы использовать софт-генератор CRC