• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 51 subscribers
  • Views 479 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: Device hangs forever when SNV page is full

Mariano
Intellectual 285 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: SYSBIOS

Hi team,

SDK : 5.30.00.03
Base project : simple_peripheral_oad_offchip
SNV Sector = 1
Cache_AS_RAM = TRUE

I am facing a problem when the SNV page is full. When it is full and I try perform a write operation, the program throws an exception and hangs forever. I think the page is erased after the writing because the data of SNV page is all 0xFFFFFFFF.

The exception is the following: "Hard Fault: FORCED: BUSFAULT: PRECISERR.Data Access Error. Address = 0x80087"

Exception call stack :
0 ti_sysbios_BIOS_RtsGateProxy_query__E__mangled__ at :0 :": "PC=0x1001C104
1 ti_sysbios_knl_Task_SupportProxy_swap__E__mangled__ at :0 :": "PC=0xFFFFFFF9

Below additional data about tasks, hwi, heap metrics and heap stats.


Please, can anyone provide me some direction for solving that problem?

Thanks in advanced.

  • 0
    TI__Mastermind 37805 points

    Hello,

    Can you give me some more context for your actions here? Are you trying to overwrite values in SNV? Or are you trying to write values outside of SNV?

    Best,

    Nate

  • 0 in reply to Nathan Block
    Intellectual 285 points

    Hi Nate,

    Sure. I am trying to overwrite in SNV page.

    There are some variables im my project which are stored in SNV page. I changed the Customer NV Items range to 0x80 - 0xCB. 
    These variables has random access once it depends of user interaction.

    Everything works fine up to reach the last address of SNV page, the variables are overwrite several times and in random ways. I am watching the last address of SNV page with the Memory Browser. When the SNV page is full and I trying overwrite any variable in SNV page (the variable can be the lower possible) the program hangs forever.

    Before the program to hang I see that the SNV page is erased successfully. As you can see in my previous post the heap has 7096 bytes free so there is space in RAM for compaction of SNV page.

    Best regards,

    Mariano

  • 0 in reply to Mariano
    TI__Mastermind 37805 points

    Thank you for the updated description Mariano. I would recommend reviewing our documentation on SNV here.

    https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/blestack/ble_user_guide/html/ble-stack-common/flash_memory-cc2640.html

    I think this may be a compaction issue. Can you try to set OSAL_SNV to 2 to see if the problem still occurs?

  • 0 in reply to Nathan Block
    Intellectual 285 points

    Hi Nate.

    I set OSAL_SNV to 2 and in primary tests the problem does not occur. However I have some doubts in relation to set OSAL_SNV to 2.

    In according to thread https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1074755/cc2640r2f-incompatible-nv-settings-detected-oad-supports-1-nv-page is not recommended changing the default number of SNV pages for an OAD application. What do you say me about that?

    Besides setting OSAL_SNV to 2 , I have to set OAD_NUM_NV_PGS to 2.

    /*!
    * NV Page Setting:
    * This define is used ensure the stack is built with a compatible NV setting
    * Note: this restriction does not apply to the stack library configuration
    * for off-chip OAD
    */
    #define OAD_NUM_NV_PGS 2

    #ifdef OSAL_SNV
    #if OSAL_SNV != OAD_NUM_NV_PGS
    #error "Incompatible NV settings detected. OAD supports 1 NV page"
    #endif //OSAL_SNV != OAD_NUM_NV_PGS
    #endif //OSAL_SNV

    ======================================================================================

    Please, I have other question about the subject: Is it a SNV driver bug the compaction issue with OSAL_SNV equal to 1?

    Thank you

  • 0 in reply to Mariano
    TI__Mastermind 37805 points

    Hi Mariano,

    We're not 100% sure that the copying happens in the heap, not the stack. Can you make sure to try a few times in when you have 1 vs 2 flash pages to confirm that the problem always goes away when you have 2 pages? 

    Best

    Nate

  • 0 in reply to Nathan Block
    Intellectual 285 points

    Yes. The problem always goes away when I have 2 pages.

    I think the problem is due to when OSAL_SNV = 1 the SNV driver uses the CACHE memory as buffer for temporary storage during compaction and I use the CACHE AS RAM.
    I checked nvocop.c and nvoctp.c and both uses VIMS calls to enable/disable cache. However when we use the cache as ram we can't use VIMS calls.

    First, it isn't necessary enable/disable the cache in NVOCOP/NVOCTP once I am using the CACHE as RAM. Second, it is necessary to reserve a space in CACHE RAM (address 0x11000000) which will be used for compaction process.

    Do you think these steps can solving the problem?

    Thank you in advanced. 

  • +1 in reply to Nathan Block
    Intellectual 285 points

    Hi Nate.

    I kept the VIMS calls in the nvocop/nvoctp files but I reserved a space in the CACHE RAM for temporary buffer storage used by compaction process. For that I changed the GPRAM base address and size in the linker (about 1KB reserved for compaction proposal)

    #define GPRAM_BASE 0x11000400 (It was 0x11000000)
    #define GPRAM_SIZE 0x00001c00 (It was 0x00002000)  

    In primary test the problem goes away when the compaction occurs and I setting the OSAL_SNV = 1.

    Can you tell me if that workaround is fine for my problem? I am afraid that workaround can adding others problems for the project.

    Thanks in advanced.

  • 0 in reply to Mariano
    TI__Mastermind 37805 points

    Hi Mariano,

    That's great news! I'm glad you were able to find the root cause of your problem. It looks like we can confirm this is a problem in our docs here, where it says that VIMS cannot be used if using Cache as RAM, so if compaction is using VIMS, you'll have a problem.

    There is nothing obviously wrong to me about the actions you're taking, but I can't promise there will be no challenges in the future. Is it necessary for you to use Cache as RAM in this application? That would likely be the "safest" approach.

    Best

    Nate

  • 0 in reply to Nathan Block
    Intellectual 285 points

    Right. The main action was reserve a space in the cache ram for compaction propose. 

    Nathan Block said:
    Is it necessary for you to use Cache as RAM in this application?

    Yeah, SRAM is short to my application.