deep sleep being blocked by IPC

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

cross mob
SuMa_296631
Level 5
Level 5
50 replies posted 25 replies posted 10 replies posted

I had an application that worked correctly:

- PSoC 63 (CYBLE-416045-02)

- PSoC Creator (was 4.2, now updated to 4.3)

- PDL v3.1.2 (was v3.1.1)

The code calls "Cy_SysPm_DeepSleep(CY_SYSPM_WAIT_FOR_INTERRUPT)" with an interrupt coming from an MCWDT.

After I upgraded, the call now gets stuck in 'cy_syspm.c" at

    /* Acquire the IPC to prevent changing of the shared resources at the same time */

    while(0U == _FLD2VAL(IPC_STRUCT_ACQUIRE_SUCCESS, REG_IPC_STRUCT_ACQUIRE(CY_IPC_STRUCT_PTR(CY_IPC_CHAN_DDFT))))

    {

        /* Wait until the IPC structure is released by another CPU */

    }

(Lines 2882 to 2886).

This is being called from the same module by

        /* Different device families and revisions have a different Deep Sleep entries */

        if (Cy_SysLib_GetDevice() == CY_SYSLIB_DEVICE_PSOC6ABLE2)

        {

            /* The CPU enters Deep Sleep and wakes up in the RAM */

            EnterDeepSleepRam(waitFor);

        }

        else

        {

I can provide further information if required.

What needs to be done to get this code working again?

Susan

0 Likes
1 Solution
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi SuMa_296631​,

I programmed the project again into the device that I had and it worked. I tried it a couple of times and it worked. I asked one of my colleague to try the same and it failed. I then erased my device using PSoC Programmer, programmed it again and now it failed for me too.

After a bit of debugging I found that if you program the Release version of the hex and then program the Debug version of the hex the program works. I am not sure how consistent it is as I do not have many Kits to test it extensively.

That being said, I found this KBA  - Updating PDL syspm Driver for Hard Fault Problem – KBA229335

After following the steps mentioned to modify the cy_syspm.c I was able to find consistent results in both the Kits. I erased the device and reprogrammed and I could observe the LED turn on after 1 minute in both the Kits. I do not have more Kits to test this on other devices. I will request the internal team for support.

Meanwhile, can you please try out the same steps and let me know if that worked for you?

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B

View solution in original post

0 Likes
13 Replies
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi SuMa_296631​,

Can you try running the CE220608 - PSoC 6 MCU Multi-Counter Watchdog Timer in Watchdog Mode and let me know if that project works for you?

If it does, can you please attach a minimal version of your project in which issue occurs so that I can try it out from my end and debug the same?

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes

I have attached the zip file of the workspace/project.

the way the project should work is that the LED will light while the BLE is advertising. That means it will light for 10 seconds at the start and then stop while the device is in deep sleep. It should wake after 1 minute in which case the LED should light again.

If I use the IDE to attach to the running target (CM4) after the MCWDT should have timed out, it is stuck at the line indicated in the first post.

Susan

0 Likes
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi SuMa_296631​,

I noticed that you have an EEPROM component. There is a known issue where the system enters a deadlock when there is any clock measurement call during flash write operations.

The clock measurement API is being used by the BLE controller library internally. BLE takes care of the flash operations that it performs and ensures that there is no conflict between flash writes and clock measurements that it initiates. But it does not have control over the user flash writes or other middleware flash operations.

Our internal team is working on implementing a mechanism to control shared resources across all drivers/middleware.

As a workaround can you please wrap the user flash operation with the following code -

/* Inform Controller core about write operation */

while (CY_IPC_SEMA_SUCCESS != Cy_IPC_Sema_Set(CY_BLE_SEMA, false))

{

      /* Polls whether sema is not set */

}

.... User Flash operation....

/* Inform BLE syspm callback about complete of write operation */

while (CY_IPC_SEMA_SUCCESS != Cy_IPC_Sema_Clear(CY_BLE_SEMA, false))

{

      /* Polls whether sema is not clear */

}

Please let me know if this works.

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes

No change to the apparent behaviour but now when I attach the debugger to the running program I get the call stack

pastedImage_0.png

I must admit that your explanation did surprise me a bit because the only times the EEPRO is used is once, right at the start of the app (to read any existing 'local name' and to create a default one if needed) and also when the user writes a new 'local name' value - which I've NOT done in this test.

Also this code used to work.

Just to be sure I've followed your instructions correctly, the code (to save a new local name - note that this code is not executed in this test run) is now:

  /* Inform Controller core about write operation */

  while (CY_IPC_SEMA_SUCCESS != Cy_IPC_Sema_Set(CY_BLE_SEMA, false))

  {

        /* Polls whether sema is not set */

  }

  // Save to the EEPROM for the next reboot

  EEPROM_Write(0, &newLocalName,sizeof(tLocalName));

  /* Inform BLE syspm callback about complete of write operation */

  while (CY_IPC_SEMA_SUCCESS != Cy_IPC_Sema_Clear(CY_BLE_SEMA, false))

  {

        /* Polls whether sema is not clear */

  }

The EEPROM_Write was original and I've added your code around it.

Susan

0 Likes
lock attach
Attachments are accessible only for community members.
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi SuMa_296631​,

Thank you for the update. I added the code around EEPROM init and EEPROM read as well and I could observe the LED turning on every minute as you mentioned.
I have attached the project for your reference.

Can you please confirm that the project functionality is working as expected?

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes

Hello Rakshith,

I extracted the zip file, opened the project file in the PSoC Creator IDE, clicked the 'Program (Ctrl+F5)' icon, the program was built and was then uploaded into the CY8PROTO-063-BLE board.

After 1 minute it crashed in exactly the same way I showed you in my reply of the 14th.

Just a couple fo questions about your test setup:

- is it the CY8PROTO-063-BLE board?

- Is there a board revision number that might be important to show the difference between our test results?

- What is the correct settings in the .ld files for the 'em_eeprom' memory area? (I've seen the post at EEPROM compile error )

- Are you using the GCC compiler? (I'm clutching at straws here trying to think what could be different)

Thanks for your assistance

Susan

0 Likes
lock attach
Attachments are accessible only for community members.
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi SuMa_296631​,

- is it the CY8PROTO-063-BLE board?

Yes I am using CY8CPROTO-063-BLE Board. I did not change the selected device in the project.

- Is there a board revision number that might be important to show the difference between our test results?

I do not think so. There is an issue with older devices in PSoC 6 WiFi-BT and PSoC 6 BLE Pioneer Kits. You have mentioned that the Green LED turns on initially. If it is a board issue then the program execution fails before main(). So I do not think it is a board revision issue.

- What is the correct settings in the .ld files for the 'em_eeprom' memory area?

I have not changed any linker script settings or settings of any component in the TopDesign schematic.

- Are you using the GCC compiler? (I'm clutching at straws here trying to think what could be different)

Yes, I am using the GCC Compiler. Here are some additional information that might help -

Programming Output Log:

pastedImage_8.png

Build settings, configuration, PDL version:

pastedImage_9.png

PSoC Creator version:

pastedImage_10.png

I would like to add another thing which I think might be the reason the project is not working for you. When I tested the project, I observed just the Green LED turning ON after 1 minute. I did not check the BLE connections. I found that there is another EEPROM_Write() in the StackEventHandler(). I have added the above code to the StackEventHandler() function too. I have attached the project as well as the hex file that worked for me. Please program the project/hex file and let me know if it works.

Hope it works,

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes

OK - the build settings etc are all the same. Thank you for posting that information.

I mentioned that write in the BLE callback earlier but I also said that it was a code path that was NOT taken in my testing.

I've tried on a newly build circuit board (one that the code will eventually run on) but the issue is always the same: without your code the program gets stuck waking from deep sleep; with your code it always crashes waking from the deep sleep.

I'm trying something whacky now - I've uninstalled the apps and also deleted all of the references to data that I can find on the computer and generally cleaned it up. I'll then re-install the PSoC Creator from scratch and re-create the app. A little while ago I was having other issues with some of my code and I found that creating a new app (that did exactly the same thing) fixed whatever the problem was.

If that doesn't work then I'm really not sure what to try next.

Thank you for your continued assistance with this.

Susan

0 Likes

By the way, I programmed the board with the hex file you provided (after a complete re-install of PSoC Creator 4.3) and it crashes in exactly the same was as described above.

Susan

0 Likes
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi SuMa_296631​,

I programmed the project again into the device that I had and it worked. I tried it a couple of times and it worked. I asked one of my colleague to try the same and it failed. I then erased my device using PSoC Programmer, programmed it again and now it failed for me too.

After a bit of debugging I found that if you program the Release version of the hex and then program the Debug version of the hex the program works. I am not sure how consistent it is as I do not have many Kits to test it extensively.

That being said, I found this KBA  - Updating PDL syspm Driver for Hard Fault Problem – KBA229335

After following the steps mentioned to modify the cy_syspm.c I was able to find consistent results in both the Kits. I erased the device and reprogrammed and I could observe the LED turn on after 1 minute in both the Kits. I do not have more Kits to test this on other devices. I will request the internal team for support.

Meanwhile, can you please try out the same steps and let me know if that worked for you?

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes

Hello Rakshith,

I know it sounds strange but I'm glad that you have seen the code fail. It is frustrating (for both of us I'm sure) when it always works for you but not for me.

I've tried using the programmer on its own to program the release and then the debug versions but without success.

While I was in the programmer I noted that it provided more information about the device:

Program Finished at 19:49:34                                                    |

                                                                                | Programming Succeeded

                                                                                | Verification of WFlash Succeeded

                                                                                | Verification of WFlash Started...

                                                                                | Verification of Main Flash Succeeded

                                                                                | Verification of Main Flash Started...

                                                                                | Programming of WFlash Succeeded

                                                                                | > Transfer rate: 7.09 KB/sec. 5632 bytes transferred (11 blocks x 512 bytes) in 776 ms

                                                                                | Programming of WFlash Started...

                                                                                | Programming of Main Flash Succeeded

                                                                                | > Transfer rate: 7.41 KB/sec. 191488 bytes transferred (374 blocks x 512 bytes) in 25231 ms

                                                                                | Programming of Main Flash Started...

                                                                                | Erasing of WFlash Succeeded

                                                                                | Erasing of WFlash Started...

                                                                                | Erasing of Main Flash Succeeded

                                                                                | Erasing of Main Flash Started...

                                                                                | Unchecked sections will be skipped for Program operation

Device set to CYBLE-416045-02 at 19:48:55                                      | 1048576  FLASH bytes

Device Family set to CY8C63xx at 19:48:55                                      |

                                                                                | Automatically Detected Device: CYBLE-416045-02

                                                                                | Silicon: 0xE2F0, Family: 0x100, Rev.: 0x23 (*C)

                                                                                | SROM Firmware: 4.01, Flash Boot: 1.20.1.42 (*C)

                                                                                | Protection state: 0x02 (NORMAL), Life Cycle stage: 0x01 (NORMAL)

Program Requested at 19:48:54                                                  |

Memory Types Load from HEX Finished at 19:48:51                                |

Memory Types Load from HEX Requested at 19:48:51                                |

Active HEX file set at 19:48:51                                                | C:\Users\Administrator\Documents\SolarPanel.cydsn\CortexM4\ARM_GCC_541\Debug\SolarPanel.hex

I'm not sure if that has anything to do with it...

Applying the changes in the KBA article has the device working again in both debug and release modes.

HOWEVER, the cy_syspm.c file seems to be recreated whenever you change the design and it regenerates the appropriate code. Therefore you loose the changes that are made.

Is there a way to make those code changes a bit more permanent?

Susan

0 Likes

To answer the my last question - I found the folder where the template file is kept and edited the changes from the KBA in there. I can now rebuild the whole app from scratch correctly (release and debug).

BTW, it works without your suggested changes of the wrapper code around the EEPROM functions. They may or may not be relevant as the problem seems to have been the crash coming out of deep sleep.

Thanks for finding that article and the help.

Susan

0 Likes
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi SuMa_296631​,

I know it sounds strange but I'm glad that you have seen the code fail. It is frustrating (for both of us I'm sure) when it always works for you but not for me.

I agree with that.

I've tried using the programmer on its own to program the release and then the debug versions but without success.

Thank you for the update. I will test it out on my end with multiple devices once I have access to more devices.

Applying the changes in the KBA article has the device working again in both debug and release modes.

Glad the issue is resolved

Is there a way to make those code changes a bit more permanent?

Yes, PSoC Creator copies the Generated Source from the PDL that is installed. I would recommend creating a copy so that you can use the original PDL version if needed. This is what I did -

1. Copied 3.1.2 folder in the PDL installation directory and renamed it to Changed_3.1.2. By default the PDL installation directory is - C:\Program Files (x86)\Cypress\PDL

2. Edited the cy_syspm.c file in the renamed folder. For me, the file is in this directory - C:\Program Files (x86)\Cypress\PDL\Changed_3.1.2\drivers\peripheral\syspm

3. In PSoC Creator, chose the Changed_3.1.2 PDL folder as shown -

pastedImage_5.png

4. Ensure that the linker script is not replaced. Build and program the device.

This worked for me. Please try it out and let me know if this meets your requirements.

Thanks and Regards,

Rakshith M B

Edit:

I am sorry, I had not refreshed the page and I missed your response. I see that you have done the same thing

>>BTW, it works without your suggested changes of the wrapper code around the EEPROM functions. They may or may not be relevant as the problem seems to have been the crash coming out of deep sleep.

Thank you for this update. I tried it out and I am aligned with your statement.

Thanks and Regards,
Rakshith M B
0 Likes