PSoC6 Bootloader Upgradeable BLE Stack and Emulated EEPROM - EEPROM write always fails with flash drive status CY_FLASH_DRV_IPC_BUSY

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

cross mob
TrWi_4480416
Level 1
Level 1
First question asked 5 replies posted First reply posted

Pre-implementation of the upgradeable BLE stack the Emulated EEPROM component was being successfully used within my application. Post upgradeable ble stack implementation I can no longer successfully perform an EEPROM write.  EEPROM write fails and with some debugging it is determined that the Cy_Flash_SendCmd is returning CY_FLASH_DRV_IPC_BUSY.  All aspects of the bootloading process, both stack and application, work well so in general my Bootloader implementation is sound, only the EEPROM flash writes fail.

I've made no changes to how or where I call my EEPROM writes within my application.  I can only assume that something related to the linker scripts associated with the upgradeable stack implementation has resulted in a conflict.

I have modified the linker scripts to use the CM0 core only.  Note however that both CM0 and CM4 linker scripts contain .cy_em_eeprom sections (untouched from Upgradeable Stack example project)

Anyone experience a similar issue or might know why a Flash write process might fail in this manner?

0 Likes
12 Replies
ShipingW_81
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

This issue looks not straightforward. Generally, there would be compiling error if there is any linker scripts conflict.

The component CPU core setting of both the stack and user application must be same. If you have also modified on app1/bootloader to run the stack on single core0 when you "modified the linker scripts to use the CM0 core only" ?

In addition, which core you call the EEPROM writes on?

0 Likes

The linker scripts are the same for both stack and user app. The modifications made were to set things up for the stack to run on core0 and those changes were made in both stack and application projects. I've made no adjustments to any script regarding the EEPROM flash area.

I only call the EEPROM writes on core0.  I basically do nothing with core1.

0 Likes

I was just able to successfully write to EEPROM but it required calling Cy_SysDisableCM4();

It seems that within the Cy_Flash_SendCmd function it was checking for whether CM4 was enabled and if so then entering a loop waiting a SEMA lock by peer core, which never occurs. 

Simply commenting out Cy_SysEnableCM4() was not enough. I had to call the CM4 disable function. Why would this be as I understand the CM4 core to be disabled be default upon startup?

Also, if I had wanted to also use CM4, what steps would I have had to take to get the EEPROM write to work and why did I not have to undertake these steps before implementing the bootloader?

0 Likes

You meant you have both run BLE stack and call EEPROM wirtes on single cm0+, correct?

Could you attach your project here?

A known conflict between BLE component and EEPROM component is discovered - Manage Working Flash Space for Both Cores of PSoC® 6 – KBA224173

Take a look at it check if it can bring you any help.

In addition, note this code exmaple by now only works under PDL3.0.1.

A tentative code example working with PDL3.1.0 is provided in following thread - PSoC 6 OTA bootloader issues​.

0 Likes

Correct, I run the BLE stack and call EEPROM writes on only the CM0+ core.

Note that bootloader linker scripts for both cm0 and cm4 contain an .cy_em_eeprom section occupying the same space.

As I previously stated, I now have a workaround to successfully write to EEPROM within my application code by immediately disabling the CM4 core when my application begins. The call to disable CM4 is likely needed because CM4 is enabled within the stack code so that when my application code begins to run CM4 is technically enabled. Therefore I must disable it in my application, or the EEPROM write fails due to the IPC drive busy status returned during the Flash_SendCmd.call that is part of an EEPROM write call.

It still isn't clear to me however why an EEPROM write would fail when both cores are enabled?  I can understand the risk of accessing the same flash space from both cores but there should be no reason that the EEPROM write should fail in the manner that it does(IPC drive busy)

I'm using PDL 3.0.4.

0 Likes

Possible to attach your project?

The situation on my side is, I can not get a successful build if I put both BLE stack host and EEPROM W/R operation on single cm0+. It shows a merge error that section 0x14000000 overlaps. The root-cause is what said in the KBA I mentioned previously. To eliminate the error, I have to split the whole working flash space for dual cores respectively through modifying the linker files.

Therefore, I am not be able to test how the EEPROM write could be affected by whether cm4 disabled on cm0+ or not.

0 Likes

I would like to attach my project for you to help get to the bottom of this but I cannot do so on a public forum.  I need a direct method to send you the project.

0 Likes

You can just provide a simplified demo project to be able to demonstrate the issue.

In addtion, any comment on post#7? How could you keep the BLE host and EEPROM w/r operation existing on single cm0+?

0 Likes

To create a demo project I would have to strip all of my product's proprietary application code out.  I'm not certain when I will be able to get around to doing this but I'll post it when I am finally able to do so.  If you want to look at the project sooner we would need a private means to exchange.

Perhaps I'm able to run both the BLE host and EEPROM w/r on CM0+ because my launcher and my stack start up both cores and I only disable the CM4 core once my application begins to run, after which I can successfully write and read EEPROM on CM0.

0 Likes

It's not easy for me to reproduce your scenario. Because the batch file is applied only to the CM4 binary, I can not mange all work on cm0+ with DFU function and disable cm4. The required cyacd file could not be generated.

0 Likes
docn_292601
Level 2
Level 2
10 replies posted 10 sign-ins 5 replies posted

I have the same issue, and this issue costed me 2 weeks, finally, i have to store my configures in to a Flash Chip outside.

My application run on core1, even i made core0 into sleep mode, not work.

Does Cypress have a schedule to release a new version of PDL to fix emEeprom's bugs?

Complier:ARM GCC 5.4    PDL:3.1.0 

0 Likes
AaHo_4159591
Level 1
Level 1

We have a similar problem where writes *sometimes* fail with CY_FLASH_DRV_IPC_BUSY. Some boards fail more often than others. This is with PSoC6 with BLE and EEPROM access on  CM0.

0 Likes