You are not logged in.
Hi Forum,
I was carrying out some measurements yesterday using the 802.11 reference design. I programmed the boards once in the morning, one as the AP and another as the STA, and powered down both boards at the end of the day.
During the measurements I noticed the RF_B LEDs on my STA board constantly blinking rapidly, and observed that the equivalent LEDs on my AP board were completely off. Since RF_B was not used, I assumed these blinking LEDs were part of the reference design for the STA node.
However, this morning when I powered the boards up and tried to program them to continue my experiments I discovered my STA board was 'not programmable'. Its 7-segment displays showed '00' after bitstream download and it never associated with the AP. More ominously, the serial port output stated:
Serial console output wrote:
----- Mango 802.11 Reference Design -----
----- v1.2 ------------------------------
----- wlan_mac_dcf ----------------------
Compiled Jun 4 2015 11:28:58
Note: this UART is currently printing from CPU_LOW. To view prints from
and interact with CPU_HIGH, raise the right-most User I/O DIP switch bit.
This switch can be toggled any time while the design is running.
AD Readback: 0x0000002B
Radios didn't lock! RC stat reg: 0x00001000
w3_node_init: Error in radioController_initialize (-1)
Error in w3_node_init()! Exiting
I began to suspect that something could be wrong with one or both of the radio cards. To isolate the problem, I modified 1 line of the 802.11 reference design code in wlan_phy_util.c from:
status = radio_controller_init(RC_BASEADDR, RC_ALL_RF, 1, 1); to status = radio_controller_init(RC_BASEADDR, RC_RFA, 1, 1);
This starts up the board all right (both STA or AP-mode), and I'm able to carry out some measurements, exchanging data between the two boards in both directions.
It seems calling radio_controller_init() with RC_ALL_RF or RC_RFB results in the above console error message (RC stat reg: 0x00001018 and 0x00001000 respectively).
Does anyone know how to interpret this? Is this a programming-type problem somehow? I've never used the RF_B radio interface on any of our W3 boards which have the original terminators still on them. The boards are also in a locked room with minimal handling to eliminate ESD-issues, but could that be what's happened?
Anyone know of any further tests I can carry out to check the boards?
Thanks,
vick
Offline
Unfortunately that is evidence of a problem in the hardware. The radio_controller core monitors the MAX2829 PLL status and halts the boot process if the PLL doesn't lock. I'll follow up by email to arrange an RMA.
Offline
Thanks for the quick response, and excellent after-sales customer-support Mango Communications!
I've received your email and will discuss further off-forum,
vick
Offline
<Admin Removed Duplicate Post - See http://warpproject.org/forums/viewtopic … 436#p13436>
Offline
Hi, we got a similar issue, but statreg 0x00003070
what does that mean if RFA: D1 is constantly red, but the other three are blinking rapidly?
Offline
The radio_controller blinks the Tx/Rx LEDs to indicate the MAX2829 PLL failed to lock, the result of either a hardware problem or a mis-configuration of the radio_controller. I'm not sure why only one LED would blink. Is your design holding the interface in Rx mode? What happens with one of the unmodified reference design bitstreams? And can you clarify what you mean by "statreg 0x00003070"? Is this the value printed by radio_controller_init()?
Offline
That is/was the error message:
Radios didn't lock! RC stat reg: 0x00003070
w3_node_init: Error in radioController_initialize (-1)
Error in w3_node_init()! Exiting
I could track it down a little more. Our typical scenarios is that each board is connected to the PC using a "permanent" JTAG cable connection. We rarely use SD cards. The shipped and self-compiled bitstreams work fine using impact to load them. The problem started occurring when I use SD cards for programming - but strangely enough not all the time. I can program the boards 2-3 times, then three LEDs start blinking. Even loading a shipped reference .bin file does not resolve this error anymore (powercycling is also not helping either). Only if I use impact the problem disappears. I'll keep my eyes open to check which conditions trigger this. I'll check for wrongly keeping the interface in RX mode in particular. Thanks so far Patrick.
Offline