Hi. Have a few Questions:
When the MirfV2 is first powered up from Vcc=0, prior to any registers being set, what should the PWR_UP register read?
Does PWR_UP need to be 0 to set registers?
Is there a certain order in which registers must be set?
When first powered up, I can set or read single byte registers. I first was trying to set the 5 byte TX Address in my set up section of my code. Using my logic probe, I could see the data being clocked into the Mirf.
When I tried reading the TX Address, every byte came back 00000000’s
I then decided to read the tx address after Vdd startup. All 5 bytes came back as 00000000’s. Shouldnt I be reading the default 0xE7E7E7E7E7?
I am bringing CSN low first before I issue the read command and have used different variations of dummy data to clock the address bytes in. (and out when trying to set them) just to see if there is any effect. (I did notice that I could not use 11111111 to read single byte registers). Then I bring CSN high again. CE is kept low. I have verified this with my logic probe.
Do you have any suggestions why reading/writing multibyte registers does not work but reading/writing single bytes registers seems to work fine?
Any other caveats? The Nordic FAQs said not to use 0, 55, AA, FF in address bytes.
Thnx HG
- When the MirfV2 is first powered up from Vcc=0, prior to any registers being set, what should the PWR_UP register read?
The PWR_UP bit resets to 0. This is shown in the manual on p. 53.
- Does PWR_UP need to be 0 to set registers?
No.
- Is there a certain order in which registers must be set?
No. You can’t send any packets until you have turned on PWR_UP, and you can’t receive packets until you set PWR_UP and set one of the pipe payload widths to a non-zero value.
- Shouldnt I be reading the default 0xE7E7E7E7E7?
You should be, as long as you’re sending your data properly. Also check the voltage going into the 24L01 (coming out of the regulator on the MiRF-v2) to make sure that you are getting good power integrity into the device.
You can always check out the code that’s freely available on my website if you need some pointers.
Thanx Brennon for your reply. I really appreciate it!!
I have your tutorials and code “bookletized” (Bluesquirrel Clickbook) and carry them with my package of dev stuff…and have referrred to them allot along with other resources that I have gathered including the spec sheet.
I will check that volatge drop across the traces between the onboard regulator and the Nirf on the Mirf board.
Thnx for the answers!!
HG
I’ve got some simple test programs that might help:
http://www.leonheller.com/MiRF%20V2/
Leon
well, when I doublechecked things I decided to just concentrate on one register…I was wrong in that I was able to write to 1 byte regs. I modified my code so that the first thing I do after startup is to read the RF_CH reg, and then write Channel40 to it.
Here is the Probe of that:
http://www.flickr.com/photos/15859927@N … 8/sizes/o/
Then, upon a button press I am reading the register to see if it was set:
http://www.flickr.com/photos/15859927@N … 1/sizes/o/
I have yet to measure the voltage across the voltage regulator…Since I have a snap header soldered to the Mirfv2, the components are on the underside of the PCB board when inserted into my solderless breadboard. I guess I will have to build a connector cable so I can get to it (I hate introducing new components in the system when I am trying to debug it…more points of failure). I will do that today at lunch.
This project I am working on before work and during lunch so the progress can be slow (and switching gears in my head from html/java/javascript/AJAX/SOAP to Microcontroller code can be, well…you know).
Do you see anything that stands out from the Logic Probe Pictures? I find it odd that the MIrfV2 seems to goto PWR_UP mode when first started (Vcc=5V).
Solderless breadboards are a waste of time. It’s best to use a PCB.
Leon
You might want to take a look at that first trace. You’re reading from register 5 (RF_CH), but you’re actually writing to register 6 (RF_SETUP). In the second trace, you’re reading register 6 (RF_SETUP). On what grounds do you believe that the PWR_UP bit is being set at startup? I hope you’re using either #defines that you or I wrote for the register numbers when you do register reads and writes instead of just magic hex numbers. If you don’t, you’ll never get your code to a readable (and maintainable) state.
In the first trace, I inadvertently labled the first byte of the second set wrong. The label does not match the pulses The Label reads:
00100110
and the pulse shows:
00100101
Sorry about the confusion, and thanx for taking a look. I was in a hurry when I put the graphics together…and being in a hurry breeds mistakes…
With the correction of my mistake, I’m back to where I was at…
Do you see anything that stands out in the traces? I believe I am doing
CE and CSN correctly?
-
Yes I am using defines. and I have double and triple checked them…but I will check them again if I need to and I probably will check them again.
-
The PWR_UP bit:
The Spec Sheet says that when any command is issued, the Status register is what is synchronously clocked back in. When I issued the
Read Reg on the RF_CH then 00001110 was clocked back in…
0-Reserved
0-MASK_RX_DR
0-MASK_TX_DS
0-Mask_MAX_RT
1-EN_CRC
1-CRC0
1-PWR_UP <-------here
0-PRIM_RX
Am I wrong then, in either looking at the byte clocked back on MISO from the Cmd being clocked in, or I’m reading it wrong LSBit vs MSBit? Should I read it 01110000?
Or does the PWR_UP bit act “Like a pushbutton” instead of a “Like a Toggle”?..and I shouldnt pay attention to it’s read state?
- Also, when I initially read the RF_CH the value I noticed that the returned address was 3 but the spec sheet says it should be 2? Or am I confusing “default” value with Reset Value? If so, then what is the definition of “Reset Value” and how does it relate to the registers?
Today at lunch I am going to check that voltage from the on board regulator on the Mirfv2. I had to build a short cable to get the MirfV2 off the breadboard so I can turn the MirfV2 over and get to those traces. Yes Leon, I too have come to know that breadboards can cause problems, thankyou. They sure can get messy and debugging wiring and contacts on a breadboard can cost time thats for sure. I have taken my wiring and code and made it as simple as possible, organizing my wires with different colors to make any wiring debugging easier.
I have my logic probe wires plugged in the contact banks where the MirfV2
header contacts are plugged in…getting the probe contacts as close to the MirfV2 as possible.
Well, I would really appreciate any answers to my questions that you could give!!
Thnx in Advance!!
HG
The second trace I also mislabled the Cmd byte.
The Label reads:
00000110
and the pulse shows:
00000101
hgoodric:
With the correction of my mistake, I’m back to where I was at…
Do you see anything that stands out in the traces? I believe I am doing
CE and CSN correctly?
Other than what I mentioned, nothing really stood out to me in your traces as incorrect.
hgoodric:
3. The PWR_UP bit:
The Spec Sheet says that when any command is issued, the Status register is what is synchronously clocked back in. When I issued the
Read Reg on the RF_CH then 00001110 was clocked back in…
0-Reserved
0-MASK_RX_DR
0-MASK_TX_DS
0-Mask_MAX_RT
1-EN_CRC
1-CRC0
1-PWR_UP <-------here
0-PRIM_RX
Am I wrong then, in either looking at the byte clocked back on MISO from the Cmd being clocked in, or I’m reading it wrong LSBit vs MSBit? Should I read it 01110000?
You are confusing the STATUS register (0x07) with the CONFIG register (0x00). The normal reset value of the STATUS register is 0x0E, which is exactly what you are getting out.
hgoodric:
Also, when I initially read the RF_CH the value I noticed that the returned address was 3 but the spec sheet says it should be 2? Or am I confusing “default” value with Reset Value? If so, then what is the definition of “Reset Value” and how does it relate to the registers?
Could you provide a logic analyzer trace that actually shows this immediately after power up? Default value and reset value here can be used interchangeably, so you should be reading 0x02 at power up.
hgoodric:
Yes Leon, I too have come to know that breadboards can cause problems, thankyou. They sure can get messy and debugging wiring and contacts on a breadboard can cost time thats for sure. I have taken my wiring and code and made it as simple as possible, organizing my wires with different colors to make any wiring debugging easier.
You can get pefboards from RadioShack for relatively cheap, and as long as you have a soldering iron and decent soldering skills, they are infinitely more reliable than solderless breadboards. IIRC, the pad-per-hole large boards are around $5 each.
BRAIN JOG!! Status Reg !== CONFIG reg…wow, sometimes things get stuck in my head and I keep going down that same path…I didnt realize i was equating them!!
I will goto RatShack after work and pick up some Perf boards.
I have some homework to do (measure voltage, pickup some perfs, do soldering, get that trace for you) and I am out of town this weekend, so I will probably post next week, after I take care of these things and see where I am at…
Thnx again!!!
Well, I got it working. I got to thinking about timing, and I looked in the SPI settings. I had CKE=0 instead of CKE=1 (from when I had two pics talking to each other over SPI) so I changed that and all my register settings worked. The TX and the RX connected and data came forth…but…
The data that was coming in had “garbage data” in it in random intervals…and then the Reciever (pic and MirfV2) would stop working and I would have to repower to reset.
I figured that maybe it wasnt the MirfV2 that had bad packets (how could it? I am using enhanced Shockburst w/5 byte data width. If the receiver is receiving data, it should be good data because of addresing, CRC and retries of enhanced shockburst)
So i added some code at the start of the main loop to check if there was either collision or overflow on the SPI bus. The code would reset the SPI bus and flush the RX buffer on the MirfV2…and viola!!! Transmitting and receiving perfect data!!! BTW, im not bitbanging SPI, I’m using the built in SPI on the pic16f877. I might go back and figure out why the SPI is experiencing collisions or overflow. Im sure its a timing issue.
Thnx for all your help!!
Thnx especially to Brennen!!
This is PICBASIC Pro Code. Brennen, would you like to include the code on your DIY website? I would freely pass it on.
HG
I’ll post it for sure man. Just send it my way.