• State Not Answered
  • Replies 8 replies
  • Subscribers 70 subscribers
  • Views 362 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 333087
Options

nRF7002 STA+AP with Different Channels

esmart-engineering

I have a linux driver that uses nRF7002 am able to have both STA+AP. The issue I'm running into is that when I have STA up, AP MUST be the same channel, and vice versa. I have 2 questions.

1. Can the nrf7002 be setup to use different frequency channels

2. If it can, what am I missing to make this work. I've attached a debug log that starts with "Start ap" and ends with it failing and reverting back to STA mode.

Fullscreen AP_DifferentChannel.txt Download 
[13280.179247] nrf_wifi_cfg80211_start_ap: Entry
[13280.179509] hal_rpu_cmd_process_queue: writing command
[13280.180015] umac_cmd_cfg: Command 5 sent to RPU stat=0
[13280.180195] hal_rpu_cmd_process_queue: writing command
[13280.181434] hal_rpu_cmd_process_queue: writing command
[13280.182551] umac_event_ctrl_process: Event 292 received from UMAC
[13280.182578] nrf_wifi_cmd_callbk_fn: cmd=5 status=0
[13280.182596] umac_event_ctrl_process: Event 292 processed
[13280.182754] hal_rpu_cmd_process_queue: writing command
[13280.183519] hal_rpu_cmd_process_queue: writing command
[13280.184273] hal_rpu_cmd_process_queue: writing command
[13280.185014] hal_rpu_cmd_process_queue: writing command
[13280.185747] hal_rpu_cmd_process_queue: writing command
[13280.186811] hal_rpu_cmd_process_queue: writing command
[13280.187773] umac_cmd_cfg: Command 13 sent to RPU stat=0
[13280.189350] umac_event_ctrl_process: Event 292 received from UMAC
[13280.189384] nrf_wifi_cmd_callbk_fn: cmd=13 status=-16
[13280.189401] umac_event_ctrl_process: Event 292 processed
[13280.295084] nrf_wifi_cfg80211_del_sta: deleting null reason=2 subtype=12
[13280.295333] hal_rpu_cmd_process_queue: writing command
[13280.295835] umac_cmd_cfg: Command 20 sent to RPU stat=0
[13280.296138] nrf_wifi_cfg80211_mgmt_tx: Sending frame to RPU: intf=1 cookie=5 (0x5) wait_time=0 no_ack=0 flags=0 params=0
[13280.296550] hal_rpu_cmd_process_queue: writing command
[13280.297815] hal_rpu_cmd_process_queue: writing command
[13280.297920] umac_event_ctrl_process: Event 292 received from UMAC
[13280.297959] nrf_wifi_cmd_callbk_fn: cmd=20 status=0
[13280.297977] umac_event_ctrl_process: Event 292 processed
[13280.298346] umac_cmd_cfg: Command 30 sent to RPU stat=0
[13280.299530] umac_event_ctrl_process: Event 273 received from UMAC
[13280.299570] umac_event_ctrl_process: Event 273 processed
[13280.402682] nrf_wifi_cfg80211_mgmt_tx: cookie 5 response not received (100ms)
[13280.403188] nrf_wifi_cfg80211_del_key: Entry
[13280.403411] hal_rpu_cmd_process_queue: writing command
[13280.404164] hal_rpu_cmd_process_queue: writing command
[13280.404678] umac_cmd_cfg: Command 7 sent to RPU stat=0
[13280.404977] nrf_wifi_cfg80211_del_key: Entry
[13280.405147] hal_rpu_cmd_process_queue: writing command
[13280.406442] hal_rpu_cmd_process_queue: writing command
[13280.407070] umac_event_ctrl_process: Event 292 received from UMAC
[13280.407129] nrf_wifi_cmd_callbk_fn: cmd=7 status=-2
[13280.407162] umac_event_ctrl_process: Event 292 processed
[13280.407366] umac_cmd_cfg: Command 7 sent to RPU stat=0
[13280.407815] nrf_wifi_cfg80211_del_key: Entry
[13280.408242] hal_rpu_cmd_process_queue: writing command
[13280.409519] umac_event_ctrl_process: Event 292 received from UMAC
[13280.409566] nrf_wifi_cmd_callbk_fn: cmd=7 status=-2
[13280.409580] hal_rpu_cmd_process_queue: writing command
[13280.409583] umac_event_ctrl_process: Event 292 processed
[13280.410096] umac_cmd_cfg: Command 7 sent to RPU stat=0
[13280.410519] nrf_wifi_cfg80211_del_key: Entry
[13280.410976] hal_rpu_cmd_process_queue: writing command
[13280.412233] umac_event_ctrl_process: Event 292 received from UMAC
[13280.412285] nrf_wifi_cmd_callbk_fn: cmd=7 status=-2
[13280.412303] umac_event_ctrl_process: Event 292 processed
[13280.412344] hal_rpu_cmd_process_queue: writing command
[13280.412854] umac_cmd_cfg: Command 7 sent to RPU stat=0
[13280.413620] nrf_wifi_cfg80211_mgmt_tx: Sending frame to RPU: intf=1 cookie=6 (0x6) wait_time=0 no_ack=0 flags=0 params=0
[13280.413918] hal_rpu_cmd_process_queue: writing command
[13280.414841] umac_event_ctrl_process: Event 292 received from UMAC
[13280.414878] nrf_wifi_cmd_callbk_fn: cmd=7 status=-2
[13280.414896] umac_event_ctrl_process: Event 292 processed
[13280.415810] hal_rpu_cmd_process_queue: writing command
[13280.416282] umac_cmd_cfg: Command 30 sent to RPU stat=0
[13280.417490] umac_event_ctrl_process: Event 273 received from UMAC
[13280.417541] umac_event_ctrl_process: Event 273 processed
[13280.522652] nrf_wifi_cfg80211_mgmt_tx: cookie 6 response not received (100ms)
[13280.523751] hal_rpu_cmd_process_queue: writing command
[13280.524429] umac_cmd_cfg: Command 37 sent to RPU stat=0
[13280.524651] hal_rpu_cmd_process_queue: writing command
[13280.525793] umac_cmd_cfg: Command 29 sent to RPU stat=0
[13280.525817] nrf_wifi_cfg80211_chg_vif: Entry
[13280.525833] nrf_wifi_cfg80211_chg_vif: Changing intf 1 wdev=2 to 2, state=0
[13280.525857] nrf_wifi_fmac_chg_vif: sending command
[13280.526165] hal_rpu_cmd_process_queue: writing command
[13280.526272] umac_event_ctrl_process: Event 292 received from UMAC
[13280.526310] nrf_wifi_cmd_callbk_fn: cmd=37 status=0
[13280.526328] umac_event_ctrl_process: Event 292 processed
[13280.526738] umac_cmd_cfg: Command 16 sent to RPU stat=0
[13280.526763] nrf_wifi_cfg80211_chg_vif: Waiting for response from RPU (change VIF) intf=

Parents
  • 0

    Hi

    This log doesn't give a lot of information in terms of error codes or where it actually is failing from what I can see, as it only reports what it is doing, and not the callbacks from any functions failing. Have you been able to figure out what function/process that is actually failing on your end, and what channels are you trying to use exactly, one 5GHz and one 2.4GHz? I can't think of why it shouldn't be able to use different channels for STA and AP as long as you switch between the two when needed.

    My first guess would be that the STA is taking up the radio on its allocated channel so you're not able to disable the radio to switch channel and allow the AP to run, but we would need some error codes from the logger to be able to tell anything here.

    Best regards,

    Simon

  • 0 in reply to Simonr

    Sorry, I had to add a callback for commands to fix a diferent issue, but there's usually a "umac_event_ctrl_process: %d cmd -> status %d" log line from event.c in nrfxlib, which is now replaced with "nrf_wifi_cmd_callbk_fn: cmd=%d status=%d" callback log line. The error is -16 when starting ap while a second interface (STA) is already up and on a different channel. Once the start_ap fails, everything past that begins to fail for ap functionality. If I turn off STA, I can run the same start ap command and it will work, so its just the STA interface causing problems.

    So if I'm understanding right, I need to disable any current interfaces before starting AP, and then turn them on again after. If I do it that way then AP should be able to control the radio, correct?

    I wasn't sure how radio sharing worked on the chip, but it sounds like its done manually through NRF_WIFI_UMAC_CMD_SET_CHANNEL commands, correct?

    I'll try this method unless its wrong, but I'm working on different issue so it won't be testing it for another day.

Reply
  • 0 in reply to Simonr

    Sorry, I had to add a callback for commands to fix a diferent issue, but there's usually a "umac_event_ctrl_process: %d cmd -> status %d" log line from event.c in nrfxlib, which is now replaced with "nrf_wifi_cmd_callbk_fn: cmd=%d status=%d" callback log line. The error is -16 when starting ap while a second interface (STA) is already up and on a different channel. Once the start_ap fails, everything past that begins to fail for ap functionality. If I turn off STA, I can run the same start ap command and it will work, so its just the STA interface causing problems.

    So if I'm understanding right, I need to disable any current interfaces before starting AP, and then turn them on again after. If I do it that way then AP should be able to control the radio, correct?

    I wasn't sure how radio sharing worked on the chip, but it sounds like its done manually through NRF_WIFI_UMAC_CMD_SET_CHANNEL commands, correct?

    I'll try this method unless its wrong, but I'm working on different issue so it won't be testing it for another day.

Children
No Data
Related