Проблема с SI4432. Нужна помощь.

Serg1987

Да, я делал так. В функции SI_SendCommand 4 аргумента: 1 - указатель на массив команды, 2 - длина команды, 3-ответ на команду (если требуется), 4-длина ответа в байт (если =0, то команда не требует ответа)
После каждой команды проверяю NIRQ и сбрасываю его чтением статуса. Все дефайны в настроечном файле я перевел в массивы типа uint8_t*

Спойлер

status=SI_SendCommand(&RF_POWER_UP[0],7,&c_responce[0],0);
if(status==SI_OK)
{
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_GPIO_PIN_CFG[0],8,&c_responce[0],8);
//--------------------------------------------------------------------
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_GLOBAL_XO_TUNE_2[0],6,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_GLOBAL_CONFIG_1[0],5,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_INT_CTL_ENABLE_2[0],6,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_FRR_CTL_A_MODE_4[0],8,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_PREAMBLE_TX_LENGTH_9[0],13,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_SYNC_CONFIG_6[0],10,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_PKT_CRC_CONFIG_12[0],16,&c_responce[0],0);
//---------------------------------------------------------------------
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_PKT_RX_THRESHOLD_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_PKT_FIELD_3_CRC_CONFIG_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_PKT_RX_FIELD_1_CRC_CONFIG_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_PKT_RX_FIELD_4_CRC_CONFIG_5[0],9,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_PKT_CRC_SEED_31_24_4[0],8,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_MOD_TYPE_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_FREQ_DEV_0_1[0],5,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_TX_RAMP_DELAY_12[0],16,&c_responce[0],0);
//----------------------------------------------------------------------
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_BCR_NCO_OFFSET_2_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_AFC_LIMITER_1_3[0],7,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_AGC_CONTROL_1[0],5,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_AGC_WINDOW_SIZE_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_RAW_CONTROL_10[0],14,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_RAW_SEARCH2_2[0],6,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_SPIKE_DET_2[0],6,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_RSSI_MUTE_1[0],5,&c_responce[0],0);
//-----------------------------------------------------------------------
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_DSA_CTRL1_5[0],9,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_CHFLT_RX1_CHFLT_COE13_7_0_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_CHFLT_RX1_CHFLT_COE1_7_0_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MODEM_CHFLT_RX2_CHFLT_COE7_7_0_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_PA_MODE_4[0],8,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_SYNTH_PFDCP_CPFF_7[0],11,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_MATCH_VALUE_1_12[0],16,&c_responce[0],0);
if((GPIOB->IDR & NIRQ_Pin)==0) SI_SendCommand(&c_get_int_stat[0],4,&c_responce[0],8);
SI_SendCommand(&RF_FREQ_CONTROL_INTE_8[0],12,&c_responce[0],0);
//------------------------------------------------------------------------
}

После всей настройки, как отправлять данные? Переключение режимов так понял осуществляется командой CHANGE STATE. Т.е. сразу мы должны проверить, какой у нас режим командой REQUEST_DEVICE_STATE. Затем переводим устройство в Ready_mode, (затем TX-Tune ?!

), загнать в буфер данные и переключить в режим TX_MODE. Так?
Однако у меня на запрос REQUEST_DEVICE_STATE вернулись нули. При подаче питания чип сам переходит в режим READY? Или его нужно специально дергать ещё командой CHANGE_STATE. Вот тут я не могу понять.. Если он переходит в режим Ready сам, то почему на запрос о режиме я получаю 0 (в доках 0 значится как: No Change)?

О том что SPI работает корректно я сужу по осциллографу и по команде GET_PART_INFO (он возвращает 0x44,0x61 во втором и третьем байтах, где прописана модель чипа (4461). Всё верно.) Записанные значения в регистры настроек также читаются корректно. Не могу сообразить по режимам.. Как ими управлять то.? И что за режим SPI_Active_Mode такой??

Реклама

Ser60

Посмотрите на мою статью, цитированную выше Там написано как отсылать данные и исходник программы приложен. Кратко, их надо загрузить в FIFO и подать команду режима передечи. Чип сам перейдет в него и выберет необходимые промежуточные состояния. Я не помню навскидку в какой режим чип переходит по подаче питанияния, но после загрузки конфигурации я его сражу перевожу в сом. Из этого состояния он выйдет автоматом при загрузке новых данных для передачи. Короче, посмотрите исходник в статье, многие вопросы отпадут.

Реклама

Serg1987

[uquote="Ser60",url="/forum/viewtopic.php?p=3127545#p3127545"]Короче, посмотрите исходник в статье, многие вопросы отпадут.[/uquote]
Смотрел ещё раньше. Но у вас там АСМ. А с ним у меня также худо как с французским. (

Ser60

Если АСМ проблема, там в статье ещё словами написано как и что. Послал Вам в ЛС архив одного проекта на С для Si4060 с комментариями.

Реклама

Serg1987

И всё равно непонятно с настройками GPIO.! А именно поле NIRQ mode. (в примере 0x01). Т.е. отключив прерывания вообще, как узнавать, какое событие произошло??

За проект спасибо, но он мало чем мне помог. В СИ там только заливаемые байты. Остальное вновь в асм. Внутреннего содержания кода в СИ интересующей меня функции я так и не нашел (вся логика в АСМ):

Итого проблема осталась. Отправляю POWER UP. СTS проседает в 0 и возвращается обратно. Но и NIRQ тоже проседает в 0. При попытке отправки команды для сброса прерывания - GET_CHIP_STATUS, мне возвращается ответ - 0x08,0x08,0x11.. Что означает - CMD_ERROR. Т.е. чип говорит, что команды POWER UP он не знает.

Итого у меня корректно работает только команда о получении информации о радиомодуле.. И всё!! Больше ничего. SPI тот же что и для Si4432. Но там то всё работало, хоть и потребляло больше. Тут наоборот.

Не модули, а говнище какое-то. Надо переходить на Texas Instruments

Уже достало это всё..

Реклама

Ser60

Я Вам прислал архив ВСЕГО проекта. Для успешной компиляции откройте файл Alarm2.uvprojx в Keil. У меня ошибок не выдаётся. Если сами компоновали проект из моих исходников, полагаю, что неправильно это сделали - именно, не включили в свой проект файл si4060asm.s из архива.

alarm.png: (63.88 КБ) 610 скачиваний

Определение функции Send_SI4060 находится в именно этом файле. Она принимает поинтер на массив байтов для передачи по SPI, первый байт которого - длина массива. Я в ЛС словами написал Файл si4060asm.s на АСМе - фактически interrupt-driven драйвер SPI. Для Вашего МК этот файл не интересен. Это единственное, что в проекте на АСМе, всё остальное на С. Внутри функции Send_SI4060 сначала проверяется CTS флаг, который выводится на GPIO1, и в цикле ожидается установка этого флага в 1. Прерывания только для работы на передачу не нужны. У меня в схеме в архиве вывод IRQ даже не используется.

Если-же хотите его использовать, в приёмнике для сброса прерывания посылаю в него лишь 1 байт 0х20. SPI интерфейс в 443х и 446х отличаются. Почитайте этот документ (AN799). В нём, в частности, указано, что

Retrieving status information from the chip requires the following process: issue a command that
addresses what information the host MCU is looking for; wait for the radio to prepare the data (wait for the
Clear To Send Signal), and read the actual status information.

И в статье у меня написано:

перед отправкой в чип байтов по SPI необходимо дождаться высокого уровня сигнала на выводе CTS. На осциллограмме ниже видно, что сигнал CTS падает после приёма чипом первого байта команды, но это не мешает ему принять все остальные байты в той-же команде. Чипу требуется около 20 мкс на обработку команды после завершения SPI сессии.

Вы ждёте установки CTS? Если на запрос статуса чипа получаете 0х08 в качестве CTS в первом байте, то чип не готов предоставить данные. CTS должен быть 0хFF. Или дожидайтесь установки высокого уровня на GPIO1 до посылки команды чтения статуса.

Спойлер

Уверен, что дело не в чипе а в неверном програмировании SPI и/или комуникации с ним. Посмотрите логическим анализатором что творится на линиях SPI и CTS. Выложите сюда диаграмму аналогичную выше. Если нет лог. анализатора - купите, наконец. Без него жизни нет - так и будете тыркаться как слепой. Так и с TI будет, если только пальцем в небо сразу не попадёте. У меня с SI чипами все работает без проблем. Вообще никаких.

Реклама

Serg1987

Я проверяю CTS. И пытался это делать двумя способами. Сразу с помощью команды (GET_CTS_STATUS) по SPI - 0x44. Я ещё проверю интерфейс, но вряд ли дело в нём. Почему тогда команда GET_PART_INFO работает корректно?? (ответ на неё как по даташиту)
Логика такова:
Включаю SPI, жду где-то 10 мс, для установки питания.
NSEL бросаю вниз. Шлю команду. Поднимаю NSEL. Через какое-то время вновь опускаю NSEL и шлю команду GET_CTS (0x44), и смотрю ответ. Если ответ равен 0xFF, то дальше два варианта:
Если ранее посланная команда требует ответа, то после возвращения 0xFF командой 0x44 сразу же считываю ответ. Если команда не требует ответа - поднимаю NSEL вверх. И через какое то время снова вниз для посылки новой команды

На картинке я отправляю POWER_UP. Затем считываю CTS (через SPI). Если вернулось 0xFF, то шлю следующую команду. Так как NIRQ у меня падает в 0, то даю команду - GET_CHIP_STATUS. NIRQ восстанавливается в высокий уровень - прерывание сброшено. Но в ответе я вижу - 0x08,0x08,0x11. Поясню, байт CTS я считываю командой 0x44 и поэтому в ответе я его уже не учитываю. Т.е. полная транзакция при опущенном NSEL на ответ у меня выглядит так: (0x44(это MOSI: прочесть CTS),0xff (далее все MISO:ответ на CTS),0x08,0x08,0x11). Что недвусмысленно говорит о том, что команду POWER_UP чип не принял.

Логика та же что и здесь: http://mgrfq63796.i.lithium.com/t5/imag ... 8344?v=1.0
Пробовал ждать логической единицы и на ноге GPIO1. Успешно дожидаюсь.
Результат тот же. Возникает прерывание. В ответ мне идут - 0xff,0x08,0x08,0x11.

Напомню, что команда GET_PART_INFO читается корректно (т.е. возвращается корректный ответ о ревизии и модели чипа). .

Добавлено позже:
Ещё раз перепроверил интерфейс. SPI четкого разлива.
Итого поменял логику.
1) Ставлю NSEL вниз, отправляю команду POWER_UP, поднимаю NSEL.
2) Жду высокого уровня CTS
3) NSEL вниз.
3) Отправляю команду 0x44 с целью получить единственный байт ответа (поле CTS) (получаю 0xFF)
4) NSEL вверх.
5) Снова жду высокого CTS. Параллельно NIRQ проседает в 0. Произошло прерывание. Надо его считать.
6) NSEL вниз
7) Отправляю GET_CHIP_STATUS чтобы прочитать прерывание
8 ) NSEL вверх
9) жду высокий CTS
10) Читаю регистр прерывания командой READ_CMD_BUFFER 0x44

Ну и как всегда ошибка.. После GET_CHIP_STATUS получаем 4 байта: первое поле - это CTS, остальные - статусы прерываний.

При попытке прочесть инфо о чипе - всё четко и верно.

Так что SPI здесь не причем. На 90 процентов бажат сами чипы.
SPI этот использовался и в Si4432 и вообще в совершенно других проектах. SPI в 4432 и 4461 не разный. Он одинаков - и там и там "SPI mode 0". Другой формат транзакций всего лишь. А по нижнему уровню там всё одинаково. EEPROM с SPI тоже работают. Т.е. везде он работает, а для этих чипов вы хотите сказать нужен какой-то особый SPI?

И про CTS я в курсе - он тоже работает как надо. Проседает в 0 во время отправки команды, затем в 1.

Что касается команды 0x20 (GET_INT_STATUS) то она NIRQ не сбрасывает вообще. И не высылает ответа.

У вас в статье больше акцентировано внимание на процессе приема - передачи. Но совсем мало про саму инициализацию. Про ножку NIRQ так вообще ни слова (на этапе инициализации). После засылки каждой из настройки NIRQ падает в 0.. Т.е. на него можно вообще не смотреть??? Что-то сомневаюсь. В даташите ясно сказано, что пока не прочитается регистр прерываний, чип новую команду не примет. Сейчас меня передача или прием не интересуют. Мне сейчас важна сама инициализация.

Ser60

Я имел в виду, что SPI интерфейс с чипом разный, поскольку следует учитывать CTS в 446х. В остальном такой-же, конечно. В передатчике у меня прерывания не разрешены, и вывод IRQ не используется. Все работает. В приемнике я его разрешаю и он сбрасывается. Так, как делали Вы я никпгда не пробовал. Именно, я всегда сначала засылаю всегда полную инициализацию чипа с контролем CTS на GOIP1 и протом уже перевожу его в сон, на прием, или передачу. Конфигурацию поучаю с помощью WDS. Я сейчас на неделю в отъезде. Приеду - обязательно попробую сделать так, как делаете Вы. О результате сообщу.

Serg1987

[uquote="Ser60",url="/forum/viewtopic.php?p=3132359#p3132359"]О результате сообщу.[/uquote]

Спасибо, буду ждать. Уж очень интересно, как он у вас то работает??
Я так понял, алгоритм у вас инициализации такой - отправляете команду, ждете установки CTS в высокий уровень.. Затем следующую команду.. И так по цепочке..

Но как..?

Я все равно ничего не понимаю. Во всех доках ясно написано, что после каждой команды падает NIRQ, и мы обязаны прочесть статус, иначе другая команда не пойдет.
И такой порядок начиная с POWER_UP

После каждой команды читаем CTS, ждем пока он станет равен "1". А затем проверяя падение NIRQ отправляем GET_INT_STATUS, чтобы очистить прерывания.
Я не могу понять.. Либо сам чип прощает вам такую ошибку (позволяет заливать конфигурацию без сброса прерываний), либо накосячено в доках.. Хотя я склоняюсь к первому.

Я конечно могу сделать по вашему описанию, и возможно чип будет работать как в вашем примере.. Но здесь сразу хочется разобраться, где косяк.. Почему он мне выдает CMD_ERROR в статусе..

Добавлено позже:

Да, про логический анализатор видимо правда. Придется купить. Его у меня нет, но.. вроде руки из того места растут. Пару часов возни с кодом и железом...

В итоге я не буду останавливаться на железе, им не похвастаешь. Но в софте выплюнуло вот это..:

Отчетливо видно, что при посылке команды POWER UP , уровень CTS падает в 0, как и положено. Затем жду когда он поднимется вверх. Поднялся.
Для убедительности читаю CTS командой 0x44. Читаем успешно 0xFF. И .. Здравствуй елка новый год.! После неё CTS опять падает в 0, чего быть не должно же вроде..

Скорость SPI тут я понизил до 24 кбит,с.

Ser60

Не совсем такой. Именно, перед отправкой каждой команды я жду пока CTS выйдет в 1. В начале отправки практически каждой команды CTS падает в 0, но это не должно никого смыщать, т.к. падение его в 0 означает, что чип занят обработкой текущей команды (если она даже ещё не поплностью отправлена) и не готов принять следующую. В процессе отправки команды на CTS не стоит обращать внимание.

Я не вижу, где в ДШ написано, что после установки IRQ в 0 чип не примет следующую команду(?) Дайте ссылку на документ и страницу в нём. В приведённом выше скориншоте также написано, что что если IRQ упал в 0, то он может (CAN not MUST) быть поднят опять чтением статуса. Поэтому на этапе засылки конфигурации в чип у меня прерывания в приёмнике по пину IRQ вообще не разрешены в МК и я на состояние этого пина не обрашаю внимания. Когда конфигурация залита, я даю один бит команды чтения статуса (это сбрасывает все флаги) помещаю чип в сон, и разрешаю в МК прерывание по падающему уровню. Предварительно в конфигурации чипа разрешаю нужные мне прерывания и копирование всех pending прерываний в регистры FRR. Так удобнее работать с прерываниями, т.к. чтение FRR не сбрасывает флаги в радио.

Когда МК засёк прерывание, в его обработчике сбрасывается флаг (МК-вский) и запрещаются в МК прерывания по пину IRQ (на пине IRQ в это время присутствует 0). Далее, я проверяю интересующие меня биты прерываний в FRR и либо читаю пакет либо перехожу к коду после чтения пакета. В этом коде (обычно loop back в цикле main) попсылаю в радио команду 0х44 (1 байт, ничего не читая - это сбрасывает флаги прерывания в радио и возвращает IRQ в 1), затем очищаю бит прерывания в МК и разрешаю прерывания в МК по этому пину. И так далее в цикле.

Вторую картинку я не понял - что в ней плохого и что значит "выплюнуло в софте"??? Если это какой-то эмулятор или что-то программное, я доверяю только лог. анализатору. Ещё раз, в процессе засылки команды CTS будет падать в 0 практически в каждой команде с редкими исключениями (по-моему у меня в статье одно такое исключение показано). До отсылки любой команды и сброса CS в 0 следует дождаться CTS=1. Затем set CS=0 и засылайте команду, не обращая на CTS внимания. По окончении команды CS=1. Вообще, у Вас исходник мой есть. По нему (на С) можно понять какие байты я засылаю.

Serg1987

Я так и понял. Делаем сразу сброс по питанию. Затем:
1) ждем высокого CTS
2) Отправляем команду.
3) Возвращаемся к пункту 1.

[uquote="Ser60",url="/forum/viewtopic.php?p=3133087#p3133087"]Когда конфигурация залита, я даю один бит команды чтения статуса (это сбрасывает все флаги) помещаю чип в сон, и разрешаю в МК прерывание по падающему уровню. .[/uquote]
Скорее всего вы имели ввиду байт а не бит. А какой командой сбрасываете?
Там их 4. Одна общая - GET_INT_STATUS, а другие - отдельно для chip, modem и ph.
Если используете глобальную команду (GET_INT_STATUS == 0x20) то там вроде ещё 4 аргумента нужно отправить, а не один байт ?? (AN625 - стр 33)

Последняя картинка - это верхний уровень. Я сделал логический анализатор небольшой на плате с STM F7.. Сразу идет обработка данных. Потом по завершению он это всё выбрасывает в комп программе верхнего уровня через USB. Написал отдельно небольшой софт, который обрабатывает данные и строит график. Пробовал с разными сигналами - показывает всё как-надо. Правда быстродействие ограничено.

Тут как раз посылается Power UP, потом пытаюсь сбросить статус. Выходит на NIRQ можно не обращать внимания?

Ser60

Я сейчас не дома и код команды очистки флагов не помню. По-моему 0х44 (один байт, конечно, не бит). Если ее дать без аргументов, то сотрутся все флаги. И пеще: я никогда не проверяю CTS чтением статуса по SPI. Всегда мониторю состояние ноги GPIO1. Дефолтно CTS выводится на эту ногу, и я это не меняю. На IRQ в процессе засылки команды внимание не обращаю.

Serg1987

Сбрасывать флаги это конечно хорошо. Но я хочу узнать, например, установился ли бит об успешной передаче пакета или нет? А сделать этого я не могу. Я не могу прочесть регистр статуса. Он мне постоянно возвращает нули. На анализаторе все хорошо - отправляю команду - CTS падает в ноль, жду пока CTS вернется в "1". NIRQ тоже проседает в ноль, но я на него не обращаю внимания. Хотя интересно узнать, отчего произошло прерывание. Но этого я сделать не могу. Так и не разобрался.

Повторюсь. Меня интересует вопрос, как прочитать, что у нас в произошло в статусе прерываний, а не как сбросить его. Сбросить я могу, но прочесть - НЕТ! А я хочу получить подробную информацию из регистров - прошла команда или нет и т.д.

Сделал всё как в вашем примере. После посылки пакета в передатчике NIRQ должен упасть в 0?! Но дело в том что он тут как раз не падает. SPI работает четко. Да, прикупил я себе дешевый анализатор. C SPI всё нормально. Итого, отправку пакета по ноге NIRQ я отследить не могу (она всегда в высоком состоянии, хотя у нас включено прерывание по отправке). Хотя считывая регистр FIFI_INFO я хорошо вижу, что данные туда загружаются, а после команды отправки регистр опять очищается. Но прерывание при этом не проходит.

Ser60

Собрал схему передатчика на SI4461, других у меня на макетке нет.

Спойлер

Вот осциллограмма всей инициализации чипа. На ней видно, что IRQ не падает после засылки в чип команд.

osc1.png: (92.01 КБ) 344 скачивания

Вот начало той-же осциллограммы

osc2.png: (49.66 КБ) 453 скачивания

На следующей осциллограмме показано, что IRQ падает после передачи пакета командой 0х31 и статус ненулевой.

osc3.png: (46.5 КБ) 624 скачивания

Serg1987

Спасибо.! Вроде разобрался. Всетки судя по логу анализатора у меня передатчик работает. Отправляет пакеты. NIRQ садится в ноль. Читаю статус- Packet send. Всё хорошо. Но вот приемник молчит. Попробовал зашить в приемную плату код передатчика - тоже самое, всмысле даже как передатчик вторая плата не работает - пакеты не отправляет. NIRQ вечно высокий. Итого рабочая плата у меня одна, но без второй совсем как-то грустно. Либо где-то в лэйоуте с пайкой либо не знаю, чего второму чипу не нравится.

У вас все хорошо. А у меня шлет такую ахинею:

Сразу даем POWER UP. СTS проседает в 0. NIRQ и MISO остаются в высоком состоянии (зеленые линии). Затем ждем, пока CTS вернется в единицу.. И ждем довольно долго (целых 15 мс). В итоге общая картина такова:

На второй картинке слева тот самый POWER UP. И дооолгое ожидание CTS. Ну подождали. Начали засылать опции. И сразу же NIRQ по какой то причине шлепается вниз на какое-то время. Затем возвращается в единицу. Но.. После засылки пакета в 0 он так и не уходит. Я уже честно не знаю.. Хочется плюнуть и взять уже TI. Они уже давно у меня на примете. С этими СиликонЛабс уже полгода целая история. То потребление высокое, а эти новые вообще не хотят работать толком. И SPI уже перерыл весь, и уровни сигналов, и анализатор какой-никакой взял. Один плачевный финал.

Не поделитесь информацией, у кого вы их покупаете.? Может мне поставщики такое дерьмище суют?? Ну честное слово, уже надоело так.

Ser60

Ну не знаю, чем Вам помочь. Мистика какая-то. Чипы как из разных миров. Я свои покупаю на DigiKey или Mouser. Кстати, я вход SDN просто сажаю на землю. Знаю, что фирма так делать не рекомендует, но у меня проблем с этим не было. Не хочется ещё одну ногу МК под это задействовать и вообще разводка проще. Попробуйте сдуть чип приемника и перепаять. Кстати, подложку чипа к земле припаиваете?

Помню в начале я тоже долго возился. Очень помог анализатор спектра от ТИ MSP-SA430-SUB1GHZ. С его помощью я обнаружил, что модули были несколько на разные частоты настроены, поэтому и не видели друг друга. Оказалось из-за непропайки кристалла на 30 мгц. Если будете с чипами СС от ТИ работать, у меня по ним есть третья часть статьи. Правда, она не охватывает последние их чипы СС13хх. Планирую этим летом их пощупать, уже все железо закуплено. А в плане СС1101 и вообще, очень полезная штука СС-debugger. Стоит около 50USD и подключается к системе SmartRF Studio. Так можно посмотреть наличие излучения и оценить RSSI, передавать пакеты, посмотреть принимаемые пакеты и пр, там в статье что-то по этому поводу написано. Сейчас использую её с работой с любыми Sub1G модулями в качестве приемника. Так можно быть уверенным, что передатчик излучает на нужной частоте и передаёт что надо. С работающим передатчиком уже проще приемник отладить.

Serg1987

Сделал даже программный SPI. Та же история. После POWER UP при засылке опций NIRQ кидается в 0.
Осциллографа под рукой нет. Но.. Что должно быть на ножках 16 и 17 чипа?? Сигнал с кварца 30МГц как понимаю.

Zhuk72

Так ведь 16 - nSEL, 17 - nIRQ. А выводы тактов могут быть с 8-го.
Или вопрос был не о 4432?

Ser60

Что должно быть на ножках 16 и 17 чипа?

Видимо речь идёт про SI446х. Правильно полагаете, что сигнал с кварца. Только осциллографом туда лучше не касаться - внесете расстройку частоты и точно ее таким образом замерить не удастся. У меня при непропайке частота настройки чипа (не кварца) вдиапазоне 915 мгц отличалась от нужной на пару сотен кгц.

Кстати, если у Вас статус не читается, на какую функцию настроена нога SDО? Я не помню что должно быть дефолтно и всегда при начальной конфигурации явно настраиваю ее на вывод сигнала SDO.

Serg1987

Да. На этот раз речь о Si4461. Попробовал я кварц поменять - бестолку. C NIRQ что-то странное. Вопрос следующий. Если отключить все частотнозадающие цепи с балуном. А просто оставить SPI, питание и внешний кварц - чип также должен корректно вести себя при посылке команд? (всмысле как и с полностью собранной платой)? Может у меня дело во внешних цепях? Хотя вряд ли. Вроде SPI не должен зависеть от балуна и т.п.
А статус всётки читается. Дословно цифровое возвращаемое значение не помню. Но в общем - CMD_ERROR и иже с ними. Самое интересное, что при засылке пакета счетчик свободных байт в регистре FIFO_INFO становится равным 58 (64-6) а после команды отправки счетчик свободных байт (FIFI_INFO) вновь обнуляется (точнее становится равным 64). Т.е. типа пакет как послан, но NIRQ молчит до бесконечности. А засылка команд в точности как в примере у вас (правда я перевел в массивы uint8_t). Экспериментировал с POWER UP, а именно с тактированием от внешнего или внутреннего источника (3-й байт). Только воз и ныне там. Даже кварц менял - не помогло. Что-то странное. Итого решено вернуться к дедовскому способу - сделать опять тестовый самопал, заказав чипы у другого поставщика для убедительности.

Код: Выделить всё

uint8_t q1[7] = {0x02, 0x01, 0x01, 0x01, 0xC9, 0xC3, 0x80};
uint8_t q2[8] = {0x13, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
uint8_t q3[5] = {0x11, 0x00, 0x01, 0x00, 0x52};
uint8_t q4[5] = {0x11, 0x00, 0x01, 0x03, 0x60};
uint8_t q5[6] = {0x11, 0x01, 0x02, 0x00, 0x01, 0x20};
uint8_t q6[8] = {0x11, 0x02, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00};
uint8_t q7[13]= {0x11, 0x10, 0x09, 0x00, 0x04, 0x08, 0x00, 0x00, 0x31, 0x00, 0x00, 0x00, 0x00};
uint8_t q8[9] = {0x11, 0x11, 0x05, 0x00, 0x03, 0x8B, 0x89, 0xCB, 0x89};
uint8_t q9[5] = {0x11, 0x12, 0x01, 0x00, 0x84};
uint8_t q10[8] = {0x11, 0x12, 0x04, 0x03, 0xFF, 0xFF, 0x00, 0x02};

uint8_t q11[16] ={0x11, 0x12, 0x0C, 0x08, 0x00, 0x00, 0x00, 0x30, 0x30, 0x00, 0x06, 0x04, 0xA2, 0x00, 0x00, 0x00};
uint8_t q12[16] ={0x11, 0x12, 0x0C, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
uint8_t q13[5] ={0x11, 0x12, 0x01, 0x20, 0x00};
uint8_t q14[16]={0x11, 0x20, 0x0C, 0x00, 0x02, 0x00, 0x07, 0x00, 0x2E, 0xE0, 0x01, 0xC9, 0xC3, 0x80, 0x00, 0x00};
uint8_t q15[5] ={0x11, 0x20, 0x01, 0x0C, 0xB4};
uint8_t q16[12]={0x11, 0x20, 0x08, 0x18, 0x01, 0x80, 0x08, 0x03, 0xC0, 0x00, 0x24, 0x20};
uint8_t q17[13]={0x11, 0x20, 0x09, 0x22, 0x03, 0x0D, 0x00, 0xA7, 0xC6, 0x00, 0x54, 0x02, 0xC2};
uint8_t q18[11]={0x11, 0x20, 0x07, 0x2C, 0x04, 0x36, 0x80, 0x01, 0x5D, 0x07, 0x80};
uint8_t q19[5] ={0x11, 0x20, 0x01, 0x35, 0xE2};
uint8_t q20[13] ={0x11, 0x20, 0x09, 0x38, 0x11, 0xAB, 0xAB, 0x00, 0x02, 0xFF, 0xFF, 0x00, 0x2B};

uint8_t q21[12] ={0x11, 0x20, 0x08, 0x42, 0xA4, 0x02, 0xD6, 0x81, 0x01, 0x29, 0x01, 0x80};
uint8_t q22[5] ={0x11, 0x20, 0x01, 0x4E, 0x40};
uint8_t q23[5] ={0x11, 0x20, 0x01, 0x51, 0x08};
uint8_t q24[16]={0x11, 0x21, 0x0C, 0x00, 0xA2, 0x81, 0x26, 0xAF, 0x3F, 0xEE, 0xC8, 0xC7, 0xDB, 0xF2, 0x02, 0x08};
uint8_t q25[16]={0x11, 0x21, 0x0C, 0x0C, 0x07, 0x03, 0x15, 0xFC, 0x0F, 0x00, 0xA2, 0x81, 0x26, 0xAF, 0x3F, 0xEE};
uint8_t q26[16]={0x11, 0x21, 0x0C, 0x18, 0xC8, 0xC7, 0xDB, 0xF2, 0x02, 0x08, 0x07, 0x03, 0x15, 0xFC, 0x0F, 0x00};
uint8_t q27[8]={0x11, 0x22, 0x04, 0x00, 0x21, 0x64, 0x2E, 0x3D};
uint8_t q28[11]={0x11, 0x23, 0x07, 0x00, 0x2C, 0x0E, 0x0B, 0x04, 0x0C, 0x73, 0x03};
uint8_t q29[16]={0x11, 0x30, 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
uint8_t q30[12]={0x11, 0x40, 0x08, 0x00, 0x3B, 0x09, 0x99, 0x99, 0x22, 0x22, 0x20, 0xFF};