AnsweredAssumed Answered

QN9020 - NVDS no longer works even after chip erase - locked flash?

Question asked by Richard Aplin on Jul 7, 2016
Latest reply on Jun 16, 2017 by Mike Williams

The issue is;

1) The NVDS (nonvolatile data storage) is no longer working. Programs running can no longer read or write NVDS 'tags' (i.e. small pieces of data) - when reading the error code is NVDS_TAG_NOT_DEFINED  and when attempting to write the error code is "NVDS_FAIL" .

1a) This means the chip cannot be programming with a unique MAC address; there are other problems resulting as well, but this is the most serious that I cannot work around.


2) The same code used to work, I am using the standard library functions.


3) Performing a full chip erase via SWD or bootloader does not fix the issue.  Normal application code (app size = ~50kbytes) programs and runs ok.


4) The NXP "QBlue NVDS Configurator" with a serial connection reports "Dump NVDS data from target is fail!" when it tries to connect.

Inline image 1

5) The "QBlue ISP Studio" when used to "Download Configuration File" with "Verify" (writing test .nvds file with default settings) shows

Inline image 2


5a) The ISP studio can program the application corrrectly over the same serial link, also SWD using JLink works.

5b) Performing a full chip erase via SWD reports OK, but does not fix the problem.


6) Digging deeper, running code and using the "read_flash" function to read the 0 - 0x1000 area in flash shows that it is properly erased to 0xff after a full chip erase. Writing test values (all 0xaa or 0x00 or 0xaa55 etc) to that area with the "write_flash" works, and reads back correct values.

6a) However! Doing same operation with the 0x1f000-0x1ffff range (second copy of the NVDS data at end of flash) shows a garbage data pattern stored (semi-random bytes). After a full chip erase this is not 0xff. 


7) Performing these operations on a previously unused board work fine.


8) Looking at the serialflash.c library file and docs, it is obvious that the QN9021 incorporates a standard SPI flash device (either as a separate die in the package or integrated on the same silicon). e.g. from "serialflash.c"


/// Serial flash command list


uint8_t g_flash_cmd[MAX_FLASH_CMD_NUM]=


    0x05,       /*!< Read Status Register */

    0x06,       /*!< Write Enable */

    0x20,       /*!< Sector Erase */

    0x52,       /*!< Block Erase */

    0x60,       /*!< Chip Erase */

    0xB9,       /*!< Deep Power Down */

    0xAB,       /*!< Release form Deep Power Down */

    0x01,       /*!< reserved, the value is not 0x00 and 0xFF */


These are all standard SPI flash programming commands.


The JEDEC ID reported for the SPI flash is 0x001120c2


9) Looking at other SPI flash chip documentation, some vendors support a write-protect feature where bits can be set to prevent erase/reprogramming of certain areas of the chip. These features are different for different SPI flash vendors. Some vendors implement a one-time-programmable mode where once set, these bits cannot be cleared.



10) My guess is that this on-chip SPI flash supports a write protect feature that I have somehow accidentally triggered (I did until a couple of days ago have a stack-overrun bug that crashed the CPU). 



11) If (10) is the case, which is my current belief, my request from NXP is that they give a little more detail on the actual SPI die used within the QN9021 - if it is a commercially available part I would like the datasheet - and help me understand how to reset the flash write-protection bits if that is possible.