s868

в общем проблему решил путем обьявления массива в самом-самом верху флэша. всем спасибо за внимание.

доброго времени суток. стоит задача обьявить кусок флэш памяти с адреса 0x16000 как массив и задать там фиксированные данные, которые туда зальются при программировании, в процессе работы эти данные будут модифицироваться. выполняемый код размещается как обычно в младших адресах флэша за таблицей прерываний в принципе работает такой код const unsigned __attribute__ ((space(prog), address (0x16000))) CONF[256]={0xAE, 0x12, 0xF0,0x1F,0x19,0x5B, 0x02, 0x73,0x74,0x61,0x74,0x69,0x63,0x69,0x70,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,//APN[33] }; но при компиляции почему-то выполняемый код "улетел" за этот массив Program Memory [Origin = 0x100, Length = 0x2ae00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x100 0x7e8 0xbdc (3036) _02F7B900_at_address_00016000 0x16000 0x200 0x300 (768) .text.U4RXcall 0x16200 0x7a4 0xb76 (2934) .text.TMR3call 0x169a4 0x704 0xa86 (2694) .text.Initmc 0x170a8 0x490 0x6d8 (1752) .dinit 0x17538 0x294 0x3de (990) .text.write_cell 0x177cc 0x1d8 0x2c4 (708) .text.MI2C3call 0x179a4 0x14c 0x1f2 (498) .text.check_begin_end 0x17af0 0x14a 0x1ef (495) .text.U1RXcall 0x17c3a 0x12c 0x1c2 (450) ================как корректно задать массив, чтоб программный код остался на месте? ================как сделать так, чтобы при компиляции нужная мне процедура была размещена в конкретной области памяти с конкретного адреса? вроде как и работает такое __psv__ __attribute__((space(prog), address(0x10000))) void TMR3call(CIM_MSG_DESCR_PTR Msg) { } но опять же за этой процедурой компилятор начинает размещать то, что раньше размещал в начале памяти

Доброго времени суток. Ситуация следующая: один модем звонит другому и передает небольшой пакет данных в режиме CSD (не GPRS). Вопрос - на уровне модемов и сети производится ли проверка достоверности передачи информации и делается ли автоматическая переотправка ее в случае недостоверной передачи данных? Например, передающий модем получает контрольную сумму от приемного, видит что пакет не прошел и отправляет снова и так несколько попыток до победного конца. А у приемника, пока достоверно не будет получен пакет, не появляется сигнал "пакет принят" на программном уровне. Или же переотправку пакета нужно делать своим софтом (модем Q24pl00 Wavecom), организовывать механизм получения контрольной суммы от приемника, сравнения ее с исходной, в случае несовпадения - повторная отправка пакета...

доброго времени суток. для разработки девайса приобрели кит на AD21364, софт VisualDSP 4.5 там есть возможность на ките загружаться с последовательной флэшки АТ25F512 эту часть (boot from spi flash) перенесли в наш девайс, но заменила память на AT45DB041, так как АТ25F512 снято с производства. оказалось что не все так просто и FlashProgrammer заточен под АТ25F512, если используется другая микросхема - нужно модифицировать драйвер для нее (( вопрос - каким образом решить проблему с минимальными затратами: - если выбрать другую микросхему памяти - то где искать к ней драйвер? - адаптировать драйвер под данную микросхему AT45DB041? кто делал подобное и как решил этот вопрос. заранее благодарен.

это сделать в каких полях дескриптора USB_CONFIGURATION_DESCRIPTOR_TYPE?

galjoen, благодарю за ответ. еще вопросик появился. мое устройство сейчас выдает ответы на первые стандартные запросы, согласно логу энумерации флешки, приведеному во втором посте этой ветки. в общем после этого РС видит девайс как ЗАПОМИНАЮЩЕЕ УСТРОЙСТВО ДЛЯ USB. ответы на запросы давались следующие (после того как устройство было адресовано): Reciver request 80 06 00 02 00 00 09 00 (standart configuration descriptor) // Prepare to respond <09 02 12 00 01 01 00 80 64> Reciver request 80 06 00 03 00 00 ff 00(<GetDescriptor (String lang IDs)>) // Prepare to respond <04 03 09 04> Reciver request 80 06 03 03 09 04 ff 00<GetDescriptor (String iSerialNumber)> // Prepare to respond <1A 03 31 00 39 00 36 00 42 00 30 00 41 00 30 00 30 00 30 00 39 00 36 00 36 00> Reciver request 80 06 00 02 00 00 ff 00 GetDescriptor (Configuration) // Prepare to respond <09 02 20(12) 00 01 01 00 80 64 09 04 00 00 02(00) 08 06 50 00 вопрос - где и что в ответах на запросы нужно поменять, чтоб РС увидел девайс не ЗАПОМИНАЮЩИМ УСТРОЙСТВОМ ДЛЯ USB, а чем либо другим (например джойстиком)?

спасибо большое vmp (Дата Nov 21 2007, 14:33) за лог, очень помогло. возникли вопросики касательно некоторых моментов: 1. касательно фрагмента ______________________________________________________________________________ Container title<GetDescriptor (Configuration)> device<1> endpoint<0> status<OK> speed<HS> time<4.408 958 750> Transaction type<SETUP> device<1> endpoint<0> status<ACK> speed<HS> time<4.408 958 750> Packet id<SETUP> devAddr<1> epNum<0> crc5<0x1D> speed<HS> time<4.408 958 750> Packet id<DATA0> length<8> data<80 06 00 02 00 00 FF 00> crc16<0xA4E9> speed<HS> time<4.408 959 083> Packet id<ACK> speed<HS> time<4.408 959 567> ConsecutiveTransaction count<216> type<IN> device<1> endpoint<0> status<NAK> speed<HS> time<4.408 963 050> Transaction type<IN> device<1> endpoint<0> status<ACK> speed<HS> time<4.409 551 517> Packet id<IN> devAddr<1> epNum<0> crc5<0x1D> speed<HS> time<4.409 551 517> Packet id<DATA1> length<32> data<09 02 20 00 01 01 00 80 64 09 04 00 00 02 08 06 50 00 07 05 81 02 00 02 00 07 05 02 02 00 02 00> crc16<0x434A> speed<HS> time<4.409 551 833> Packet id<ACK> speed<HS> time<4.409 552 883> Transaction type<OUT> device<1> endpoint<0> status<ACK> speed<HS> time<4.409 555 850> Packet id<OUT> devAddr<1> epNum<0> crc5<0x1D> speed<HS> time<4.409 555 850> Packet id<DATA1> length<0> crc16<0x0000> speed<HS> time<4.409 556 167> Packet id<ACK> speed<HS> time<4.409 556 500> ______________________________________________________________________________ как я понимаю, осуществляется запрос на дескриптор конфигурации, длина которого составляет 9байт судя по документации. до этого приходил аналогичный запрос на длину 9байт (и они были отправлены - все согласно штатному расписанию усб), а теперь он снова пришел, но уже ожидается 256 байт. (1-й вопрос: почему отправляется повторный запрос 80 06 00 02 00 00 FF 00 и каков формат ответа на него) 2. также непонятно, почему на запрос 9-байтного дескриптора отправляется ответ не 9 байт, а 32 (!). я смотрел исходники на ИАРе и там тоже почему-то этот дескриптор был МАЛО ТОГО что длинее 9байт, да еще и имел в своем составе другие дескрипторы: #pragma data_alignment=4 const Int8U UsbStandardConfigurationDescriptor[] = { sizeof(UsbStandardConfigurationDescriptor_t), UsbDescriptorConfiguration, (1*sizeof(UsbStandardConfigurationDescriptor_t)+ 1*sizeof(UsbStandardInterfaceDescriptor_t)+ 2*sizeof(UsbStandardEpDescriptor_t)), (1*sizeof(UsbStandardConfigurationDescriptor_t)+ 1*sizeof(UsbStandardInterfaceDescriptor_t)+ 2*sizeof(UsbStandardEpDescriptor_t)) >> 8, 1, 1, 0, UsbConfigurationCommmonAttr, UsbConfigPower_mA(100), sizeof(UsbStandardInterfaceDescriptor_t), UsbDescriptorInterface, 0, 0, 2, UsbDeviceClassStorage, MscSubClassScsi, MscProtocolBulkOnly, 0, sizeof(UsbStandardEpDescriptor_t), UsbDescriptorEp, UsbEpIn(BulkInEp>>1), UsbEpTransferBulk, BulkInEpMaxSize, BulkInEpMaxSize>>8, 0, sizeof(UsbStandardEpDescriptor_t), UsbDescriptorEp, UsbEpOut(BulkOutEp>>1), UsbEpTransferBulk, BulkOutEpMaxSize, BulkOutEpMaxSize>>8, 0, 0, }; ============ но простите, UsbStandardInterfaceDescriptor и UsbStandardEpDescriptor должны по идее отправляться на запросы типа 80 06 00 04 .... и на 80 06 00 05 в ОБЩЕМ НЕПОНЯТНО ((( 2-й вопрос: почему UsbStandardInterfaceDescriptor и UsbStandardEpDescriptor выдаются на запрос UsbStandardConfigurationDescriptor а не на свои индивидуальные? 3. в моей программе выдаются ответы на запросы, согласно логу энумерации флешки (на XPsp1 на high speed) и до приведеного выше момента (включительно) они совпадают. но после этого вместо запроса Packet id<DATA0> length<8> data<80 06 00 03 00 00 FF 00> у меня появляется запрос <80 06 00 06 00 00 0a 00> на уточняющий дескриптор устройства.... 3-й вопрос: что мне ответить на запрос <80 06 00 06 00 00 0a 00>? заранее благодарю.

доброго времени суток. прошу помощи - не получается никак с усб-контроллером на чипе STR912FA. осуществляю инициализацию регистров, в процессе работы устанавливается бит USB_ISTR_bit.RESET (I received bus reset), после что нужно сделать чтоб увидеть в буфере 0-й точки запрос SETUP reqeust? корректнее сконфигурировать 0-ю точку (как)? ответить на сигнал сброса установкой каких-то битов в каких-то регистрах (каких)? ========================== #include <iostr912f.h> int main () { SCU_PRR0_bit.RST_USB = 0; //USB RESET enable SCU_PCGR0_bit.USB48M = 0; //1: 48 MHz USB clock stop SCU_PCGR0_bit.USB = 1; //1: USB peripheral clock running SCU_PRR0_bit.RST_USB = 1; //USB RESET disable SCU_PCGR1_bit.GPIO7 = 1; //GPIO7 ON SCU_PRR1_bit.RST_GPIO7 = 1; //GPIO7 RESET disable SCU_GPIOOUT7 = 0x5555; // GPIOOUT7 GPIO7_DIR = 0x01; // output GPIO7_DATA = 0xFE; // output SCU_CLKCNTR_bit.USBSEL = 0x1; //USB 48 MHz Clock Selection 00: fMSTR (default) USB_CNTR = 1; //1: Force a reset of the USB Peripheral, SCU_PCGR0_bit.USB48M = 1; //1: 48 MHz USB clock running // Init controls endpoints GPIO7_DATA = 0xFF; // output USB_CNTR_bit.FRES = 0; // Exit from suspend USB_CNTR_bit.ESOFM = 0; USB_CNTR_bit.RESUME = 0; USB_CNTR_bit.LP_MODE = 0; USB_CNTR_bit.FSUSP = 0; // Must be 0 USB_ISTR = 0; GPIO7_DATA = 0xFE; // output m22: if (USB_ISTR_bit.RESET == 0)goto m22; USB_ISTR_bit.RESET = 0; // настройка конечной точки 0 USB_BTABLE = 0x07E8; USB_DADDR_bit.EF = 1; *((long*)0x700007E8) = 0x00080000; *((long*)0x700007EC) = 0x10080008; USB_EP0R_bit.EP_TYPE = 0x01; USB_EP0R_bit.EA = 0x00; USB_EP0R_bit.STAT_RX = 0x01; m23: if (USB_ISTR_bit.CTR == 0)goto m23; for(;;) ; } ============================================= ожидалось что после этого в ячейках памяти начиная с адерса 0х7000000 (буфера 0-й точки) обновится инфа (окажется запрос с хоста), но его там нету(( помогите плиз.

Vladimir_T, примите запоздалое СПАСИБО) итак, процессор STR912FAW44 в документации на него - в частности в описании усб контроллера - имеется двоякое трактование структуры Packet buffer areas: на стр.362 показано чередование областей ADDR и COUNT каждой контр.точки ..................... ADDR0_TX COUNT0_TX ADDR0_RX COUNT0_RX ...................... а в описании на стр.391 указано, что 32-битный регистр USB_ADDRn содержит два 16-битных ADDR, то есть чередование получается ..................... ADDR0_TX ADDR0_RX COUNT0_TX COUNT0_RX ...................... собственно говоря - вопрос: какова истинная структура Packet buffer areas. спасибо за внимание. и еще. после анализа громоздких исходников, которые шли к ИАРу, была сделана попытка простейшей инициализации усб-контроллера (для отладочной платы STR912-SK) согласно даташиту. то есть лаконично написать все то, что там было размазано #include <iostr912f.h> int main () { SCU_PRR0_bit.RST_USB = 0; //USB RESET enable SCU_PCGR0_bit.USB48M = 0; //1: 48 MHz USB clock stop SCU_PCGR0_bit.USB = 1; //1: USB peripheral clock running SCU_PRR0_bit.RST_USB = 1; //USB RESET disable SCU_PCGR1_bit.GPIO7 = 1; //GPIO7 ON SCU_PRR1_bit.RST_GPIO7 = 1; //GPIO7 RESET disable SCU_GPIOOUT7 = 0x5555; // GPIOOUT7 GPIO7_DIR = 0x01; // output SCU_CLKCNTR_bit.USBSEL = 0x0; //USB 48 MHz Clock Selection 00: fMSTR (default) USB_CNTR = 1; //1: Force a reset of the USB Peripheral, SCU_PCGR0_bit.USB48M = 1; //1: 48 MHz USB clock running GPIO7_DATA = 0xFF; // output // Init controls endpoints // Clear USB Reset USB_CNTR_bit.FRES = 0; USB_CNTR_bit.ESOFM = 0; USB_CNTR_bit.RESUME = 0; USB_CNTR_bit.LP_MODE = 0; USB_CNTR_bit.FSUSP = 0; // Must be 0 USB_BTABLE = 0x07E8; USB_DADDR = 0x0080; *((long*)0x700007E8) = 0x00080000; // установка адресов для двух буферов точки0 *((long*)0x700007EC) = 0x10080008; //установка COUNT для них же USB_ISTR = 0; USB_CNTR = 0; USB_EP0R = 0x3230; USB_EP1R = 0x00; USB_EP2R = 0x00; GPIO7_DATA = 0xFE; // output m22: if (USB_ISTR_bit.CTR == 0) goto m22; for(;;) ; } ===================================================================== предполагалось, что в буфер точки0, который расположен в начале Buffer table усб-контроллера, окажется запрос компутера о дескрипторах или статусе устройства (то есть буфер изменит свое содержимое) и будет установлен USB_ISTR_bit.CTR (Correct Transfer: This bit is set by the hardware to indicate that an Endpoint has successfully completed a transaction). но ничего этого не происходит(( чего сделали не так?

Доброго времени суток. В комплекте с отладочной платой IAR STR912-SK шли мощные исходники, один из которых превращал плату в MassStorage - то есть можно было всунуть флэшкарточку в разъем на плате, виндовс через УСБ-порт определял плату как дисковый накопитель (без драйверов) и можно было смотреть-редактировать файлы с карточки. На неискушенного начинающего разработчика это произвело те же впечатления, какие произвело блестящее зеркальце на туземцев с племени Тумба-Юмба! Дальнейшее изучение громоздкого исходника ввело этого же разработчика в состояние легкой прострации. Задача состоит в написании программки для STR912, которая настроит его следующим образом: - соединение через УСБ - виндовс определит дисковый накопитель (появится новый диск) - на накопителе будет несколько маленьких файлов (размещенные во флэш-памяти АРМа по определенным адресам), эти файлы будут видны в виндовсе и можно просмотреть их содержимое и модифицировать. Прошу отослать к литературе, которая обьяснит - какой пакет данных АРМ должен отправить через УСБ, чтоб его определили как нужное устройство, с нужным файловым соодержимым. Спасибо.

действительно не хватало включить перифирию, процесс затянулся всвязи с опечаткой в даташите производителя - неверно указан адрес 14 SCU_PCGR0 Reserved Peripheral Clock Gating Reg. 0 48 SCU_PCGR1 Reserved Peripheral clock Gating Register 1=========18 а не 48 1C SCU_PRR0 Reserved Peripheral Reset Reg. 0 в завершении темы публикую законченый шэдэвр простейшей программы на ассме, которая инициализирует порт на вывод и выводит в него 0х55 в замкнутом цикле. надеюсь кому-то это поможет. =============================================== NAME main PUBLIC main COMMON INTVEC:CODE CODE32 B main RSEG ICODE:CODE s_gpout3 dc32 0x4c002050 //SCU_GPIOOUT3 (16 бит) pcgr1 dc32 0x4c002018 //SCU_PCGR1 (32) prr1 dc32 0x4c002020 //SCU_PRR1 (32) mgr1 dc32 0x4c002028 //SCU_MGR1 (32) pecgr1 dc32 0x4c002030 //SCU_PECGR1 (32) s_gpt3 dc32 0x4c002090 //SCU_GPIOTYPE3 (8) gp03sel dc32 0x48009420 //GPIO_SEL (8) gp03dir dc32 0x48009400 //GPIO_DIR (8) data3 dc32 0x480093fc //GPIO_DATA (8) CODE32 main nop nop nop nop //SCU_PCGR1_bit.GPIO3 = 1; ldr r0,pcgr1; mov r1,#0x02; strb r1,[r0,#2]; nop; //SCU_PRR1_bit.RST_GPIO3 = 1; ldr r0,prr1; mov r1, #0x02; strb r1,[r0,#2]; //SCU_MGR1_bit.MSK_GPIO3 = 1; ldr r0,mgr1; mov r1, #0x02; strb r1,[r0,#2]; //SCU_PECGR1_bit.GPIO3 = 1; ldr r0,pecgr1; mov r1,#0x02; strb r1,[r0,#2]; nop; //GPIO3_SEL = 0; ldr r0,gp03sel; mov r1, #0x0; strb r1,[r0]; // GPIO3_DIR = 0xFF; ldr r0,gp03dir; mov r1, #0xff; strb r1,[r0]; // SCU_GPIOTYPE3 = 0; ldr r0,s_gpout3 ; mov r1, #0x0; strb r1,[r0]; // SCU_GPIOOUT3 = 0x5555; ldr r0,s_gpout3; mov r1, #0x55; strb r1,[r0]; strb r1,[r0,#1]; main1 // SCU_GPIOTYPE3 = 0; ldr r0,data3 ; mov r1, #0x55; strb r1,[r0]; B main1; END main ================== всем спасибо, и удачных проектов!

спасибо, ребята.

как?) какой регистр за это отвечает?

Сэр Сергей Борщ, благодарю за советы. К сожелению написаный фрагмент тоже не работает нужным образом( судя по всему алгоритм инициализации порта неправильный(( вроде все делается согласно даташиту, но порт на вывод не удается настроить