CC1101 выходит в IDLE после приема пакета а не должен

[greeka]

Всем привет,

не могу понять в чем дело, настраиваю регистр MCSM1.RXOFF_MODE = 11 (3) чтоб он оставался в RX после приема пакета, но он постоянно выходит в IDLE.
Что может быть причиной такого?

[GRAF]

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

[int4880053]

На форуме www.kazus.ru там полно про него написано.

[greeka]

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

GRAF
Код:
Сброс:

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

void CC1101_Reset(void) {
    CSN_LOW();
    Delay_us(5);
    CSN_HIGH();
    Delay_us(40);
    CC1101_WriteStrobe(0x30);
    Delay_us(2);
}

Настройка:

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

void CC1101_Configure(void)
{
    CC1101_WriteReg(CCxxx0_IOCFG0,0x06); //IOCFG0 - GDO0 Output Pin Configuration
    CC1101_WriteReg(CCxxx0_FIFOTHR,0x47); //FIFOTHR - RX FIFO and TX FIFO Thresholds
    CC1101_WriteReg(CCxxx0_PKTLEN,0x3E); //PKTLEN - Packet Length
    CC1101_WriteReg(CCxxx0_PKTCTRL1,0x0C); //PKTCTRL1 - Packet Automation Control
    CC1101_WriteReg(CCxxx0_PKTCTRL0,0x05); //PKTCTRL0 - Packet Automation Control
    CC1101_WriteReg(CCxxx0_ADDR,0x23); //ADDR - Device Address
    CC1101_WriteReg(CCxxx0_CHANNR,0x01); //CHANNR - Channel Number
    CC1101_WriteReg(CCxxx0_FSCTRL1,0x06); //FSCTRL1 - Frequency Synthesizer Control
    CC1101_WriteReg(CCxxx0_FREQ2,0x10); //FREQ2 - Frequency Control Word, High Byte
    CC1101_WriteReg(CCxxx0_FREQ1,0xA7); //FREQ1 - Frequency Control Word, Middle Byte
    CC1101_WriteReg(CCxxx0_FREQ0,0x62); //FREQ0 - Frequency Control Word, Low Byte
    CC1101_WriteReg(CCxxx0_MDMCFG4,0xF9); //MDMCFG4 - Modem Configuration
    CC1101_WriteReg(CCxxx0_MDMCFG3,0x93); //MDMCFG3 - Modem Configuration
    CC1101_WriteReg(CCxxx0_MDMCFG2,0x43); //MDMCFG2 - Modem Configuration
    CC1101_WriteReg(CCxxx0_DEVIATN,0x15); //DEVIATN - Modem Deviation Setting
    CC1101_WriteReg(CCxxx0_MCSM0,0x18); //MCSM0 - Main Radio Control State Machine Configuration
    CC1101_WriteReg(CCxxx0_MCSM1,0x0F); //MCSM1 - Main Radio Control State Machine Configuration
    CC1101_WriteReg(CCxxx0_FOCCFG,0x16); //FOCCFG - Frequency Offset Compensation Configuration
    CC1101_WriteReg(CCxxx0_WORCTRL,0xFB); //WORCTRL - Wake On Radio Control
    CC1101_WriteReg(CCxxx0_FSCAL3,0xE9); //FSCAL3 - Frequency Synthesizer Calibration
    CC1101_WriteReg(CCxxx0_FSCAL2,0x2A); //FSCAL2 - Frequency Synthesizer Calibration
    CC1101_WriteReg(CCxxx0_FSCAL1,0x00); //FSCAL1 - Frequency Synthesizer Calibration
    CC1101_WriteReg(CCxxx0_FSCAL0,0x1F); //FSCAL0 - Frequency Synthesizer Calibration
    CC1101_WriteReg(CCxxx0_TEST2,0x81); //TEST2 - Various Test Settings
    CC1101_WriteReg(CCxxx0_TEST1,0x35); //TEST1 - Various Test Settings
    CC1101_WriteReg(CCxxx0_TEST0,0x09); //TEST0 - Various Test Settings
}

Сгенеренная студией.

После инициализации периферии в МК идет такой вызов:

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

    CC1101_Reset();
    CC1101_Configure();

Далее в прерывании по падающему фронту ноги GDO0 настроенной на получение пакета попадаем в обработчик:

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

void uEXTI_IRQHandler(uint32_t Pin)
{
    HandleStatus = 1;
}

И в основном цикле как только в обработчике выставили флаг:

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

while (1)
    {
        if (HandleStatus)
        {
            HandleStatus = 0x00;
            CC1101_HandleStatus();
        }
    }

Сам CC1101_HandleStatus:

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

void CC1101_HandleStatus(void) {
    uint8_t Length = CC1101_ReadStatusReg(CCxxx0_RXBYTES);

    if (Length & BYTES_IN_RXFIFO) {
        CC1101_ReadBurstReg(CCxxx0_RXFIFO, CC1101_Data, Length);
//        CC1101_RxMode();
    }
    
}

если вызов CC1101_RxMode(); как сейчас закоменчен, то больше приема нет.

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

void CC1101_RxMode(void) {
    CC1101_WriteStrobe(CCxxx0_SFRX);
    CC1101_WriteStrobe(CCxxx0_SRX);
}

Параметры студии:

2017-03-21_1949.png

(16.95 КБ) 670 скачиваний

[Ser60]

Похоже, что проблема, как минимум, в том, что используется дефолтное значение регистра MCSM1, согласно которому чип после RX переходит в IDLE. Запишите в биты 3:2 этого регистра значение 11b.

[greeka]

Извините, не то скопипастил. Обновил. Конечно же этот регистр устанавливается в значение 0x0F (переход в RX после отправки и получения).

[Ser60]

Вообще, в режиме приёма пакета по GDO0, падающий уровень на нём сигнализирует о принятии лишь слова синхронизации. Для момента окончания принятия пакета следует дождаться нарастастающего уровня после того как он упал. Я это делаю обычно так (код для MSP430):

Спойлер

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

      P1IES_bit.GDO0 = 0;         // set INT on low-to-high transition
      P1IFG = 0;               // clear port IF
      P1IE = RST_BTN + GDO0;      // enable port pin interrupts
      __low_power_mode_3();      // wait for receiving the sync word
      
      P1IES_bit.GDO0 = 1;         // sync word received - set INT on high-to-low transition
      P1IFG = 0;               // clear IF
      P1IE_bit.GDO0 = 1;         // enable GDO0 pin INT
      __low_power_mode_3();      // wait for receiving packet in FIFO

[greeka]

Как говорит даташит:

6 (0x06) - Asserts when sync word has been sent / received, and de-asserts at the end of the packet.

На диаграмме не видно, но уровень становится = 1, потом через 1,5 ms падает. Полагаю когда 1 - это прием синк слова, когда 0 - окончание пакета.
У меня настроена автоочистка FIFO по битому пакету (CRC) и собственно пакет как видно на картинке читается корректно.

UPD: Я понял про что вы: настройка инверсии сигнала на линии:

0x02: IOCFG0 – GDO0 Output Pin Configuration
Bit 6: Invert output, i.e. select active low (1) / high (0)

[Ser60]

Да, пожалуй Вы правы насчёт GDO0, я уже подзабыл. Однако, я сейчас настроил один из чипов в Studio на передачу CC-дебаггером, другой на приём в дефолтной конфигурации (в ZIP архиве внизу) без выхода из режима RX. И он действительно из этого режима не выходит по приёму пакета (см. осциллограмму). Пакет состоит из слова "test" с 2 предшествующими байтами номера пакета и байтами RSSI и CRC в конце. Почитайте еррату на свою версию. Чип случаем не китайская подделка? Интересно, что у Вас лежит в регистре 0х31? У меня 0х14 - покупал его года 4 назад.

Спойлер

Кстати, после чтения длины принятого пакета командой 0xFB следует передёрнуть CS и уже потом в следующей сессии читать RX FIFO командой 0xFF.

cc1101rx.png

(66.36 КБ) 918 скачиваний

CC1101.zip

(1.48 КБ) 224 скачивания

[greeka]

А есть подделки CC1101? Как их распознать?

У меня на таких модулях:

Кстати, после чтения длины принятого пакета командой 0xFB следует передёрнуть CS и уже потом в следующей сессии читать RX FIFO командой 0xFF.

У меня так и есть, см. самый первый пост, там сразу после ответа от FB дергается верхняя линия - это CSN

В регистре 0x31 (0xF1) лежит 0x14

[Ser60]

С подделками я дел не имел, но от китайцев всего ожидать можно. Где куплен модуль и сколько он стоит?

[greeka]

На али вестимо. Цена средняя по палате 2.5 на момент покупки.
https://ru.aliexpress.com/item/433M-CC1 ... 0.0.SX5e1j

[Ser60]

Ну не знаю, что и сказать... Похожи на мои, купленные у официального дистрибъютора.

SV400510.JPG

(23.82 КБ) 681 скачивание

[Serg1987]

Хорошо же вам. У меня вон с Si4432 одни баги.

[Ser60]

Хммм, и с силлабовскими у меня никогда проблем не было - работают как часы. Правда, дело довелось иметь только с Si446x серией, приёмником Si4362, передатчиком 4060 и ещё не помню точно какими, но точно не со старой серией Si443x. Сейчас делаю проект на Si4468 с выходной мощностью +20dBm, пока он в стадии разработки. У меня тут, кстати, несколько статей в шерсти про модули на Si найдте. Модули всегда делал под них сам с одним лишь исключением в последней статье. Но в любом случае использовал некитайские модули (в последней статье) и покупал все Si чипы только у официальных дистрибъюторов. С покупкой на Али у меня нулевой опыт, только со слухов знаю, что там бывают подделки.

[greeka]

greeka - если то, о чём пишите, единственная проблема, что мешает Вам подать команду перевода модуля в RX после выгрузки из него пакета? Или имеется опасность пропустить какой-то пакет за время выгрузки?

Ser60 отвечу вам в своей теме.
Вообщем-то проблемы нет, так и делаю. Более того, приемник не рекомендуется долго держать в состоянии приема т.к. он уплывает. Но насторожила эта ситуация, думал что я что-то упустил, ведь должно же работать как заявлено.

Еще мне непонятен такой момент - если я сразу после падения импульса на линии GDO0 буду не пытаться выгрузить пакет, а переключать в режим приема и потом выгружать текущий принятый пакет, при этом будет передаваться новый пакет, будут ли битые данные в RX FIFO?

У меня тут, кстати, несколько статей в шерсти про модули на Si найдте.

Подскажите как статьи искать по автору? Или дайте ссылки на них.

[GRAF]

Страница 2

Details
If a received data byte is written to the RX FIFO at the exact same time as the last byte in the RX FIFO is read over the SPI interface, the RX FIFO pointer is not properly updated and the last read byte is duplicated.

Workaround(s)
For packets below 64 bytes, it is recommended to wait until the complete packet has been received before reading it out.

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

Если используются не амплитудная модуляция, то уход частоты можно компенсировать, в пункте 14.1 даташита сказано. Здесь пример.

[Ser60]

будут ли битые данные в RX FIFO?

Не будут. По модулю hardware бага, что GRAF указал.

Подскажите как статьи искать по автору? Или дайте ссылки на них.

У меня тут несколько статей на тему. Быстрее будет Вам нажать кнопку Профиль под этим моим сообщением, чтобы получить доступ к статьям.

[greeka]

Страница 2

Details
If a received data byte is written to the RX FIFO at the exact same time as the last byte in the RX FIFO is read over the SPI interface, the RX FIFO pointer is not properly updated and the last read byte is duplicated.

Workaround(s)
For packets below 64 bytes, it is recommended to wait until the complete packet has been received before reading it out.

Не понял как это относится к тому, о чем я писал.
Вот пример - у меня пакет на 60 байт + системные 2 байта которые добавляет сам чип. Я получил пакет, CRC сошлось, чип дернул ногой. Я начинаю читать данные из RX FIFO и в этот же момент модуль начинает получать данные (тоже пакет на 60 байт). Под баг этот мы не попадаем, но что будет с данными, которые я еще не прочитал из буфера?

Добавлено after 4 minutes 4 seconds:

У меня тут несколько статей на тему. Быстрее будет Вам нажать кнопку Профиль под этим моим сообщением, чтобы получить доступ к статьям.

А слона-то я и не заметил
Благодарочка!

[Ser60]

что будет с данными, которые я еще не прочитал из буфера?

Они там и будут сидеть пока их не прочитаете или не очистите FIFO. Насколько я помню, последний организован как кольцевой буфер. Если для вновь принимаемых байтов не будет места в нём, чип перейдет в режим RXFIFO_OVERFLOW и приём прекратит.