Kinetis KW2x - Debugging Radio Transmit / Receive

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

Kinetis KW2x - Debugging Radio Transmit / Receive

Jump to solution
2,386 Views
davidguinn
Contributor II

Using the Wireless UART example provided with BeeKit and Kinetis SDK, I am able to see packets being transmitted on Channel 15 by a TWR-KW21D256, captured by the USB-KW24D512 in packet sniffer mode(The TWR is also successfully receiving packets sent by another Zigbee dongle).  We have a prototype board with the KW21D512 which the Wireless UART mostly works EXCEPT for the radio transmit and receive, the packet sniffer is not seeing it transmit and the prototype is also not receiving from the other Zigbee Dongle.  UART and GPIO pins (LEDs and GPIO inputs) are all working correctly on this prototype board.  So what would be the best way to debug this issue?  The one thing I am concerned about is the EXTAL_32M and XTAL_32M was connected to a 24MHz external clock instead of a 32MHz, would this have any impact on the radio?

The radio hardware design is exactly the same as the TWR's.

From the documentation, the radio internally uses the SPI1 bus, we are using Port E Pins 0 to 4 as GPIO inputs, would this have any impact on this too?

Using IAR Embedded Workbench 7.40

Tags (3)
0 Kudos
1 Solution
2,028 Views
davidguinn
Contributor II

We figured it out.  So in the end it was discovered the external 32MHz crystal/clock(connected to EXTAL_32M and XTAL_32M)MUST have capacitors, so by matching the 12pF the TWR has, our transmitting and receiving started functions in the correct frequency.  Without the capacitors, a Spectrum Analyzer showed it was transmitting at 2.4265 GHz which is too high.  We also discovered Chapter 32's OSC control register allows you to select internal capacitors to use but this does not solve the problem, external caps must be used.

Thank you for the advice and support.

View solution in original post

0 Kudos
9 Replies
2,028 Views
jc_pacheco
NXP Employee
NXP Employee

Hello David,

The modem 32 MHz source must always be present. The crystal has special requirements and the reference frequency must meet the 802.15.4 Standard.

See Chapter 4 - Clock Sources, in the MKW2xDxxxRM.pdf

Regards,

JC

0 Kudos
2,028 Views
davidguinn
Contributor II

Hi,

I forgot to reply to this earlier, I had added a comment on my support request though on the clock.  It was actually a mistake on the schematic, it listed 24MHz but the Bill Of Materials actually called for a 32MHz and so the prototype board does have the same 32 MHz component as the TWR board.  The current suspect is C18 on the TWR board is a DNP 10PF capacitor where the prototype has a normal 10PF capacitor connected to the F Antenna.  Our prototype board does not have a external SMA antenna.

Software/Firmware wise, if the firmware successfully transmits and receives on the TWR-KW21D256, it should also work on the KW21D512(assuming the hardware functions correctly), is that correct?

0 Kudos
2,028 Views
jc_pacheco
NXP Employee
NXP Employee

Hi David,

The capacitor in the TWR is not populated by default because it's using the SMA connector. In the TWR board, if you want to switch to use the Inverted-F antenna, you have to change the capacitor from C17 to C18.

Having said that, if your design already has the capacitor in place for the F antenna and you don't have the SMA Connector, your design should be working fine as long as all the RF circuitry is in place as the design files states.

pastedImage_0.png

I'd recommend you to use the Connectivity test for validation purposes.

On your Software question, yes... The project for the KW21D512 on the TWR should work as expected in your design, just take into consideration the peripherals.

-JC

0 Kudos
2,028 Views
davidguinn
Contributor II

Ah, I had looked through the TWR-KW2XHWRM.pdf and I didn't see any mention of needing to rotate the capacitor to enable the Inverted-F antenna (although I'm a software engineer, not hardware engineer).  So the DNP is Do Not Populate :smileyhappy:  Although interestingly if the external antenna is not connected to the SMA, it is still able to transmit and receive.

Could using PTC pins(PTC4, PTC5, PTC6, PTC7) as GPIO pins, impact the internal communication for the radio since it uses SPI?  Our prototype has 3 LEDs as GPIO outputs and PTC7 as a GPIO input.

0 Kudos
2,028 Views
jc_pacheco
NXP Employee
NXP Employee

Hello David,

That's right, if the antenna is not connected it still radiates but the range is limited, that's the external antenna for.

PTC4 to PTC7 are free for you to use as you want (GPIO, SPI, UART, etc), depending on the port configuration (See "Chapter 3.3 MKW2xDxxxV Pins").

See "Table 4-2. Internal Connections" to understand how the lines are connected internally, the Radio SPI pin assignments (SPI1) are taken care by the software and are not available in the pin out connections.

Did you already tried to use the Connectivity Test and verified simple TX and RX continuous transmissions?

-JC

0 Kudos
2,028 Views
davidguinn
Contributor II

Thanks for the information so far.  I had the capacitor rotated from C17 to C18 so now it is using the Inverted-F antenna on the TWR-KW21D256.

To test simple TX and RX continuous transmissions, I've modified the Wireless Uart example, so the TWR-KW21D256 is successfully receiving from another Zigbee dongle and it is also successfully transmitting which the Zigbee Dongle receives.  I also have a USB-KW24D512 as a packet sniffer to capture packets in the air.  So now using the Inverted-F antenna on the TWR, it is still successful in TX and RX.

But the same code on our prototype board, it neither receives nor transmits, the packet sniffer doesn't show anything transmitting from the prototype board and when I transmit from the Zigbee dongle, it doesn't receive anything either but the packet sniffer shows the Zigbee dongle's transmission.  Also this is all in very close range, everything is within 1-2ft of each other.

So with the software successfully working on the TWR board and for the most part on the prototype board (GPIO and UART),  it seems like this is a hardware issue?

0 Kudos
2,028 Views
jc_pacheco
NXP Employee
NXP Employee

At first sight it looks like a hardware issue. Same firmware should work in both cases; you'll need to debug your application to be completely sure about the status of the packet being sent/received.

0 Kudos
2,029 Views
davidguinn
Contributor II

We figured it out.  So in the end it was discovered the external 32MHz crystal/clock(connected to EXTAL_32M and XTAL_32M)MUST have capacitors, so by matching the 12pF the TWR has, our transmitting and receiving started functions in the correct frequency.  Without the capacitors, a Spectrum Analyzer showed it was transmitting at 2.4265 GHz which is too high.  We also discovered Chapter 32's OSC control register allows you to select internal capacitors to use but this does not solve the problem, external caps must be used.

Thank you for the advice and support.

0 Kudos
2,028 Views
jc_pacheco
NXP Employee
NXP Employee

That's right, the IEEE 802.15.4 standard requires that the frequency be accurate to less that +/-40 ppm.

Reference Oscillator Crystal Requirements Application Note

I'm glad you found the issue. Feel free to mark this post as "Answered" when you think it's the case.