I'm trying to use an Si4463 based RFM26W module, but the SDO pin never goes low, so I can't read anything from it. After sending the POWER_UP API command, the GPIO-1, that is configured as default for CTS output, goes low, appropriately as according to manual, and the current consumption rises to 1.8mA. However, to any API request the SDO line remains high.
I attache an image of the logic analyzer screen showing the POWER_UP sequence. The uppermost channel shows the GPIO-1/CTS output, channel 5 MISO is the SDO line.
Can anyone please help me out, what can be wrong?
What a coincidence...
Looks like you've been burning the midnight oil....so have I.
Within the last month, I bought 5 Hope modules from Anarduino.com.
It's the same Hope Module (RFM26W)...and I'm experiencing the exact same issue.
I'm driving the module on a new custom Atmel Atmega32u4 board I designed.
I was low on pins and decided not to employ interrupts, but just use manual CTS polling to monitor the control of the board.
So, I only included the MOSI, MISO, SCK, NSEL(chip select), SDN and ANTENNA in the design.
I don't have the NIRQ, TX, RX, or any GPIO's wired.
Of course I've got the VCC and two GNDs wired.
My new board design is working like a champ...except the radio module,
I don't have a scope...which is a bummer.
What model of Saleae do you have? How do you like it?
This is my first stab at a hardware project, and it's becoming clear that a scope is probably a necessity.
Like you, I'm not getting past "Power_Up".
Everything comes back x'FF'.
If you haven't already...be sure to get App Note AN625 off this website.
It details the si4465x API Commands and Properties.
I took a look at your scope data...
I noticed your Power Up command was x'02', x'00', x'01'.
The APi description says the second byte of x'00' will keep you in the bootloader.
I don't think you want to remain in the bootloader....but you want to boot the chip's main application...which is a byte setting of x'01'
The APi description says the third byte of x'01' indicates a TCXO is used.
I don't know what a TXO is...but the other option is XTAL(which denotes a 30 MHz crystal to drive the chip).
And I do think the RFM26W has a 30 MHz crystal....
So the third byte needs to be a x'00' which denotes a crystal.
So try to change the last two bytes of the power up command.
The resulting command will be: x'02', x'01', x'00'.
The fact that the current went up to 1.8mA means the chip at least recognized the command(first) byte.
I'll keep pounding away at it from my end, and I will post any break throughs.
I hope you'll do the same for me....
It's usually one little thing that stuffs things up.
Once you get past that...things go more smoothly.
I tried all 4 combinations of bytes 2 and 3 using x'00' and x'01'...and none fixed the issue.
Maybe you can give it a try.
It’s good to know that I’m not the only one to struggle with this RF26 or Si4463, who knows what this is at last. I’ve already downloaded and studied every available documentation and demo code. My setup is exactly the same as yours apart from the CPU which is a PIC24FJ128GC. At first I only wanted to test communication by calling PART_INFO API function. As it failed I programmed exactly the same sequence that is in the RFDK_RFM26_V2.1 demo code. This demo starts that way, but the whole thing fails from the point where CTS goes down. At that point SDO should go down as well.
I tried to gate the CTS signal into the SDO line, so the code could wait until the CTS went up, still to no avail.
My distributor indicated the problem to HopeRF more than a month ago, no reply.
The logic analyzer is an 8 channels Chinese clone, but it’s perfect for this kind of trouble-shooting.
If I can get any further I will post it here.
I didn't have a chance to work on the problem today.
I also looked at the RFDK_RFM26_V2.1 demo code.
I don't know any thing about PIC chips.
But the code was written for a type of.
But I did follow the code enough to see that the guy who wrote the code was "bit banging" the SPI.
I'm using the SPI built into the ATMega chip.
I've scoured the Internet for issues with this module.
There is a site called Radio Head that deals specifically with creating Arduino libraries for these Hope Modules.
I don't use the Arduino IDE, I use free Studio 6 from Atmel.
They both rely on the open source gcc compiler under the covers.
I'm starting to look at the Radoi Head RFM26 source files...RH_RF24.cpp and RH_RF24.h.
They use C++ which I'm not fond of...straight C for me.
They partially use a WDS generated layout.
I haven't even begun to dig into WDS.
I just want to get the PART_INFO and FUNC_INFO commands returning valid data as a sanity check.
If this turns out to be a hardware issue...I wish HopeRF would just fess up.
It would relive a lot of head banging on our parts....
I don't think there is an edit function for posts...
The one sentence should have said..."But the code was written for a type of PIC."
Maybe I've had a breakthrough of sorts.
After sending the POWER_UP command, then follow it with the GET_INT_STATUS command.
The GET_INT_STATUS command is 0x20 followed by 0x00, 0x00, and 0x00.
The three bytes of zeros are reading three interrupt status registers and clearing any interrupts that are set.
After I did that I was able to get PART_INFO and FUNC_INFO to partially work.
I mean partially because now each command returns 0x00's in the response stream rather the 0xff's.
Response times to get to CTS also seem extremely slow.
I'm about ready to hang it up on this module and go with a different one.
Sprinkled throughout the Radio Head library for this chip are comments on how flakey it is.
They also mention that the A1 version of the chip can't do one byte commands.
If my board is an A1 chip, that may explain the 0x00's.
From the complete lack of posts on the Internet concerning this module, I can only deduce that there is just no one using it.
The only reason I chose this module was the 1,000,000 bits per second transmit rate it claims.
I don't want to be a trailblazer, they're the ones with the arrows in their backs.
Let me know if the GET_INT_STAT works...and please tell me what you are seeing for the times these all three commands actually are taking before you are seeing the Module respond with CTS.
If you can get zeros from the SDO line it's really a breakthrough meaning the module is capable to pull it down.
As I noticed that the nIRQ was pulled down I also issued the GET_INT_STAT, but nothing happened.
If I poll the CTS with the 0x44 command, it always responds FF. If I and-gate the CTS GPIO out with SDO to my SDI, then it never returns 0xFF so it exits with time-out, despite that I increased the 5000 trials in the demo to 65535. When I send the 0x44, CTS goes down, when I raise the nSEL, CTS goes back high. Maybe I should read several bytes after one 0x44 command, until it reads FF?
I'll try it if I have some time, but now I can't waste all my time on this dubious thing.
I'm giving up on this module...or, more specifically...this chip...
With most radio chips you are reading or writing directly into banks of control registers.
You pass an address byte over the SPI to the radio with the high order bit set or clear to indicate a read or write. And then, the read or write happens immediately as the next byte from the master gets shifted into the radio.
In all cases, your reads and writes to the control registers are happening in real time. Any real-time system needs to guarantee this type of deterministic access.
If there is latency, it's not with the physical reading or writing of control registers. The latency is more due to the actions the registers impose on the radio.
For instance, if you write a certain register that changes the state...you may be required to pause enough time for that state to become active. You may be waiting for an interrupt that indicates completion, or spinning in a tight loop, watching that specific bit in the interrupt status register to set or clear, before continuing on.
But at least you're actively reading a register. Also, you can read any output status registers as a sanity check that your SPI is actually passing data back and forth.
This radio puts an unwanted middle man between you and the registers.
You don't know if the middleman understood what you asked, where the hell he is, or how long he will take to get back to you. And worse, what are the unexpected or untested series of commands you may pass to him that will totally crash his operation.
As I see it, this is the biggest problem. There is really no way to troubleshoot issues with this kind of middleware from a user prospective. You can't bypass it, to get to any of the registers directly...which may help in troubleshooting.
In the end, the actual radio control firmware maybe rock solid. But this middleware piece that parses, stores, and fetches, may be full of undiscovered holes.
Anyway, good luck.
Yes jrkirk, I totally agree with you.
Without any support it seems hopeless and they don't seem to bother.
Thank you fo your contribution,
What processor are you using to talk to the module ?
I have an atmel xmega talking successfully to the si4463.
The process i went through is as follows:
I generated a project with WDS with my required rf settings.
I then ported the code across to the atmel studio 6.2 environment.
I could then use the API's to control the si4463 without issue and have commercialized several products.
Let me know if i can assist further.
Hi Paul, thank you for helping.
I'm using a PIC24FJ128GC006 CPU at 7.3728 MHz clock.
What are the API calls and what is the timing until the si4463 responds?
Hi Peter, have you downloaded WDS ?
If not then get it here: https://www.silabs.com/products/wireless/EZRadio/Pages/WirelessDevelopmentSuite.aspx
Select simulate radio and select your si4463 and then select "Radio configuration Application".
Then select your project and set the required rf parameters and then click "Generate source"
and select "generate custom project and launch silabs IDE"
This will generate all the code required which you can port to your pic processor.
You will need the silabs ide if you havent got it https://www.silabs.com/products/mcu/Pages/8-bit-microcontroller-software.aspx
API documentation can be found in application note AN625.
Hope that helps
my intention was to use WDS, but until I can't communicate with the module I taught it would be useless.
Anyway, based on your recommendation I installed it and let it generate some sample code. Now I see, the HopeRF demo was probably generated with the same tool and then ported to an 8 bit pic cpu, which I ported to my 16 bit cpu. Now there is either some flaw in the ported code, or I have to use a different revision version. The code generated for rev. B1 does not contain any patch code, while the code for a rev. C2 does. Maybe this is my problem, I'll have to port the patched version, then we'll see what next.
I have no idea what revision my chip can be, it's overprinted with this: RF26 BCL0V7 1421.
If I can get any further I'll post it here, but first I have to go on with other things, because I've spent a lot of time with this.
UI_RX_SPI_A = TX_RX_SPI_A(0x01); // PART_INFO Command
check_CTS_auf_FF(); // wenn er hier raus nSEL auf 0!!!
nSEL0 // dies ist die korrekte sequenz
uc_RFM26W_RX_buff = TX_RX_SPI_A(0x00); // CHIPREV[7:0] 0x11
uc_RFM26W_RX_buff = TX_RX_SPI_A(0x00); // PART[15:8] 0x44 dies ist si4463!!!!
uc_RFM26W_RX_buff = TX_RX_SPI_A(0x00); // PART[7:0] 0x63
uc_RFM26W_RX_buff = TX_RX_SPI_A(0x00); // PBUILD[7:0] 0x00
uc_RFM26W_RX_buff = TX_RX_SPI_A(0x00); // ID[15:8] 0x00
uc_RFM26W_RX_buff = TX_RX_SPI_A(0x00); // ID[7:0] 0x0f
uc_RFM26W_RX_buff = TX_RX_SPI_A(0x00); // CUSTOMER[7:0] 0x00
uc_RFM26W_RX_buff = TX_RX_SPI_A(0x00); // ROMID[7:0] 0x03
UI_DUMMY = TX_RX_SPI_A(0x00); // dummy
UI_DUMMY = TX_RX_SPI_A(0x00); // dummy
UI_DUMMY = TX_RX_SPI_A(0x00); // dummy
UI_DUMMY = TX_RX_SPI_A(0x00); // dummy
On this way I have got the information. I use the TMS320F28062 und have the same problem.
I would like to start a new topic about AN625. How to do this here?