Can't get WiFi and PSA API to work in the same application using nRF7002DK

Hi.

We're working on a project using nRF Connect SDK 2.5.0 and nRF7002DK that needs to use both WiFi and PSA in order to do some cryptographic operations, but there are memory issues when running the application, even changing drastically the values in CONFIG_MAIN_STACK_SIZE and/or CONFIG_HEAP_MEM_POOL_SIZE. To replicate the problem, I've tried to combine both WiFi Station and PSA SHA256 samples in a single application using the required configurations but I still face the same problem, getting errors on WiFi and hash operations. I've also tried to increase the stack size with a value up to 40960 without making a difference. The output looks like this: 

[00:00:00.406,829] <err> wifi_nrf: nrf_wifi_hal_dev_add: No space for TX buf info

[00:00:00.407,043] <err> wifi_nrf: nrf_wifi_fmac_dev_add: nrf_wifi_hal_dev_add failed

[00:00:00.407,073] <err> wifi_nrf: nrf_wifi_fmac_dev_add_zep: nrf_wifi_fmac_dev_add failed

[00:00:00.407,073] <err> wifi_nrf: nrf_wifi_if_init_zep: nrf_wifi_fmac_dev_add_zep failed

[00:00:00.419,525] <err> wifi_nrf: nrf_wifi_hal_dev_add: No space for TX buf info

[00:00:00.419,708] <err> wifi_nrf: nrf_wifi_fmac_dev_add: nrf_wifi_hal_dev_add failed

[00:00:00.419,738] <err> wifi_nrf: nrf_wifi_fmac_dev_add_zep: nrf_wifi_fmac_dev_add failed

[00:00:00.419,769] <err> wifi_nrf: nrf_wifi_if_start_zep: nrf_wifi_fmac_dev_add_zep failed

*** Booting nRF Connect SDK v2.5.0 ***
[00:00:00.419,921] <inf> net_config: Initializing network
[00:00:00.419,921] <inf> net_config: Waiting interface 1 (0x20001508) to be up...
[00:00:00.420,013] <inf> net_config: IPv4 address: 192.168.1.99
[00:00:00.420,074] <inf> net_config: Running dhcpv4 client...
[00:00:00.420,318] <inf> sta: Starting nrf7002dk_nrf5340_cpuapp with CPU frequency: 64 MHz
[00:00:01.397,491] <inf> sta: QSPI Encryption disabled
[00:00:01.397,583] <inf> sta: Static IP address (overridable): 192.168.1.99/255.255.255.0 -> 192.168.1.1
[00:00:01.397,583] <inf> sta: Starting SHA256 example...
[00:00:01.397,613] <inf> sta: ---- Plaintext to hash (len: 150): ----
[00:00:01.397,613] <inf> sta: Content:
                              45 78 61 6d 70 6c 65 20  73 74 72 69 6e 67 20 74 |Example  string t
                              6f 20 64 65 6d 6f 6e 73  74 72 61 74 65 20 62 61 |o demons trate ba
                              73 69 63 20 75 73 61 67  65 20 6f 66 20 53 48 41 |sic usag e of SHA
                              32 35 36 2e 54 68 61 74  20 75 73 65 73 20 73 69 |256.That  uses si
                              6e 67 6c 65 20 61 6e 64  20 6d 75 6c 74 69 2d 70 |ngle and  multi-p
                              61 72 74 20 50 53 41 20  63 72 79 70 74 6f 20 41 |art PSA  crypto A
                              50 49 27 73 20 74 6f 20  70 65 72 66 6f 72 6d 20 |PI's to  perform 
                              61 20 53 48 41 2d 32 35  36 20 68 61 73 68 69 6e |a SHA-25 6 hashin
                              67 20 6f 70 65 72 61 74  69 6f 6e 2e 00 00 00 00 |g operat ion.....
                              00 00 00 00 00 00                                |......           
[00:00:01.397,644] <inf> sta: ---- Plaintext to hash end  ----
[00:00:01.397,644] <inf> sta: Hashing using SHA256...
[00:00:01.397,644] <inf> sta: psa_hash_compute failed! (Error: -134)
[00:00:01.397,674] <inf> sta: Example exited with error!

Is it a problem with the device or the SDK or is there anything we can try on our side?

Thanks.

Best regards.

Parents
  • Hi,

    For potential memory problems, there are some guides in the documentation which you could look at - memory footprint optimization and memory requirements for Wi-Fi applications.

    Best regards,
    Dejan

  • Hi.

    Thanks for your reply. I've tried to follow the guides provided, specifically using the configurations listed under Usage profiles for the memory optimized STA mode. However I still face the same issue with the PSA API, being unable to do the hash operations, as well as other memory problems while running the project (global variables with wrong values). I also decreased the main stack size and used thread analyzer to check memory usage, which constantly shows that there is still enough unused memory. This is an example of the output:

    Thread analyze:
     0x20002fa0          : STACK: unused 1256 usage 2840 / 4096 (69 %); CPU: 0 %
          : Total CPU cycles used: 16
     0x20001680          : STACK: unused 564 usage 460 / 1024 (44 %); CPU: 0 %
          : Total CPU cycles used: 14
     0x20003078          : STACK: unused 6168 usage 2024 / 8192 (24 %); CPU: 5 %
          : Total CPU cycles used: 406
     0x200027c8          : STACK: unused 840 usage 184 / 1024 (17 %); CPU: 0 %
          : Total CPU cycles used: 1
     0x200028a0          : STACK: unused 3912 usage 184 / 4096 (4 %); CPU: 0 %
          : Total CPU cycles used: 0
     0x20002360          : STACK: unused 3800 usage 296 / 4096 (7 %); CPU: 0 %
          : Total CPU cycles used: 2
     0x20002a38          : STACK: unused 792 usage 232 / 1024 (22 %); CPU: 0 %
          : Total CPU cycles used: 0
     0x20002e40          : STACK: unused 792 usage 232 / 1024 (22 %); CPU: 0 %
          : Total CPU cycles used: 0
     0x200036e0          : STACK: unused 2280 usage 280 / 2560 (10 %); CPU: 0 %
          : Total CPU cycles used: 21
     0x20002108          : STACK: unused 792 usage 232 / 1024 (22 %); CPU: 0 %
          : Total CPU cycles used: 1
     0x20003130          : STACK: unused 1352 usage 696 / 2048 (33 %); CPU: 3 %
          : Total CPU cycles used: 267
     0x20003208          : STACK: unused 1048 usage 1000 / 2048 (48 %); CPU: 0 %
          : Total CPU cycles used: 41
     0x20001738          : STACK: unused 552 usage 216 / 768 (28 %); CPU: 0 %
          : Total CPU cycles used: 1
     0x20003508          : STACK: unused 224 usage 96 / 320 (30 %); CPU: 62 %
          : Total CPU cycles used: 4740
     0x200035c0          : STACK: unused 3244 usage 1876 / 5120 (36 %); CPU: 22 %
          : Total CPU cycles used: 1726
     ISR0                : STACK: unused 892 usage 1156 / 2048 (56 %)

    Is there any other possible approach to this issue?

    Thanks.

    Best regards.

  • Hi,

    I am sorry for a delayed reply. I was out of the office.

    There is a functionality implication of disabling 2 mentioned configuration options in the sense that this would potentially make all wifi features unusable. In other words, they would probably not work. WPA_SUPP uses non-PSA calls which might affect PSA SHA 256 sample. I have reported this issue to our developers and they will look into it. I will get back to you with new findings, probably during next week.

    Best regards,
    Dejan

  • Hi,

    I have tested potential solution to your problem. You should be able to get both samples to work if you make nrf7002dk_nrf5340_cpuapp_ns.conf file and include it into your build configuration. The content of the file is shown below. Please test it yourself to verify that it is working for you.

    CONFIG_WIFI_CREDENTIALS_BACKEND_PSA=y
    CONFIG_TFM_PROFILE_TYPE_MEDIUM=y
    CONFIG_PM_PARTITION_SIZE_TFM_SRAM=0x18000
    CONFIG_MBEDTLS_HEAP_SIZE=16384
    


    Best regards,
    Dejan

  • Hi.

    Thanks for your reply. I've tested the configurations and it works fine. Since those are TF-M configs and the target is the non-secure one, do they make the WiFi sample compatible with it then? The sample only lists the secure target as compatible and is the one I was using at first but it actually works adding those options, so I'd like to clarify that.

    Thanks again for the solution.

    Best regards.

  • Hi,

    I tested your combined project by building it with non-secure build target nrf7002dk_nrf5340_cpuapp_ns. As shown in building with *_ns, application is built as non-secure image and TF-M as secure image. In general, if sample is built for non-secure target, it automatically includes TF-M.

    Best regards,
    Dejan

  • Hi.

    Although it works fine with the non-secure target, the full project is being developed currently with the secure one due to memory problems in this SDK version, which is also the one considered in the main issue since the WiFi samples are shown to be compatible only with this one in the documentation. Is there another possible fix for the secure build target?

    Thanks.

    Best regards.

Reply
  • Hi.

    Although it works fine with the non-secure target, the full project is being developed currently with the secure one due to memory problems in this SDK version, which is also the one considered in the main issue since the WiFi samples are shown to be compatible only with this one in the documentation. Is there another possible fix for the secure build target?

    Thanks.

    Best regards.

Children
Related