I have two systems with this chip. One is on a factory reference board,
the other is my own board. Both are driven by AVR Tiny-26 chips, running
the same code set, at the same speed.
The factory system works fine, mine does not.
The obvious thing to check of course was whether the interface signals
are reaching the right pins on the nRF chip, and they are.
On my system, it appears that the Nordic chip never inits. When I send a
shockburst packet, it does send, but it always sends on 2400 MHz, even
though the init code tries to set it to 2402.
I suspect this may be an issue over something on the reference board
that I'm not aware of, or a difference in the chips. The date codes show
about 18 months difference.
I've put a logic analyzer on both systems, everything seems right,
nothing's anywhere near any timing issues (THAT ARE IN THE DATA SHEET),
and by all appearances it should be working.
I'm hoping someone else has hit this and can help me through it.
Dave,
I'm sure you've checked by now but
Is there anything in the chip fuse settings that could be different
eg - clock / crystal not working or at a totally wrong frequency.
port pins disabled ???
>
> Can anyone help me with an interesting problem?
>
> I have two systems with this chip. One is on a factory reference board,
> the other is my own board. Both are driven by AVR Tiny-26 chips, running
> the same code set, at the same speed.
>
> The factory system works fine, mine does not.
>
> The obvious thing to check of course was whether the interface signals
> are reaching the right pins on the nRF chip, and they are.
>
> On my system, it appears that the Nordic chip never inits. When I send a
> shockburst packet, it does send, but it always sends on 2400 MHz, even
> though the init code tries to set it to 2402.
>
> I suspect this may be an issue over something on the reference board
> that I'm not aware of, or a difference in the chips. The date codes show
> about 18 months difference.
>
> I've put a logic analyzer on both systems, everything seems right,
> nothing's anywhere near any timing issues (THAT ARE IN THE DATA SHEET),
> and by all appearances it should be working.
>
> I'm hoping someone else has hit this and can help me through it.
>
>
>
>
>
> Of Richard Prosser
> Sent: Sunday, December 18, 2005 2:15 AM
> To: Microcontroller discussion list - Public.
> Subject: Re: Nordic nRF2401
>
> Dave,
> I'm sure you've checked by now but
> Is there anything in the chip fuse settings that could be different
> eg - clock / crystal not working or at a totally wrong frequency.
> port pins disabled ???
Yes, but thanks for asking..
Logic analyzer traces at the Nordic chip are identical, as closely as I
can tell. All signals getting to the right places, and well within any
timing constraints that I'm aware of.
Divide and conquer:
Would it be possible to rebuild the factory system so the AVR is in a socket, and you can swap in your AVR? Or other means to swap in your controller and program onthe the known good RF chip and cirquit?
>Can anyone help me with an interesting problem?
>
>I have two systems with this chip. One is on a factory reference board,
>the other is my own board. Both are driven by AVR Tiny-26 chips, running
>the same code set, at the same speed.
>
>The factory system works fine, mine does not.
>
>The obvious thing to check of course was whether the interface signals
>are reaching the right pins on the nRF chip, and they are.
>
>On my system, it appears that the Nordic chip never inits. When I send a
>shockburst packet, it does send, but it always sends on 2400 MHz, even
>though the init code tries to set it to 2402.
>
>I suspect this may be an issue over something on the reference board
>that I'm not aware of, or a difference in the chips. The date codes show
>about 18 months difference.
>
>I've put a logic analyzer on both systems, everything seems right,
>nothing's anywhere near any timing issues (THAT ARE IN THE DATA SHEET),
>and by all appearances it should be working.
>
>I'm hoping someone else has hit this and can help me through it.
>
>
>
>
>
> Divide and conquer:
> Would it be possible to rebuild the factory system so the AVR is in a
> socket, and you can swap in your AVR? Or other means to swap in your
> controller and program onthe the known good RF chip and cirquit?
That's what I've done. The factory system is just the Nordic chip and
ancillary components connected to a 20 pin header. On that system, the
code initializes the processor just fine, every time.
On the prototypes, I get what the logic analyzer says is the same
sequence and timing at the Nordic chip pins, but the Nordic chip fails
to init.
I am going through the factory board today to see if it actually matches
the schematic given. Maybe there's something a little different that is
causing it to work.
This gets a bit more interesting, because due to layout constraints, I
have the code set up to build for five different pinouts.
Ignoring the factory board, I'm set up to talk to the 2.4Ghz chip in two
versions, and the 915 MHz chip in two other versions. Each has slightly
different pinouts into the AVR, and the two Nordic chips are so
different you'd never guess they were made by the same people. So, I
abstracted all their functions to a layer of calls that the application
layer uses, making both chips appear identical to the application.
The code has a few equates that you set true or false, and it builds the
right version. That all seems fine, as I said the LA indicates that
everything is coming out the right pins and ending up in the right
places.
If it's a code problem, then it's something that I'm not doing because
the requirement isn't documented.
I'd be tempted to suspect a bad solder joint (ie, the signal may not
be getting into the chip, only near it) and ground and power issues.
Beyond that, have you matched the capacitors on the prototype closely
to the working version? (value, voltage, ESR, composition)
I understand that these chips are rather sensitive to layout issues as
well. Are you using the layout in the data sheet, or from a working
design?
> > Divide and conquer:
> > Would it be possible to rebuild the factory system so the AVR is in a
> > socket, and you can swap in your AVR? Or other means to swap in your
> > controller and program onthe the known good RF chip and cirquit?
>
> That's what I've done. The factory system is just the Nordic chip and
> ancillary components connected to a 20 pin header. On that system, the
> code initializes the processor just fine, every time.
>
> On the prototypes, I get what the logic analyzer says is the same
> sequence and timing at the Nordic chip pins, but the Nordic chip fails
> to init.
>
> I am going through the factory board today to see if it actually matches
> the schematic given. Maybe there's something a little different that is
> causing it to work.
>
> This gets a bit more interesting, because due to layout constraints, I
> have the code set up to build for five different pinouts.
>
> Ignoring the factory board, I'm set up to talk to the 2.4Ghz chip in two
> versions, and the 915 MHz chip in two other versions. Each has slightly
> different pinouts into the AVR, and the two Nordic chips are so
> different you'd never guess they were made by the same people. So, I
> abstracted all their functions to a layer of calls that the application
> layer uses, making both chips appear identical to the application.
>
> The code has a few equates that you set true or false, and it builds the
> right version. That all seems fine, as I said the LA indicates that
> everything is coming out the right pins and ending up in the right
> places.
> If it's a code problem, then it's something that I'm not doing because
> the requirement isn't documented.
>
>
>
>
> I'd be tempted to suspect a bad solder joint (ie, the signal may not
> be getting into the chip, only near it) and ground and power issues.
Yes. These MLF packages are a bit frustrating that way, there's nowhere
really to probe other than on the solder joint, which isn't the same as
the old trick of probing on the DIP chip's leadframe rather than on the
PCB or socket. I've reflowed the joints though, and examined under a
microscope, and they appear to be wetting the chip pads fine.
> Beyond that, have you matched the capacitors on the prototype closely
> to the working version? (value, voltage, ESR, composition)
Yes.
> I understand that these chips are rather sensitive to layout issues as
> well. Are you using the layout in the data sheet, or from a working
> design?
We are just talking about the logic signals at this point. Our RF layout
is different, but we believe we know what we are doing on that side :)
Very puzzling..
My biggest gnawing suspicion is that there's 18 months between the chips
that work, and the ones that don't. I haven't seen any documentation on
errata, but that doesn't mean there isn't any.
David Van Horn 20:00 2005-12-18:
>My biggest gnawing suspicion is that there's 18 months between the chips
>that work, and the ones that don't.
Can you swap the chips, and see if the problem swaps with them?
OR ask for sample of latest chip rev.
How is the manufacturers support working? Are they nice people?
> I haven't seen any documentation on
>errata, but that doesn't mean there isn't any.
Had that problem with early rev of Linear tech LTC2400. They said they did nit change anything on the digital side, yet problem moved with the chips as i swapped. :/
--
Morgan Olsson, Kivik, Sweden
David Van Horn wrote
>I've put a logic analyzer on both systems, everything seems right,
>nothing's anywhere near any timing issues (THAT ARE IN THE DATA SHEET),
>and by all appearances it should be working.
This is long shot but on an nRF905 I found that the rest state of the
SPI clock was important. Although the data sheet doesn't say so
explicitly I found I couldn't initialise the device when the clock was
resting high when CSN went low - even though data was stable and clocked
on the correct edge. I wouldn't expect an LA to show any difference in
the data it collected.
> David Van Horn 20:00 2005-12-18:
> >My biggest gnawing suspicion is that there's 18 months between the
chips
> >that work, and the ones that don't.
>
> Can you swap the chips, and see if the problem swaps with them?
MLF package, pretty difficult.
> OR ask for sample of latest chip rev.
>
> How is the manufacturers support working? Are they nice people?
If I ever hear from them, I'll let you know.
Actually, they did respond after about a week, but only on an "is it
plugged in" level.
> David Van Horn wrote
> >I've put a logic analyzer on both systems, everything seems right,
> >nothing's anywhere near any timing issues (THAT ARE IN THE DATA
SHEET),
> >and by all appearances it should be working.
>
> This is long shot but on an nRF905 I found that the rest state of the
> SPI clock was important. Although the data sheet doesn't say so
> explicitly I found I couldn't initialise the device when the clock was
> resting high when CSN went low - even though data was stable and
clocked
> on the correct edge. I wouldn't expect an LA to show any difference in
> the data it collected.
Thanks! That definitely was the case in an earlier version of the code,
after all Data isn't SUPPOSED to matter till clock transits high, but I
did take that out, looking for anything that just "smelled funny" to me.
I've spoken to them this am finally, and found some interesting issues
with the crystal. I have some different parts coming in overnight that
may solve this problem.
We walked through all the code, and proved that it works on the factory
boards, so we are definitely fighting something marginal at the hardware
level.
microbrix.com> wrote:
