[AndreyS 0]

Добрый день.

 

Начал работу с микросхемой CYRF6936 (до этого работал с CYWUSB693*) и возникли проблеммы.

 

Ну для начала переход с LS на LP оказался не такой тривиальный как я думал сначала. Но это просто к слову.

 

По сути вопроса.

 

Имею две одинаковые платы (условно приемник и передатчик). Основной клок заведен от микроконтроллера (формируется аппаратно путем деленяи базовой частоты 24МГц на 2. Т.е. получаю 12 МГц) на CYRF (т.е. тактую CYRF внешним источником).

Схема включения CYRF взята из даташита (без использования внутреннего преобразователя).

Произвожу инициализацию микросхемы (код одинаковый на обоих платах) и вхожу в бесконечный цикл ожидания приема и при отсутствии данные передачу синхропакета.

И по идее должен получать установившееся соединение. По факту этого не происходит. Поставил датчик тока по питанию CYRF, для контроля работы ВЧ цепей микросхемы. Нормально наблюдаю рабоут передающей части и в нужный момент принимающей части (т.е. потребление в нужный момент меняется). Делаю вывод что микросхема работает правильно.

Но так как соединения у меня так и не получается - значит есть ошибка в программе.

 

Помогите пожалуйста с правильностью инициализации! И вообще правильно ли я произвожу работу с микросхемой в процедурах чтения и передачи?

 

Может быть все же проблемма в плате? Много неизвестных, так как этот корпус распаиваем в ручную феном. Человек который распаивал уже пожег 10 микросхем. Я в шоке. Но дабы быть уверенным со своей стороны, хотел бы получить помощь по программной части.

 

Я произвожу инициализацию микросхемы при запуске системы следующими данными (половину настроек взял из документации, половину из примеров Cypress)

// массив инициализации
code const byte radio_init_data[] =
{
MODE_OVERRIDE_ADR,RST,		// сбрасываем радио CYRF
CLK_EN_ADR,RXF,			// по доке нужно сделать при инициализации
AUTO_CAL_TIME_ADR,AUTO_CAL_TIME_MAX,	// по доке нужно сделать при инициализации
AUTO_CAL_OFFSET_ADR,AUTO_CAL_OFFSET_MINUS_4,	// по доке нужно сделать при инициализации
// временно перевел XOUT в CMOS
IO_CFG_ADR,(IO_CFG_RST&~XOUT_OD),//(IO_CFG_RST|XOUT_OD),	// настройка портов. Все как CMOS и IRQ активно в нуле, XOUT открфтый коллектор
// было убрано
XTAL_CFG_ADR,0x08,					// по доке нужно сделать при инициализации
RX_CFG_ADR,((RX_CFG_RST)&~(RXOW_EN)),	// автоподстройка включена и перезапись буфера выключена
TX_OFFSET_LSB_ADR,0x55,			// множитель для синтезатора. Частота 732.6 Гц
TX_OFFSET_MSB_ADR,0x05,			// Это частота между каналами. При переключении
XACT_CFG_ADR,(ACK_EN|END_STATE_SLEEP|ACK_TO_15X),	// режим ответа. Авто ACK включен, после ACK в sleep и таймаут = 15x
TX_CFG_ADR,(PA_4_DBM|DATCODE_LEN_32|DATMODE_8DR),	// 32 chip code и 250кБит 8DR
FRAMING_CFG_ADR,(SOP_EN|LEN_EN|4),		// включаем поддержку SOP пакета для 32 chip code
PREAMBLE_ADR,0x01,				// количество повторов преамбулы (0 - отключает преамбулу)
PREAMBLE_ADR,PREAMBLE_CODE_LSB_RST,					// преамбула
PREAMBLE_ADR,PREAMBLE_CODE_MSB_RST,					// преамбула
PWR_CTRL_ADR,((PWR_CTRL_RST|LV_IRQ_TH_1P8_V|PMU_OUTV_2P7)&~PMU_EN),	// выключаем PMU (неиспользуется аппаратно)
// временно разрешил работу XOUT
XTAL_CTRL_ADR, XOUT_FNC_XOUT_FREQ,//XOUT_FNC_GPIO,		// порт XOUT переводим в программный и незадействуем
DATA32_THOLD_ADR,0x03,//0x05,				// устанавливаем значение в 05 для типовых приложений
RX_OVERRIDE_ADR,(ACK_RX),
TX_OVERRIDE_ADR,(ACK_TX_SEN),
#ifdef CRC_SEED
CRC_SEED_LSB_ADR,((byte)CRC_SEED),			// загружаем CRC seed
CRC_SEED_MSB_ADR,(CRC_SEED>>8)			// загружаем CRC seed
#else
CRC_SEED_LSB_ADR,0x00,				// загружаем CRC seed
CRC_SEED_MSB_ADR,0x00				// загружаем CRC seed
#endif
};

 

В основном цикле произвожу установку канала (всегда константа) и записываю PN коды.

Далее произвожу попытку получить данные и в случае неудачи произвожу попытку передать синхропакет.

И так по циклу.

 

Вот этот цикл

	// цикл проверки соединения
	do{
		// устанавливаем канал
		Radio_set_channel(Protocol.channel);
		if (Channels[Protocol.channel-1].present && Channels[Protocol.channel-1].connect)
			set_pn_code(&PN_CODES[Channels[Protocol.channel-1].PN_code]);
		else
			reset_pn_code(0);
		// слушаем канал
		Protocol.packet_len=recive_radio(&Protocol.dat.mass);
		// читаем уровень шумов
		Channels[Protocol.channel-1].rssi=Radio_RSSI_read();
		if (!Protocol.packet_len)
		{// данных нет
			if (Channels[Protocol.channel-1].present)
			{
				if (global_time_check(Channels[Protocol.channel-1].bind_time,PROTOCOL_BIND_TIME_OUT))
				{// прошел таймаут, устройство не отвечает
					// сбрасываем соединение
					Channels[Protocol.channel-1].present=0;
					Channels[Protocol.channel-1].connect=0;
				}
			}
			else
			{// Канал пуст. Проверим его на наличие обекта
				// отправляем запрос на соединение
				Bind_req_func();
				if (Radio_count)
				{// нашли канал
					// читаем данные из канала
					Protocol.packet_len=recive_radio(&Protocol.dat.mass);
				}
			}
		}
		if (Protocol.packet_len)
		{// Уточнение. Данные есть
			CommandParser(Protocol.dat.packet.hdr.type);
		}
	}while(1);

 

 

Вот процедуры передачи пакета

 

/*---------------------------------------------------------------------------
ПЕРЕДАЧА ПАКЕТА
Вход:
	Длина передаваемых данных и указатель на буфер с данными
Выход:
	1 = переданы, 0 = ошибка передачи.
---------------------------------------------------------------------------*/
bit transmit_radio(byte buffer_length, byte *tx_buffer)
{
data byte i;
if (Radio_status==RADIO_NOT_USE)
{
	if (buffer_length>(MAX_RX_BUF-1)) return(0);
	// очищаем буфер
	do{
		i=Get_Radio_byte(TX_IRQ_STATUS_ADR);
	}while(!(i&TXB0_IRQ));
	// настраиваем прерывания
	Write_Radio(TX_CTRL_ADR,TX_CLR|TX_CTRL_RST);
	// закачиваем данные
	Write_Radio_data(TX_BUFFER_ADR,buffer_length,tx_buffer);
	// устанавливаем длину
	Write_Radio(TX_LENGTH_ADR,buffer_length);
	// запускаем передачу
	i=Get_Radio_byte(TX_CTRL_ADR);
	Write_Radio(TX_CTRL_ADR,(TX_GO|i));
	// сообщаем о статусе для того что бы позже контроллировать передачу на предмет реповтора данных
	Radio_status=RADIO_TRANSMIT;
	Radio_count=0;
	return(1);
}else return(0);
}

 

Вот процедура контролирующая ход передачи данных

 

/*---------------------------------------------------------------------------
ОБРАБОТЧИК СОСТОЯНИЙ РАДИО
Вход:
	статусная переменная radio
Выход:
	изменение статуса radio
	1 ошибка
---------------------------------------------------------------------------*/
bit radio_control(void)
{
register byte status;
if (Irq_radio)
{
	Irq_radio=0;
	if (Radio_status==RADIO_TRANSMIT)
	{
		status=Get_Radio_byte(TX_IRQ_STATUS_ADR);
		if (status&(TXC_IRQ|TXE_IRQ))
		{// есть прерывание
			status&=(TXC_IRQ|TXE_IRQ);
			if (status==TXC_IRQ)
			{
				if (!Radio_count) Radio_count=1;
				Radio_status=RADIO_NOT_USE;
//					Write_Radio(TX_CTRL_ADR,0x00);
			}
			else
			{
				Get_Radio_byte(RX_IRQ_STATUS_ADR);
				Radio_count++;
				if (Radio_count<TIME_OUT_TRANSMIT)
				// повторяем передачу
					Write_Radio(TX_CTRL_ADR,TX_GO|TX_CTRL_RST);
				else
				{// остановка реповтора
					Radio_count=0;
					Radio_status=RADIO_NOT_USE;
//						Write_Radio(TX_CTRL_ADR,0x00);
					return(1);
				}
			}
		}
	}
}
return(0);
}

 

Вот процедура приема данных

 

/*---------------------------------------------------------------------------
ПРИЕМ ПАКЕТА
Вход:
	Указатель на буфер приема.
Выход:
	Количество полученных байт. Если =0, значит ничего не полученно (или полученно с ошибками).
---------------------------------------------------------------------------*/
byte recive_radio(byte *rx_buffer)
{
data byte i,status=0;//-1;
data dword time;
if (Radio_status==RADIO_NOT_USE)
{
	// инициируем прием.
	Write_Radio(CLK_OVERRIDE_ADR,RXF);
	Write_Radio(RX_CTRL_ADR,(RX_GO | RXC_IRQ | RXE_IRQ));
	Get_Radio_byte(RSSI_ADR);
	// входим в цикл ожидания данных
	time=get_tic_count();
// цикл ожидания данных 20 ms
	while (!global_time_check(time,20))
	{
		if (Irq_radio)
		{// обработчик
			Irq_radio=0;
			status=Get_Radio_byte(RX_IRQ_STATUS_ADR);
			if (status&(RXC_IRQ|RXE_IRQ|RXBERR_IRQ))
			{// есть прерывание
				if (status&(RXE_IRQ|RXBERR_IRQ))
				{// ошибка
					i=Get_Radio_byte(RX_COUNT_ADR);
					if (i)
					{
						Read_Radio(RX_BUFFER_ADR,i);
						while(Spi_busy);
						i=0;
					}
					status=0;
					break;
				}
				else
					i=Get_Radio_byte(RX_COUNT_ADR);
				status=0;
				if (i)
				{
					Read_Radio(RX_BUFFER_ADR,i);
					while(Spi_busy);
					do{
						*rx_buffer++=SPI_mas.dat[++status];
					}while(status!=i);
				}
				break;
			}
			else
			{
				status=0;
				i=Get_Radio_byte(RX_COUNT_ADR);
				i=0;
			}
		}
		status=0;
	}
	// при получении ошибки или завершения приема выводим приемник из режима приема
	// читаем XACT_CFG_ADR
	i=Get_Radio_byte(XACT_CFG_ADR);
	// устанавливаем FRC_END_STATE
	Write_Radio(XACT_CFG_ADR,i|FRC_END_STATE);
	// и ждем пока не сбросит в XACT_CFG_ADR FRC_END_STATE
	do{
		i=Get_Radio_byte(XACT_CFG_ADR);
	}while(i&FRC_END_STATE);
	// отключаем приемник
	Write_Radio(CLK_OVERRIDE_ADR,CLK_OVERRIDE_RST);
	Write_Radio(RX_CTRL_ADR,0x00);
}
return(status);
}

 

Кто применял данную микросхему, какие трудности вообще возникали с ней?

 

PS Под неустановившимся соединением я подразумеваю, что в буфере CYRF, в режиме приема, нет данных (буфер пуст и выход происходит по истечению таймаута 20mS). При этом в режиме приема, по датчику тока иногда наблюдаю синхронные провалы (синхронные с провалами на датчике тока второй микросхемы, находящейся в этот момент в режиме передачи) потребления тока (уменьшение потребеления). Т.е. ощущение что микросхема что-то получила, но в режим передачи подтверждения не перешла (возможно получила что-то битое), но при этом вывалилась из режима приема. Затем опять вошла в режим приема (потребление вернулось на начальный уровень). При этом прерывания об ошибке не возводится. Т.е. нет ошибки BAD CRC.

Изменено 24 июня, 2009 пользователем AndreyS

[AndreyS 0]

Никто данные микросхемы не использует??

 

Я разобраля в своей ошибке (правда пока не могу уверенно назвать ее ошибкой).

 

В инициализации я использовал следующюю настройку регистра (смотри первое сообщение)

 

    RX_CFG_ADR,((RX_CFG_RST)&~(RXOW_EN)),    // автоподстройка включена и перезапись буфера выключена

 

После пересмотра исходников я решил поставить их (исходники от Cypress) настройку

 

    RX_CFG_ADR,(( RX_CFG_RST | FASTTURN_EN | LNA_EN ) & ~( HI | RXOW_EN | AUTO_AGC_EN )),

 

И все сразу заработало.

 

После анализа я выяснил что за нормальную работу ответственны (при остальных настройках) два бита. Сброшенный бит HI и установленный FASTTURN_EN. Причем одновременно (т.е. HI именно должен быть сброшен, а второй соответственно возведен и никак иначе).

 

И вот тут у меня возник вопрос. Я принял решение о состоянии данного регистра после прочтения документации и понял что значение после сброса соответствует работоспособному состоянию (видно, что ошибся). Единственное что я отключил RXOW EN (мне данная ситуация ненужна).

 

Скажите мне пожалуйста, как ДОЛЖЕН БЫТЬ выставлен данный регистр, а не как МОЖЕТ БЫТЬ выставлен?

 

Вот два листа из документов. cypress0.jpg это лист регистра из последнего документа (в нем нет состояния ригистра поумолчанию). cypress1.jpg это лист старого документа. В нем есть default состояние регистра.

[Dr.NoA 0]

С CYRF6936 дела не имел, но по опыту работы с предыдущими приемопередатчиками этого типа (CYWUSB6934 и CYWUSB6935) могу сказать, что не следует абсолютно доверять спецификации, т.к. там достаточно много ошибок было (возможно, сейчас эти ошибки уже исправили). Так что если у вас есть примеры от Cypress, которые работоспособны, то нужно на них тоже ориентироваться.

[AndreyS 0]

С CYRF6936 дела не имел, но по опыту работы с предыдущими приемопередатчиками этого типа (CYWUSB6934 и CYWUSB6935) могу сказать, что не следует абсолютно доверять спецификации, т.к. там достаточно много ошибок было (возможно, сейчас эти ошибки уже исправили). Так что если у вас есть примеры от Cypress, которые работоспособны, то нужно на них тоже ориентироваться.

 

 

Добрый день.

 

Спасибо за ответ. Исходники мне и помогли разобратсья в своей ситуации. Как я погляжу, со времен CYWUSB* прошло много времени, а написание док по беспроводным чипам у них так и хромает (хотя и по CY7C6801* у них доки тоже корявые).

 

В CYWUSB ОБЯЗАТЕЛЬНЫМ условием нормальной работы было прописывание конкретных значений PN кода (абы какие нельзя писать, хотя в доке сказано что можно любые прописывать. Само собой что эти значения должны быть в обоих чипах). В CYRF обязательной настройкой стал регистр RX_CFG_ADR с конкретным значением битов.

[AndreyS 0]

Добрый день.

 

Еще возникли вопросы.

 

При длительно режиме приема или передачи периодически происходит зависание этой микросхемы.

 

Что это значит:

В режиме передачи - это означает следующее. В цикле ожидания прерывания (регистр TX_IRQ_STATUS_ADR) TXC IRQ или TXE IRQ не происходит вызова этого прерывания. Пришлось поставить защитный таймер (иначе прошивка виснит) на 100ms (максимальный цикл передачи при этом, с учет 5 реповторов, 5 ms).

В режиме приема - это означает, что при выходе из режима прием (установкой бита FRC_END в регистре XACT_CFG_ADR), в цикле ожидания установки бита FRC_END происходит зацикливание (т.е. бит не возводится бесконечно).

 

Подскажите пожалуйста, это нормально???

 

В предыдущих версиях Cypress CYWUSB693* такого не происходило НИКОГДА. Чип нормально работал сколько угодно долго.

Ерраты на CYRF6936 я не нашел, зато обнаружил разные исходники в которых запуск на прием и передачу происходит по разному (один из них точно неправильный, исходя из документации), но они не дали мне ответ на подобные зависания.

[AndreyS 0]

Добрый день.

 

Последние вести с полей.

 

Видно этим чипом тут занимаюсь только я (или остальные знают о проблеммах).

 

По поводу зависания чипа.

 

Выяснил что при настроке чипа в бездействии переходить в режим SLEEP происходит его зависание (он через некоторое время просто не просыпается).

Может быть я неправильно делаю общение с чипом (я не делаю каких-либо пауз между запросов в регистры, правда в исходника и документации я не обнаружил по этому поводу ничего. В исходниках так же нет пауз). Можно конечно программно переинитить чип и он опять оживет, но опять не надолго.

В общем настроил работу в бездействии не SLEEP, а в IDLE и все работает нормально (правда кушать стало больше чем планировалось).

Т.е. при бездействии чип переходит не в SLEEP, а IDLE и тогда никогда не зависает.

 

Вторая неприятна вещь.

 

Если в момент приема данных произойдет ошибка приема (RXE возведен по разным причинам), то необходимо опустошить не весь буфер приема, как указано в примере (в документации на этот счет вообще ничего нет). А именно то число байт что уложено в буфере приема самим чипом, это можно узнать прочитав RX_COUNT_ADR (в примере вычитывают весь физический размер буфера приема в чипе). Если делать как в примере, то после ошибки и полного опустошения (да же больше) успешных данных больше не получить (всегда воникает ошибка).

Вычитываю из буфера ровно столько сколько он принял по ошибке и все работат нормально.

 

Кто работает с этим чипом, расскажите назначение следующих бит (FRC SEN и FRC AWAKE) в регистре MODE_OVERRIDE_ADR. Думал после запуска генератора (при инициализации) возвести FRC_SEN, но что-то я не понимаю на что он влияет (его отсутствие пока не влияет на работу).

В старой доке этих бит вообще нет, в исходниках они не применены (только RST). В документации ничего о них нет (кроме описания регистра).

[AndreyS 0]

Добрый день.

 

Все еще нужна помощь людей работавших/работающих с этим чипом.

 

В частности сейчас застрял на очередной особенности этого чипа.

 

Периодически (когда как, максимум через 5 минут работы чипа) происходит его ступор. Т.е. чип продолжает принимать данные (из режима в режим вроде как нормально переключается), но вот только все принятые данные он бракует, сообщая что ошибка приема- буфер полный, при этом число принятых байт в RX_COUNT_ADR = 0. Думал передатчик сбивается и начинает слать лабуду, но как только перезагрузишь приемник опять начинает нормально принимать данные.

 

Так же периодически происходит, что-то с передатчиком, он через (значительно больший промежуток времени чем у приемника) промежуток времени видимо начинает передавать что-то криво, так как перезагрузка приемника не восстанавливает работу. Только перезагрузка передатчика.

 

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

 

Помогите разобраться в проблеме!! :(

[AndreyS 0]

Добрый день всем.

 

После пересматривания исходников от Cypress нашел ответ по проблеме зависания Radio при переходе из SLEEP режима. Программисты Cypress производят перевод Radio сначала в IDLE и только после этого начинают с ним работу. В документации о необходимости такой процедуры ничего не сказано. Указано лишь время просыпания Radio из SLEEP режима (5 ms).

 

Так и осталась тайной для меня почему через некоторый промежуток времени Radio на прием информации начинает браковать все входящие пакеты (сообщает о битом CRC). Наустанавливал в свой код столько костылей из Cypress'овских исходников, но однозначно сказать что они помогли я не могу (приемник так или иначе начинает браковать все входящие пакеты).

 

ЛЮДИ!! ПОМОГИТЕ. ЕСТЬ ТУТ КТО, КТО РАБОТАЛ С ДАННЫМ RADIO КОНТРОЛЛЕРОМ??

 

А то приходится ставить вопрос о применимости данного чипа в дальнейшем.

 

Параллельно производил измерение тока потребления системы от первичного источника питания (не претендую на точные цифры). Когда вся схема спит (CPU на пониженной и выключен генератор {потребление ядра десятки uA, периферия до 100uA}, с аналоговой части снято питание {потребление единицы uA}) получается что RADIO (если верить в то что проц действительно кушает uA) в разных энергосберегающих режимах кушает не совсем паспортные значения.

 

Источник напряжения 1.3 вольта, повышающий преобразователь и LDO формируют 3.3 вольта (повышающий формирует 3.7 вольта) оценочное КПД 70%

Теперь исходя из этих данных имеем следующее:

PMU не выключено, так как не использую.

Radio в SLEEP потребление на батареи 8 mA по расчета ток Radio = примерно (1.3*8mA*0.7)/3.3= 2 mA это много. По datasheet 10 uA (если PMU включено то 35 uA)

Radio в IDLE потребление на батареи 12 mA ток Radio = примерно 3.3 mA Тоже много, по доке около 1 mA.

 

Кончено я не точно смотрел КПД преобразователя питания, но у меня в системе есть светодиод на него даю 3 mA. По потреблению им тока от батареи я и вычислил КПД преобразователя.

 

ЛЮДИ!! ПОМОГИТЕ. ЕСТЬ ТУТ КТО, КТО РАБОТАЛ С ДАННЫМ RADIO КОНТРОЛЛЕРОМ?? Дайте плиз рабочий исходник процедуры включения этого чипа в режим приема

[AndreyS 0]

Вдогонку.

 

Как мне кажется, я нашел корень зла. Но не знаю как от него правильно избавиться.

 

В общем регистр RX_IRQ_STATUS_ADR по истечению некоторого времени не сбрасывается (т.е. даже после выполнения необходимых условий для сброса соответствующих флагов). Сейчас я отслеживаю количество таких глюков за единицу времени и при их превышении переинициализирую Radio "налету". Это пока помогает мне удерживать логическое соединение без реконнекта.

[AndreyS 0]

Добрый день всем.

 

Вроде как я разобрался с этим "замечательным" CYRF6936.

 

Подвисание чипа на прием вылечилось (благодаря аналогичным видимо исследованиям человека делавшего для себя систему управления модели самолета).

 

Замечательная фича Кипреса, позволяющая поумолчанию принимать пакеты от старых LS приемников, была всему виной.

 

Отключение ее в регистре RX_OVERRIDE (бит FRC RXDR запрещающий приемнику пытаться воспринять пакеты других скоростей и заставляющий приемник работать только на скорости TX) убрало зависание приемника и необходимости его перезагрузки "на лету".

 

Плюс для надежности приема полезных пакетов я понизил скорость до 125 Кбит с соответствующим включением длины псевдокодов с 32 бит до 64 бит.

 

Но основное это все же RX_OVERRIDE.

 

Надеюсь мои записи кому-нибудь в дальнейшем сэкономят время.

[gruzdev 0]

я выложил свой драйвер под linux для этого чипа, возможно кому-то пригодится:

https://github.com/gruzdev/cyrf6936