• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 291 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.

CC2745R10-Q1: No-Init SRAM

Marcus Frech
Intellectual 1550 points

Part Number: CC2745R10-Q1

Hi,

customer has below question.

This is regarding data sharing between the application and bootloader across software reset on the CC2745R10-Q1 - BTLE Chip.

 

We have a custom bootloader (Bank 0 in PFLASH) and an application ( Bank 1 in PFLASH). We must share a set of data between the bootloader and application.

 

We see two possible options , but we have questions/issues with both.

 

Option 1: No-Init RAM (SRAM)

 

We are trying to store shared data using no-INIT RAM (SRAM) on CC2745R10-Q1.

We configured based on the TI E2E forum thread: CC2745R10-Q1: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1514098/cc2745r10-q1-customizing-noiit-region-compilation-will-result-in-errors

 

Issue:

No-init RAM is not retaining data across software reset.

Note : software reset is triggered in software using system API `NVIC_SystemReset()`.

 

Could you please guide us possible reasons and recommended configuration?

If possible, a TI example would be helpful. Kindly let us know if you need any additional details from our side like our configuration w.r.t No int RAM.

 

Many thanks and best regards

Marcus

 

 

  • 0
    TI__Prodigy 201 points

    Hi Marcus,

    Sorry for the late reply. We are already on it, and will provide more info tmr.

  • 0
    TI__Prodigy 201 points

    Hi Marcus, we think it could be some compiler relared issue. We are working on a workaround w/o touching the compiler first, we will update as soon as there is some progress. 

  • 0 in reply to Zhitao Wu
    TI__Prodigy 201 points

    Marcus, after some investigation, we found location could be the key factor. You can either assign the section location as the quoted ticket does, or you can define your shared data with a location attribute like this.

    __attribute__((noinit,location(0x20001000))) int noinit_location_global;
  • 0
    Prodigy 50 points

    Thanks for your feedback. The proposed solution worked well for us. We configured a no-init RAM variable at a fixed RAM location using:


    __attribute__((noinit, location(0x20001000))) int noinit_location_global;

    The value is retained across software resets and can be shared successfully between the bootloader and the application.

    However, I have one question regarding the observed behavior. In the bootloader, I increment a reset counter on every reset. The application clears this counter once it becomes stable and no further resets occur.

    After the application clears the counter, if a reset occurs again, I observe the following:

    First reset → counter = 1
    Second reset → counter = 1
    Third reset → counter = 2

    I was expecting the counter to become 2 on the second reset itself. Is this expected behavior? If so, could you please explain the reason behind it?

    This is not a blocker for us, as the counter continues to increment from the third reset onward. However, we would like to understand why the increment is not reflected on the second reset after the counter has been cleared by the application.

  • 0 in reply to Naveen Balachandar
    TI__Prodigy 201 points

    Hi Naveen,

    What is not clear to me is the clear logic, is it possible to skip the clear logic and see how it goes?

  • 0 in reply to Zhitao Wu
    Prodigy 50 points

    Hello ,

    Yes for my testing, I'm not clearing the reset counter and oberved the same behaviour.

    JFYI: I have bootloader runs at Bank 0 -(Address 0 )and application is at bank 1

  • 0 in reply to Naveen Balachandar
    TI__Prodigy 201 points

    Hi Naveen, 
    I tried the single application mode with resets, the counter incremented at every reset. Will check the bootloader/application mode you mentioned and get back to you.

  • 0 in reply to Zhitao Wu
    TI__Prodigy 201 points

    Hi Naveen, I tested the bootloader/application combination, it also looks ok. 

  • 0 in reply to Zhitao Wu
    Prodigy 50 points

    Sorry for the late reply. In my case, the bootloader is located at address 0x00000000. After a restart, execution begins in the bootloader, where I increment the reset counter. The bootloader then increments the counter by +1 and jumps to the application at address 0x00080000. When the application resets, it jumps back to the bootloader.

    I observe the behavior mentioned earlier: the reset counter value is 1 after the first reset, 1 after the second reset, 2 after the third reset, 4 after the fourth reset, and so on. Therefore, the issue still exists on my side. Specifically, the counter value remains 1 for two consecutive resets, which is the behavior I am concerned about.

    Did you test using the same logic/setup? If so, what reset counter values do you observe after each reset?

  • 0 in reply to Naveen Balachandar
    TI__Prodigy 201 points

    Hi Naveen, 
    Yes, it is the same logic, increment in the bootloader and print out in the application. The setup is simple modification from the existing mcuboot/mcuboot_blink examples in the SDK examples, only the application is located at 0x6000. Here is a screenshot.

  • 0 in reply to Zhitao Wu
    Prodigy 50 points

    Thanks for the feedback. It is strange that this issue is occurring in our case. Fortunately, it is not a major concern, as the counter increments correctly after the second reset.

    Do you have any suggestions on what might be causing this behavior?