CYW20706 NVRAM strange value over write issue

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
munjr0612_48795
Level 2
Level 2
10 replies posted 5 questions asked 50 sign-ins

SDK : WICED-Studio 6.2

Currently, nvram id 0x71~0x74 is managing the setting value used, but some data is being overwritten.
If you read the nvram data, you will see that the current data is "77646F672E632D36382D613630343065373100" = "wdog.c-68-a6040e71".
I don't have a process to write related data. I'd like to know the conditions or reasons why the data is used.

0 Likes
19 Replies
advait_kulkarni
Moderator
Moderator
Moderator
25 likes received 250 sign-ins 100 solutions authored

Hi @munjr0612_48795 ,

WICED-Studio 6.2 is a very old release and there is no longer support available for it. Kindly upgrade to Modustool box with latest BTSDK, and let us know if this issue is observed in MTB and latest BTSDK.

Thanks and regards,

Advait Kulkarni

lock attach
Attachments are accessible only for community members.

We checked through Flash dump after forced watchdog to ModusTool Box.
Currently, we have confirmed the data "F113693877646F672E632D36382D3739623332346000F0001274D7200FF" when watchdog occurs.
I checked the same data as wdog.c in this data.

Why is this data in here?

Attached is the current code. Please check.

0 Likes
advait_kulkarni
Moderator
Moderator
Moderator
25 likes received 250 sign-ins 100 solutions authored

Hi @munjr0612_48795,

The wdog.c file that you have mentioned is not present in the zip. Can you please let us know from which app did you check that file from? Or which app you are using for this code? Is it rfcomm_spp example? It would be great if you can share your entire project.

Thanks and regards,

Advait Kulkarni. 

lock attach
Attachments are accessible only for community members.

I used the code file attached to "RFCOMM_Serial_Port" example using MBT 2.2 SDK.
I modified it to cause watchdog when entering a button in the basic example.
After that, when the watchdog reset occurs, you can check that certain data is used through flash dump.

I proceeded with the dump with perl dump_readram.pl, and I delivered the flash dump result.

Among the dump data, "77646F672E632D36382D373962333234" Please tell me the reason why this data is used.

The hextoascii of the above data is "wdog.c-68-79b324".

I will attach the entire project.

Thanks and regards,

0 Likes

Please let me know the current progress..

Thanks and regards.

0 Likes
advait_kulkarni
Moderator
Moderator
Moderator
25 likes received 250 sign-ins 100 solutions authored

Hi @munjr0612_48795 ,

We checked internally, and we think that the data does not have any significance and would be random. In any case, you should be able to write into that part using the flash apis (refer to https://infineon.github.io/btsdk-docs/BT-SDK/30739-A0_Bluetooth/API/group___serial_flash_interface_d...). Did you try that and still getting any error? 
We will continue to check about this till we make sure, kindly give us some time on that. Let us know if there are any errors on using the APIs.

Thanks and regards,

Advait Kulkarni

0 Likes

All schedules are being delayed.
Please I beg you.

Thanks and regards.

0 Likes
advait_kulkarni
Moderator
Moderator
Moderator
25 likes received 250 sign-ins 100 solutions authored

Hi @munjr0612_48795 ,

Can you please tell me if you have tried using the APIs that I have shared? To write your data in the NVRAM?

Thanks and regards,
Advait Kulkarni

0 Likes
RyMu_1654936
Level 3
Level 3
Distributor
First like received 250 sign-ins 100 sign-ins

Hi Advait

The issue is unwanted data is programmed in the flash when the watchdog is reset.
The unwanted data looks watch-dog log. "wdog.c-68-79b324".

BTW, the area un-wanted data were programmed is used for a specific purpose.
So, their data is overwritten by the watchdog log.

Could you help to remove to program watchdog log when the watchdog is reset?


Regards,
Ryan

0 Likes
advait_kulkarni
Moderator
Moderator
Moderator
25 likes received 250 sign-ins 100 solutions authored

Hi @RyMu_1654936 ,

During the any of the flash operations, the device should not be reset, including the XRES pin, a software reset, and watchdog reset sources. Otherwise, portions of flash may undergo unexpected changes. Can you check if this could be causing the issue.

Other than that, I tried to reproduce your issue at my end, but the device did not force a wdog reset. You have programmed the button on the eval kit for reset only right? 

Thanks and regards,

Advait Kulkarni

0 Likes

Hello Advait,

I'm Romeo who's in charge of S/W team leader.

Munjr is on a vacation, so I am answering instead.

This issue occurred in the factory automation test, i.e. power on/off test.

Therefore, we do not know if it was reset during any flash operations.

We made wdog reset intentionally.

As an example, when the button is pressed, it enters an infinite loop.

if (button_pressed)

   while(TRUE);

Please reproduce in this way and let us know the result of the review.

 We look forward to your prompt relpy.

BR, Romeo

 

 

 

0 Likes
Romeo
Level 1
Level 1
5 replies posted 10 sign-ins 5 sign-ins

Hello Advait,

Adding to help your understand.

In this case, the watchdog is not our main concern.

The main issue is that the unknonwn logs are written in NVRAM when watchdog happened. 

And which area of NVRAM is reserved to store the watchdog logs?

Please focus on this point.

Thanks, Romeo

0 Likes
Romeo
Level 1
Level 1
5 replies posted 10 sign-ins 5 sign-ins

Dear Advait,

Happy new year!

Could you update current status?

 

Thanks,

Romeo

0 Likes
Romeo
Level 1
Level 1
5 replies posted 10 sign-ins 5 sign-ins

Dear Advait,

Could you share your schedule?

There has been no update for long time. So, our customer has a big trouble with mass production schedule.

Please accelerate to solve this.

Thanks, Romeo

 

0 Likes
RyMu_1654936
Level 3
Level 3
Distributor
First like received 250 sign-ins 100 sign-ins

Hi Advait, 

"Can you check if this could be causing the issue?"

=> When the watchdog reset, it writes something in the NVRAM. However, this area is used for user areas. 

      Consequently, user data is overwritten by watchdog logs. 

 

      Though watchdog should not happen, it happened anyway. 

       Could you help with 'The logs are written in the NVRAM even though watchdog happens'? 

        It looks like this routine is not included in the customized code we can access. 

 

Regards, 

Ryan

0 Likes
RyMu_1654936
Level 3
Level 3
Distributor
First like received 250 sign-ins 100 sign-ins

Hi Advait, 

If watchdog logs are written in a specific area, please let us know. 

The customer could try to avoid the area. 

 

Regards, 

Ryan

0 Likes
advait_kulkarni
Moderator
Moderator
Moderator
25 likes received 250 sign-ins 100 solutions authored

Hi @RyMu_1654936 ,

Apologies for the delay in response. I was unable to reproduce your issue with your code this week as there was a code flashing issue with the 706 boards due to an internal update. Will take up this task on priority as this will be fixed in a day or two.

Regarding your query on "area in flash to avoid", if a reset is triggered by the watchdog timer, the logs (for fault analysis) get stored in the last row of the flash . Also, as I said earlier, make sure that device does not go into reset during flash operations.

Thanks and regards,

Advait Kulkarni.

 

Hello. @advait_kulkarni 

I would like to know the meaning of "last row of the flash" among what you said.
Are you saying that it will be stored in an available flash?
What happens if the error log is stored in the last row and the available flash is full?

And may I know the current progress of the work?

Thank and regards.

0 Likes

Hello, @advait_kulkarni 

May I know the current progress? Is it being modified?

Thanks and regards, Mun.

 

 

0 Likes