Программирование ARM. Eclipse, Keil,IAR,CooCox - всё сюда.

roker сказав(ла):
Ну тогда только нас двоих заберут добрые дяди в белых халатах.
Натисніть, щоб розгорнути...

Нет, ещё ur4lv пошаливает иногда :)

P.S. Погода - говно, майские ещё не настали. Вот шо делать в субботу?

roker сказав(ла):
У Кейла есть обработчик эксепшна обращения по нулевому указателю. Так сто while(1) искать надо там. :)
Натисніть, щоб розгорнути...

Зачем его искать? Просто останавливаешь дебагер - и ты в нём :)
И это не у кейла - это в либах. Там несколько хардфаулт_хандлеров.



ur4lvn сказав(ла):
Код: 
 USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDevice_0->pClassData;
это вызов функции которая лежит в поле pClassData конкретного экземпляра хэндла типа USBD_HandleTypeDef. Этот хэндл создан?
Натисніть, щоб розгорнути...

Дело в том, что это ни какой не вызов.
По формату это - объявление hcdc с типом указателя на USBD_CDC_HandleTypeDef.
и больше это ни на что не похоже.

Этому указателю присваивают (прямым приведением типа*) значение, которое должно лежать в hUsbDevice_0->pClassData;

НО!
USBD_CDC_HandleTypeDef - структура! Не функция!

А hUsbDevice_0->pClassData - действительно имеет тип void*, вот только там нет значения. Там 0 лежит на момент обращения.

И ни какой он не вызов, так как аффтары потом делают так:
if (hcdc->TxState != 0)
То есть, аффтары, как бы, подозревают, что там, по указателю, должна находиться структура, в которой есть поле TxState.

Но для этого, её адрес должен лежать в hUsbDevice_0->pClassData.

А ТАМ ЛЕЖИТ ЭТО!
fault_view2.png




И вообще, они косанули с этим присвоением...
Я думал, что это от оптимизации, но
volatile USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDevice_0->pClassData;

Value - <ot in scope> struct <untagged>*

Вот и вся пэстня.

Вся эта возня - чтобы узнать, не занят ли USB.. Есть идеи как ещё это сделать?



//-------------------------------------------

Да!

Косяк внятен - не проверяется наличие инициализации USB перед передачей.

Дело в том, что когда я принимаю ресив - это вообще может случиться только при инициализированном USB. Иначе у меня зависнет терминал - и всё.

А вот структурка существует только тогда, когда USB инициализирован.

Поскольку, висящий в девайсах порт, ещё не говорит о том, что девайс о нем чего-то знает, и что там вообще с девайсом хаб не имеет понятия (а я писал уже - он понимает отключение/подключение только по резистору в 1,5к к шине), то перепрошитый и не иниченный контроллер - не виден хабу.
Контроллер же не получает инициализацию, так как хабу и так всё ясно.

Получается коллизия. Выходит, что для корректной работы девайс просто обязан сам уметь отключаться и подключаться к USB.
Иначе это, как минимум, затруднит отладку (вот как мне), а как максимум - приведёт к незапланированному драчению юзером порта.
А если порт припаять вообще (как собираюсьэто сделать я :) ), или спрятать внутрь прибора - тут уже без диспетчера устройств не обойтись.

Вывод - в понедельник добавлю управление подвеской.
Через TeamViewer паять неудобно.

Алгоритм без вкусностей - такой.
Прошиваем МК.
Порт не меняет значения - если он был в винде, то он там и остается.
Это - ложь. Нет там ни какого порта.

Удаляем устройство, не забыв скипануть и не удалить драйвера.
Нет устройства. МК прошит.
Запускаем дебагер с брейком, или просто в стопрежиме, чтобы он стоял перед инициализацией.

Говорим винде - обновить устройства - и она начинает искать.
В это время отпускаем дебагер в run - вуаля! Всё работает!

Это я так делаю потому, что тимвьюер, а не личное присутствие. Не удобно мне строчить на форум и плату отлаживать - она под руками путается, по этому остается в другом месте ночевать :)

P.S> Косяк с хардфаултом - предательский, конечно... могли бы и проверять не только сам USB, что писать туда можно, но и что структура создана.
 
Останнє редагування:
//------------------------
Ааааалилуйя.
Помните, я писал про жлобский J-Link, который понял, что он пиратский и провалялся у меня с год в бездействии?
Так вот - он ожил!
Фтыкнулся в кейл, попробовал зашить камень, был оплёван и унижен за старую дырявую прошивку, обновился и работает!
Во. Терь у меня есть чем работать пока едет второй ST-link и ремонтируется первый.
 
Поздравляю! Наверное они регулятор жадности приоткрутили
 
параллельная история. libopencm3
читаю значение пина ихними средствами :as is: блеать, оно в нулях!!! я никогда не мог подумать, что в этом месте может быть косяк. а сижу с этой хуйней уже часов с 9 :-( кругом враги терь разбираться в чем дело, но не напишешь p GPIOB->IDR пушо там всё через жопу

ЗЫ
оказалось банально не включил клок. но суууука догадаться об этом сложно, пушо наглядности ноль
 
Останнє редагування:
roker сказав(ла):
Поздравляю! Наверное они регулятор жадности приоткрутили
Натисніть, щоб розгорнути...

Видимо, за год просто забыли как определять старые J-Link-и :)

_pasha сказав(ла):
параллельная история. libopencm3
читаю значение пина ихними средствами :as is: блеать, оно в нулях!!! я никогда не мог подумать, что в этом месте может быть косяк. а сижу с этой хуйней уже часов с 9 :-( кругом враги терь разбираться в чем дело, но не напишешь p GPIOB->IDR пушо там всё через жопу
Натисніть, щоб розгорнути...
Что такое "ихними средствами"?

Напиши паралельно и ихними и через регистр. Доступ к регистрам быть обязан, их можно найти в lowlewel драйверах, или что там в опенцм есть снизу.

P>S> Видимо, хорошо, что я не повёлся на нахваливание опенцм и продолжил ковырять HAL :) Тут таких проблем нет. Есть другие, но раскапывать. видимо, проще :)
 
_pasha сказав(ла):
там основано не на первичных описаниях портов
так, чтобы по простому глянуть периферию - это извращаться нужно
Натисніть, щоб розгорнути...

Танунах такое :D

Я в этом проекте буду пилить HAL, так как уже всунул туда жало и он работает. Есть плюсы и минусы.

Но потом я на свой ограничительный перечень, видимо, сползу на непортабельные личные либы, основанные на периферии.
Всей линейкой от f1 по f7 я всё равно пользоваться не буду (мне жизни не хватит под каждый камень по проге писнуть, ибо их дохерища), но вижу возможность офигенно сэкономить память. Кил 10, не менее. Ибо голый HAL проект жрёт сразу в среднем 12-15 кБ. Шоправда, при продолжении уже юзерской писанины - код не растет стремительно и на большинство случаев HAL будет устраивать.

P.S. С прерываниями они, конечно, поступили жестоко. По умолчанию обработчики разные, но HAL обернул их в свои функции и разбирает внутри прерывания по SR кто плюнул. ИМХО - это первое от чего я избавлюсь посвободке.
 
не, hal точно фтопку.

dvs4tgasoline сказав(ла):
непортабельные личные либы, основанные на периферии.
Натисніть, щоб розгорнути...
а шо тама непортабельного , ащета?
я перешел на другую парадигму.
пишу всю конкретику в main() потому что он у нас один - получается как раз для этих дел.
остальное висит где-то далекооооо и ниче не знает про остальные муки.
и еще newlib- это что-то, под названием нуегонах.
вся нужная часть stdlib обеспечивается __builtin_xxxx
и там все в порядке с реализацией. пока.
 
О... вот он, сцука, слизнячёк, дошли до него руки :)

Зірим.
Во время одупления соединения с хабом вызывается функция

USBD_CDC_SetTxBuffer(hUsbDevice_0, UserTxBufferFS, 0);

Вот она. гнида, препарированная.

Код: 
uint8_t  USBD_CDC_SetTxBuffer  (USBD_HandleTypeDef   *pdev,
                                uint8_t  *pbuff,
                                uint16_t length)
{
  USBD_CDC_HandleTypeDef   *hcdc = (USBD_CDC_HandleTypeDef*) pdev->pClassData;
  
  hcdc->TxBuffer = pbuff;
  hcdc->TxLength = length;  
  
  return USBD_OK;  
}

Вот нахуя забивать на инициализацию массива?
Он есть... массив...
uint8_t UserTxBufferFS[APP_TX_DATA_SIZE];

Педерасты вообще понимают, что там валяется в этой pClassData до момента вызова этой функции и, что проверить потом была эта функция или нет вызвана, можно только 2-мя способами:
1. Проклясть их и допедалить им в код структуры флаг коннекшена
2. Извращаться.
?
Ну обращайся ты к содержимому, оно хоть по умолчанию обнуляется при старте, нет... они инициализируют УКАЗАТЕЛЬ в СРЕДИНЕ кода!!!

Дебилыблядь(С)какая-то грустная русская лошадь.
Того, кто так сделал - надо сослать в Воронеж и разбомбить кхуям.

P.S. Так что, HAL реабилитирован по этому эпизоду.
Пиздец кроется в
usbd_cdc_if.c

А он не относится к HAL. Это из состава usb____FS.lib



ur4lvn сказав(ла):
Свой усб сдс запускал с нуля дня 3 :(
Натисніть, щоб розгорнути...

А ты тож ебался с этой инициализацией, или проскочил как-то?
Как ты вообще определяешь подключен у тебя порт к хабу, или нет? В stm32_usb-fs-device_driver есть такой косяк? Потому как STM тащит чужие либы для usb со времен этой самой usb-fs, которая была со времен начала кокоса, где она есть даже в репозитарии.
 
Останнє редагування:
обращаться к непонятному без проверки на NULL нехорошо. Хоть и долго.
 
_pasha сказав(ла):
обращаться к непонятному без проверки на NULL нехорошо. Хоть и долго.
Натисніть, щоб розгорнути...

Чисто для юмора - А он - не NULL :) Смекаешь?
Это static! Его бессмысленно на NULL проверять - он не будет им никогда :)
Если так делать - надо содержимое проверять, а не null, поскольку там блядь мусор! А на него ссылаются.
И я вообще не понимаю нахуя объявлять 2 простых одномерных массива и обращаться к ним:

*через поле структуры, типа - указатель на void.
* в котором лежит указатель на struct.
*и чтобы это понять - его явно приводят к типу путём (имяСтруктуры *).
*само это поле принадлежит static структуре,
которое копируется в ОБЫчную структуру (ТОЧНО ТАКУЮ! И нахуя она при наличии базового static такого же объекта - знает только тот даун, который писал) без volatile (то есть, что там валяется в содержимом до вызова - ни кто не знает вообще)
*причем, значение в это поле (pClassData) заносится только при подключении к девайсу ХАБА (не питания! Хаба! То есть - и программно тоже удалить/обновить)
*А при попытке передачи проверяется не факт инициализации значением, а само значение по указателю!
* что неминуемо вызывает или порчу данных в ОЗУ, или (как у меня) - hardfault потому как там число лежит охуенное и далеко за пределы памяти показывает.


Ротвейлера в студию!

P.S. Блядь, я в гневе.
 
Останнє редагування:
мусор - если в секции no_init или как там ее.

dvs4tgasoline сказав(ла):
через поле структуры, типа - указатель на void.
* в котором лежит указатель на struct.
*и чтобы это понять - его явно приводят к типу путём (имяСтруктуры *).
*само это поле принадлежит static структуре,
которое копируется в ОБЫчную структуру (ТОЧНО ТАКУЮ! И нахуя она при наличии базового static такого же объекта - знает только тот даун, который писал) без volatile (то есть, что там валяется в содержимом до вызова - ни кто не знает вообще)
*причем, значение в это поле (pClassData) заносится только при подключении к девайсу ХАБА (не питания! Хаба! То есть - и программно тоже удалить/обновить)
*А при попытке передачи проверяется не факт инициализации значением, а само значение по указателю!
* что неминуемо вызывает или порчу данных в ОЗУ, или (как у меня) - hardfault потому как там число лежит охуенное и далеко за пределы памяти показывает.
Натисніть, щоб розгорнути...
да то понятно. писатели сферических коней все делают хендлами пушо думают что у камня может появиться больше одного усб и либа останется на задворках. а так оппаньки, строчку добавил - и всьо в ажуре
 
dvs4tgasoline сказав(ла):
А ты тож ебался с этой инициализацией, или проскочил как-то?
Натисніть, щоб розгорнути...
В комплекте либы есть прожекты,взял то,что мне нужно,почитал Агурова с натшеллом и выпилил все ненужное.
Как ты вообще определяешь подключен у тебя порт к хабу, или нет?
Натисніть, щоб розгорнути...
По звуку :), винда звенит по-разному.Так же по звуку можно услышать и хардфолт.

В stm32_usb-fs-device_driver есть такой косяк? Потому как STM тащит чужие либы для usb со времен этой самой usb-fs, которая была со времен начала кокоса, где она есть даже в репозитарии.
Натисніть, щоб розгорнути...
ХЕЗ,пока не замечал,но пЁрлы типа USB_To_USART_Send_Data(), для виртуального USART0, поначалу сбивали с ног.
 
_pasha сказав(ла):
да то понятно. писатели сферических коней все делают хендлами пушо думают что у камня может появиться больше одного усб и либа останется на задворках. а так оппаньки, строчку добавил - и всьо в ажуре
Натисніть, щоб розгорнути...

Так хоть бы они проверяли свои хэндлы, суки! Как можно без проверки брать значение из поля структуры, если оно не заносится туда по дефолту и не имеет контрольного значения, говорящего, что оно - лажа?
Это ж, сцуко, сюрреализм какой-то.
 
//----------------------- включил всю периферию кроме CAN по одной штуке -----------
Program Size: Code=14994 RO-data=286 RW-data=380 ZI-data=11364

Теперь известно сколько памяти занимает куб со старта в общем случае для STM32F103
Включены:
GPIO
RCC
CRC
SPI2
USART1
USART3
SPI1
ADC1
USB_FS(CDC)
SYSTICK
TIMER1

P.S. Ну, и DMA 5 каналов настроены, на USARTы и мем-мем
 
Подключение подвески D+ к управлению пином - просто бальзам на душу населения.
Всем рекомендую делать именно так.

_pasha сказав(ла):
кста, мне пригождается случай когда мем2мем нужно. С триггером по таймеру. Яхуею.
Натисніть, щоб розгорнути...

mem-to-mem - часто нужно.
Я в USB его юзаю. ТАм нет DMA периф-ту -мем для USB. И в либах нет очереди - просто затираемый буфер.
В данном случае - самое то. По прерыванию я влетаю в обработчик, из него виден приемный буфер USB. Задача - забрать приемный и освободить приемник как можно быстрее и проще.
Ну что может быть проще, чем ткнуть буфер в нос DMA и сказать - делай.
Не memcpy() же вызывать.

P.S. А тебе куда он пригодился? (я раньше ещё на CAN его юзал - манал я разгребать регистры, он мне в массив тащил фрейм, там я его разбирал. Но, на AT91SAM7 там это периф-ту-мем делал.
 
_pasha сказав(ла):
так таи же нету подвески через syscfg...некошерно :rolleyes:
--
тема 103го камня оказалась заразной :ги: пойду пилить.
Натисніть, щоб розгорнути...

ммм... зачем через syscfg? Там должно быть 1,5кОм. На сколько я понял - сам кирпич так не умеет. Или я чего-то не понял. Повесил тупо на пин - девайс теперь не надо смыкать с разъёма, можно детектить, что отвалилось USB и переподключаться :)
 
Ви повинні увійти або зареєструватися, щоб відповісти.
Назад
Зверху Знизу