You are not logged in.
Hi,
I am using the w3_radio_controller v3.00.a.
1. Can I safely use radio_controller_setCenterFrequency(..) to set a new channel/band, or do I have to check for ongoing transmissions/receptions? I saw nowhere a check in software.
2. What would happen in case of the PHY receiving a packet and the software issuing a channel switch?
Thanks!
Christian
Offline
The radio_controller driver does not enforce any policy on re-tuning the transceiver during a Tx/Rx event. The driver doesn't know what waveforms might be passing through the transceiver- it just sends the SPI register write commands to re-tune. The application must enforce whatever exclusion is required. For example, this is implicit in the 802.11 Ref Design. Channel changes are requested by an IPC message from CPU High -> Low. CPU Low only checks the IPC mailbox in between frame_transmit() and frame_receive() contexts, effectively implementing a 'no switch during Tx/Rx' policy. The blocking poll of Tx/Rx state in the OFDM ref design is similar.
Offline
2. What would happen in case of the PHY receiving a packet and the software issuing a channel switch?
The radio would re-rune while the incoming waveform was still arriving. The resulting output (Rx baseband) waveform would show the original waveform (pre tune), some transients (during re-tune), then whatever the baseband equivalent of the new center frequency (post tune). If this happens mid payload the Rx PHY would finish with a bad checksum. If it happens early in a reception (during AGC or training), the waveform would probably never trigger a good header (OFDM ref design) or RX_START (802.11 ref design) event, so the PHY would reset and wait for a new reception.
Offline
Thank you.
I have a somewhat related followup: Assume software currently performs sanity checks of the pkt header while receiving a pkt, e.g. destinationAddr == myAddr. If software sees that this does not match, can it issue a reset/abort without locking up the PHY and do something else, e.g. other time critical stuff?
If so, which function do you recommend to unblock/reset the PHY?
Offline
I think if you call "mimo_ofdmRx_disable(); mimo_ofdmRx_enable();" it will reset the Rx PHY pipeline without causing any deadlocks.
Offline
Ok. Good. What would be the situation in case of the 802.11 reference design?
Offline
Resetting the Tx or Rx PHY mid-packet is trickier in the 802.11 design, as the PHY cores and MAC core operate in lock step. The MAC core assumes that every RX_START event will be followed by an RX_END event. Same for TX_STARTED/TX_END.
If you're ok with wiping other state the MAC core (NAV / backoff counter / postTx/Rx timers) you can reset the PHY and MAC cores with:
//Reset Tx/Rx PHY, MAC REG_SET_BITS(WLAN_RX_REG_CTRL, WLAN_RX_REG_CTRL_RESET); REG_SET_BITS(WLAN_TX_REG_CFG, WLAN_TX_REG_CFG_RESET); wlan_mac_reset(1); REG_CLEAR_BITS(WLAN_RX_REG_CTRL, WLAN_RX_REG_CTRL_RESET); REG_CLEAR_BITS(WLAN_TX_REG_CFG, WLAN_TX_REG_CFG_RESET); wlan_mac_reset(0);
I haven't actually tested this, but I think it will work.
Offline
We see (latest with RefDes 1.4.0, not yet fully confirmed with 1.3.0) PHY lock ups using the almost exactly the above mentioned reset (just removed the commands concerning the TX part) especially in case of heavy WiFi cross traffic. They manifest themselves:
- RXerror flag is set, RX unsupported is not set
- polling the RX PHY in wlan_mac_low_poll_frame_rx() locks the station in the second while loop:
-- I could read the status of the PHY
-- afterwards, the PHY does not become inactive anymore ( http://warpproject.org/trac/browser/Ref … =4982#L403 )
As you did changes to the PHY/MAC core lately, could there be any race condition that we miss? We removed the TX reset deliberately as a colliding TX is not possible due to the while loop waiting for the completion of the TX process.
Update: I also tested it with writing RESET to the TX registers, but it leads to the same situation
Last edited by Christian (2016-Feb-10 10:18:51)
Offline
You'll have to provide some more context. Where in the code did you add the explicit Rx PHY reset?
In general, why do you want to reset the Rx PHY/MAC state mid-reception? I think it would be better to leave the cores running normally, cleaning up any Rx state after your time critical code runs. As long as you eventually call "wlan_mac_dcf_hw_rx_finish(); wlan_mac_dcf_hw_unblock_rx_phy();" the Rx MAC/PHY will resume normal reception processing.
Offline
The initial Idea was based on the fact that we use a polling-based timer-system to run parts of the state-machine. Since timer-handling is very timing critical, early discarding of transmissions we know are not designated to us (e.g. packet-length not handled by our system, MCS not used by our system) could lead to less cases where timer expiries are handled later than expected.
We executed it inside the frame-receive callback, at the beginning of the function. We checked against the PLCP, and if its a packet that can't originate in our system we want to stop decoding it.
However, after some more investigation it seems that the lockup-problem is not directly related to the reset. After removing the reset-code, it still happens that the PHY stays active indefinetly. Just now its getting stuck inside of wlan_mac_dcf_hw_rx_finish() with mac state 0x28002 instead of the loop christian linked earlier. After removing the reset, every reception is finished at some point with rx_finish + unblock_rx_phy. Do you have any pointers what might cause this behaviour?
[Edit]
As an additional note, we disabled DSSS in our system using both of
wlan_phy_DSSS_rx_disable(); wlan_phy_rx_pktDet_autoCorr_dsss_cfg(0xFF, 0x3FF, 30, 40);
could that lead to any invalid state?
Last edited by Edlmann (2016-Feb-11 11:40:38)
Offline