[qn9090] LL reset with error 0x20000

[HesselM]

Hi all, 

We use a qn9090T as a BLE-central to connect to several peripherals simultaneously. 

SDK 2.6.5 is used, but we have ported the qn9090 to Zephyr (see below for more info).

When using 1-2 perhiperals, with low notify-rate, all is fine. But when a perhiperal is used in the mix with a high update-rate (several times per second), the controller eventually calls the "plf_reset_cb" callback with error 0x20000. 

We know a riverawaves-controller is used, but cannot find anywhere an explanation of error-codes. 

The original code in the 2.6.5 SDK triggers a full MCU-reset. This is something we want to prevent. Ignoring the error results in a hard-fault. We are also trying to check if we can re-init the controller, but the best option would be to actually know the cause of the error and fix it. 

Would someone be able to tell us what exactly this error means? Or where we can find an overview of error-codes for the "plf_reset_cb" ?

Thanks!

Hessel.

Ps. In case you are interested to the port (which is work in progress), please checkout:

- hal_nxp: https://github.com/Sendrato/hal_nxp/tree/master-20220510-qn9090-v2.6.5-cleanup

- zephyr: https://github.com/Sendrato/zephyr/tree/k32_qn9090_cleanup-v3.0-branch

All basic perhiperals, timers and the BLE controller are functional. It is not yet released or pushed to the main zephyr-community, but we are planning to this eventually.

In a private branch we have also fixes for an NFC-tag subsystem (also supporting nRF), but this is for a different future release to the Zephyr project.

---------------

Update: the mentioned branches are outdated, for the latest (Zephyr v3.1 with mcux SDK 2.6.5) please follow these links:

- hal_nxp: https://github.com/Sendrato/hal_nxp/tree/master-20220510-qn9090-v2.6.5

- zephyr: https://github.com/Sendrato/zephyr/tree/v3.1-branch-qn9090

[HesselM]

Hi Eduardo, 

Thanks for your response. Unfortunately there is no information in UM111141 about this error. 

However, after lots of research and reverse engineering, we are quite certain the DA14585 [ https://www.renesas.com/eu/en/products/interface-connectivity/wireless-communications/bluetooth-low-... ] mcu uses the same BLE LL interface and radio as the qn9090.

According to the DA14585 datasheet, at offset 0x60 of the LL-perhiperal there is the "BLE_ERRORTYPESTAT_REG" register. And this specifies that error-code 0x20000 (bit 17) is error "CONCEVTIRQ_ERROR", or:

Indicates whether two consecutive and concurrent ble_event_irq have been generated, and not acknowledged in time by the RW-BLE Software.

Which, given the chip is maintaining multiple connections with notify's and switching between scanning and advertising, seems to be a reasonable error. Unfortunately we are currently not sure how to solve this..

Hessel

[EduardoZamora]

Hi,

I have been looking for more documentation that could help you. Unfortunately, that is the only information we can provide.

I apologize for any inconvenience this may cause you.

Regards,
Eduardo.

[HesselM · Accepted solution]

Hi Eduardo, 

Thanks again for the reply. 

In the meanwhile we figured out the reason for our problem: it turned out to be a scheduling issue after the BLE_LL_ALL_IRQn interrupt had been called. 

Additionally, after more digging, decompilation and reverse engineering we are quite certain that the qn9090 uses the same BLE-die as the DA14585 and DA14680.

So for others having the same issue and the need to debug the BLE-core:

We found some useful information on debugging the BLE core on page 147-153 (chapter 33) and page 181-199 (chapter 37.3) of the DA14680 data sheet (CFR0011-120-00-FM Rev 5). Note that the BLE-registers for the qn9090 start at 0x400a0000 instead of 0x40000000. A readout of BLE_VERSION_REG therefore should be from 0x400a0004 instead of 0x40000004.

Hessel.

[HesselM]

After some disassembly of the controller-archive we found out that the error is produced by the BLE Link Layer peripheral, stored at address 0x400a0000 in the qn9090 Memory Map. 

The error is retrieved from this address with offset 0x60 and the reset-call is from the BLE-LL irq-handler (BLE_LL_ALL_IRQHandler) .

We still have no clue why this error is produced and how to solve it. 

The test program connects with 3 different peripherals, maintaining connection and receiving data on a notify, while switching every 10 seconds between advertising and scanning. 

[EduardoZamora]

Hello Hessel,

We would like to remind you that the BLE protocol has time restrictions and definitions that need to be considered. Could you please confirm that these considerations are being met?

Information about the Link Layer in BLE protocol can be found in the QN9090 User Manual (UM11141) Chapter 41.6.1.3: Link layer.

Also, please take a look at the memory pools according to the source/project being used as base. Inside our SDK, you can find them in the app_preinclude.h file.

We would also recommend that you post your inquiry on the Zephyr community, just to verify if this could be related to the Zephyr software.

Regards,
Eduardo.