CC2340R5-Q1: Adjusting NVS has caused differences in the power-on sequence.

Supplementing power consumption monitoring during the second power-on execution.

Hi,

Out of curiosity, have you tried upgrading to the latest SDK to see if this persists? 

Ian Tsai said:

Is there a way to reset CC2340R5 to factory mode via software, without desoldering the chip?
I tried Chip Erase in UniFlash, but it didn't work.

A mass erase should erase everything on the device. Just to clarify, once you've done a mass erase on the chip, data is still on flash?

Ian Tsai said:

A software-based reset would greatly simplify future testing.

This does exist. See here: https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_8_40_00_61/docs/drivers/doxygen/html/_power_8h.html#a1db423246eb4407154df05d8fedbf746

Ian Tsai said:

On the second boot, execution reaches the program area in about 2 seconds.
However, if NVS is modified, the system takes three boots before stabilizing at 2 seconds.

I'm a bit confused, do you mind elaborating what you mean by the system takes three boots before stabilizing at 2 seconds?

Best,

Nima Behmanesh

Hi,

Since we have already entered the product verification phase, it is not suitable to switch to a different SDK at this time.

Apologies for my previous brief description. Recently, I conducted further tests and found that when flashing firmware with modified NVS settings onto a blank IC, the first power-on is always affected. However, if the firmware is reflashed, this issue does not reoccur.

Device Boot Process:

Observed Behavior:
I captured power consumption data using a current meter, and it appears that both NVS writes and SPI transmissions are affected on the first boot. This causes proper NVS read/write operations and SPI control to function only on the second boot.

Questions:
Does modifying the NVS address region require the system to rewrite corresponding information?
How can we prevent this overlap from causing control failures during the first boot?

Hi,

Yes, NVS writes usually are preceded with an invalidate, and then a write to next available NVS memory section:

https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_8_40_00_61/docs/ble5stack/ble_user_guide/html/ble-stack-common/flash_memory-cc23xx.html?highlight=non%20volatile#non-volatile-storage-architecture

Additionally, NVS will disable interrupts and executing code in flash: NVSLPF3.h File Reference

So it makes sense why SPI may not work if the NVS is writing information to the device. 

Ian Tsai said:

Apologies for my previous brief description. Recently, I conducted further tests and found that when flashing firmware with modified NVS settings onto a blank IC, the first power-on is always affected. However, if the firmware is reflashed, this issue does not reoccur.

By first power-on is always affected, you mean that it takes a little longer to execute? 

Best,

Nima Behmanesh

Hi,

By first power-on is always affected, that not just by a longer execution time, but by a failure to write default values to NVS.
This issue only occurs when flashing firmware with modified NVS address regions. (We tested the same project code, changing only the NVS configuration.)
We are unsure what specific processes occur during the first boot after flashing firmware with modified NVS addresses onto a blank IC, leading to NVS write failures.
Additionally, we need guidance on how to prevent this issue from happening.
This problem has already caused false detections in our ATE program, so we would greatly appreciate your support in resolving it.

Hello,

I apologize for the delay, I was out sick last week.

I think I'm understanding the problem better now. If it's a blank chip and doesn't use the default NVS settings included in our projects, there are issues writing to it on the first boot. After the second, third boot than writing occurs normally.

If my understanding is incorrect, please let me know. I'll need to reach out to the drivers team to see what the process is. In parallel, I'll try this myself. 

Here are the steps I'm going to do to try to reproduce:

1. Take a blank CC2340R5 and flash it using modified NVS settings

2. Read the NVS,

3. If it's blank write something to it

If the issue is reproduced, then the writing should fail on the first boot.

Is that right?

Best,

Nima Behmanesh

Hi,

No problem, please take care.
Yes, your understanding is correct, and the tests you plan to conduct align with my current process.
Looking forward to your updates. Thank you!

Hi Ian,

A couple of questions before I get started today trying to reproduce the issue:

1. Are you using NVS and external flash?

2. What compiler are you using?

These will help me rule out some variables that could be causing this issue.

Best,

Nima Behmanesh

Hi,

1. We are using the basic_ble_oad_dual_image example and have modified the default 16KB internal NVS into two separate 8KB blocks, with addresses configured as shown in the previous comparison image.
2. Compiler version: TI Clang v3.2.1.LTS.

Hello,

Thanks for the information, I'll respond with my results either today or tomorrow.

Thank you for your patience.

Best,

Nima Behmanesh

Hi,

Is there any update? Do you need any further support from us?

Hello,

I apologize for the delay, we are still working on this issue. I will get back to you as soon as possible.

Best,

Nima Behmanesh

Hi,

I think your reasoning is valid. In my program flow, broadcasting and other operational parameters are stored in NVS, so I need to retrieve these parameters before initializing the BLE stack. Therefore, the NVS API calls occur before BLE stack initialization.
However, I noticed that osal_snv_init only executes after icall is initialized. Even if I manually call it earlier, it does not take effect.
Is there a way to initialize NVS before BLE stack initialization, ensuring I can access stored parameters?

Here is my code snippet.

Hi,

Sorry, I seem to have misunderstood the code. The App_StackInitDoneHandler runs after the BLE stack initialization, so my NVS API calls are indeed executed after the BLE stack has been initialized.

Hello,

I tried the same test on basic_ble, but reading/writing NVS before the stack is initialized, and I'm not seeing any issues. I did this by modifying the appMain function in app_main.c:

NVS_Handle region1;
NVS_Params nvsParams;
uint8_t buf[32] = {0};

void appMain(void)
{
    NVS_init();
    GPIO_init();

    NVS_Params_init(&nvsParams);
    region1 = NVS_open(CONFIG_NVS_0, &nvsParams);

    int_fast16_t status = 0;
    status = NVS_read(region1, 0, buf, 1);
    if (status != NVS_STATUS_SUCCESS)
    {
        GPIO_write(CONFIG_GPIO_LED_RED, 1);
        while(1);
    }

    if (buf[0] == 0xFF)
    {
        status = NVS_write(region1, 0, 0, 1, NVS_WRITE_POST_VERIFY);
        if (status != NVS_STATUS_SUCCESS)
        {
            GPIO_write(CONFIG_GPIO_LED_GREEN, 1);
            while(1);
        }
    }

    // Call the BLEAppUtil module init function
    BLEAppUtil_init(&criticalErrorHandler, &App_StackInitDoneHandler,
                    &appMainParams, &appMainPeriCentParams);
}

Note that I'm doing the reading and writing before the stack has initialized.

Best,

Nima Behmanesh

Hi,

Since the documentation recommends using OSAL to access NV, we are using osal_snv_read() and osal_snv_write() to directly access the BLE_NVID_CUST_START location.
Would you mind testing again using OSAL as per this method?

Hello,

Yes, I’ll try this tomorrow and get back to you.

Best,

Nima Behmanesh