MC1321x RF problem when moving from 62.5 KHz to 8 MHz as clockout

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MC1321x RF problem when moving from 62.5 KHz to 8 MHz as clockout

1,747 Views
MarcB
Contributor I
Hi,

I'm trying to increase the clock output of the modem in the MC1321x so that I can use it as clock input for another external MCU. The original setting from the Beekit myWirelessApplication sample code is:

- #define CLOCK_OUT_SETTING   0x7E85 (nv_data.h), which outputs 62.5 KHz out of the modem
- NV_ICGC1 = 0x18 (nv_data.c), which sets the oscillator as low frequency range (FLL loop prescale factor P is 64)
- NV_ICGC2 = 0x20 (nv_data.c), which sets the multiplication factor to 8

So the MCU will run at 62.5 KHz * 64 * 8 = 32 MHz, which is what we want


Now I would like to output 8 MHz from the modem instead. I've changed the above settings to:

- #define CLOCK_OUT_SETTING   0x7E81 (nv_data.h), which outputs 8 MHz out of the modem
- NV_ICGC1 = 0x58 (nv_data.c), which sets the oscillator as high frequency range (FLL loop prescale factor P is 1)
- NV_ICGC2 = 0x00 (nv_data.c), which sets the multiplication factor to 4

So the MCU will run at 8 MHz * 1 * 4 = 32 MHz

The FLL locks correctly and the hiwave debugger confirms a bus frequency of 16 028 535 Hz

But RF communication is not working at all. I am simply sending broadcast messages to a receptor and none of the packets are being picked up. If I use the original settings (62.5 KHz output), everything is fine, if I used the new settings, nothing gets through.

Did I forget some settings here? Any ideas?

Cheers!
Marc



Message Edited by MarcB on 2008-05-12 04:44 PM
Labels (1)
0 Kudos
5 Replies

474 Views
bigmac
Specialist III
Hello Marc,
 
This sounds like it could be a receiver interference issue, perhaps determined, to some extent, by PCB layout and grounding.  Are you using your own board design?
 
Regards,
Mac
 


Message Edited by bigmac on 2008-06-11 01:58 PM
0 Kudos

474 Views
MarcB
Contributor I
Yes, this is our own board, but I don't think it's receiver interference. The device whose clock settings I am modifying is the transmitter, while the receiver is using the default config.

- If if use the transmitter in the default config (clockout of modem at 62.5 KHz), the receiver gets messages normally.
- If if use the transmitter with a modem clockout at 8 MHz, the receiver gets nothing.

But in generally "should" it work? Are the settings I am changing the correct ones? Am I missing something?

Cheers!
Marc

0 Kudos

474 Views
MarcB
Contributor I
Here's some more info:

- Two board layouts A and B.
    - A has the MC9S08GT60 and MC13202
    - B has the MC13213
- Two applications used to calculate a basic packet error rate
    - Transmit: broadcast packets with random data, a sequence number and a checksum. No ack, no retransmit
    - Receive: count received packets, out-of-order packets and corrupted packets.

Running both boards at the default clock output (62.5 KHz) with any combination of the transmit or receive application works fine.

As soon as I change the modem clockout to 8 MHz (with settings shown in first post) on board B, both applications fail (no packets are transmitted or received).

I have not tried to change the modem clockout on board B because it's an old Codewarrior project and causing me trouble on my machine.

Could it be that there is a larger clock error when outputing 8MHz?

Any help on this issue is greatly appreciated!
Marc
0 Kudos

474 Views
MarcB
Contributor I
Other important details:

I've tried different combinations of modem clockout and MCU PLL settings.

As long as using an external clock in the low range (62.5KHz or 32.786KHz), everything works fine
As soon as I try a clock in the high range (2 MHz, 4 MHz pr 8 MHz), I loose communication.


I've tried to track program execution when communication is not working. Here are a few points:
- The MCPS_handler is called to confirm transmission, but no received gets it
- The FLL_Lost_Lock_ISR gets called after a few seconds of operation and is called frequently

So it looks like the MCU has a hard time locking onto the modem clockout when its is in the high range.
0 Kudos

474 Views
MarcB
Contributor I
I still haven't solved this issue...
Do someone have any idea on the issue described in this post?

Thanks!
Marc
0 Kudos