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

PSoC™ 6 Forum Discussions

PZbb
Level 2
Level 2
10 replies posted First solution authored 5 sign-ins

 

Hello,

I am trying to run a security app using custom BSP for CY8C6247FTI-D52.

Using ModusToolbox 2.4.1 I:

  • downloaded the example https://github.com/Infineon/mtb-example-psoc6-security for CY8CPROTO-062-4343
  • changed the target to PSOC6-GENERIC
  • added my custom BSP (make bsp TARGET_GEN=myBSP DEVICE_GEN=CY8C6247FTI-D52)
  • changed the target in Makefile for all applications (bootloader, cm0, cm4)
  • created a configuration in Device Configurator for all applications
  • modified shared config linker scripts
    PZbb_1-1669880219189.png
  • I have compiled the bootloader, it detects the absence of the application or its correct digital signature after uploading to the FLASH memory with the programmer. There are no problems with it. Below is the output from the compilation:
    PZbb_2-1669826342090.png
  • The CM0 application is also fine, I can debug it. Here is the output:
    PZbb_4-1669826441106.png
  • The CM4 application compiles without problems, but I can't debug it and I can't see any output from it, eg changing the GPIO state.
    PZbb_5-1669826464121.png

The CM4 application doesn't even enter the assembly code in startup_psoc6_01_cm4.S . I checked this by defining the Cy_OnResetUser function, which should be called first from the startup level before initializing the BSS, clocks, calling main(), etc.

I checked it for bootloader and CM0 application where I successfully jump into this function. But for CM4 I don't see such a result. This makes me believe that for some reason CM4 is starting from the wrong place in memory or not starting at all.

There is a Cy_SysEnableCM4 call in the CM0 application that should start CM4 from the appropriate FLASH location.

PZbb_6-1669826569461.png

The function argument value 0x10030000 is valid, as you can see in the screenshot from the debug session.

PZbb_7-1669826599738.png

The problem occurs when a value 0x5fa0003 is assigned to the CM4_PWR_CTL register, which results in a HardFault of the CM4 core, and there is nothing to fail in this application because in Cy_OnResetUser there is an infinite loop for(;;){}

According to the documentation https://www.infineon.com/dgdl/Infineon-PSoC_6_MCU_PSoC_62_Register_Technical_Reference_Manual-Additi... 4.1.12 value stands for enabling the CM4 and setting VECTKEYSTAT.

Further hours of debugging led me to a bootloader with the following code:

PZbb_8-1669826687082.png

#if is omitted on CY8CPROTO-062-4343W but on my CY8C6247FTI-D52 Cy_SysDisableCM4 is called and I believe this is the real source of my problems. I know that for my CY8C6xx7 the CM4 starts after a reset, hence the manual shutdown for the purpose of copying FLASH in the bootloader. There must be some problem between disabling and enabling the CM4 core.

Could you point out where I should look for a solution to the problem? Maybe it's something related to LDO configuration, clocks, CPU sleep, etc.

In the PDL documentation https://infineon.github.io/psoc6pdl/pdl_api_reference_manual/html/group__group__syspm.html I see that there are a lot of mentions on this topic for CY8C6xx7. I am using PDL 2.4.1 https://github.com/cypresssemiconductorco/mtb-pdl-cat1#release-v2.4.1 

Best regards,
PZbb

0 Likes
1 Solution
PZbb
Level 2
Level 2
10 replies posted First solution authored 5 sign-ins

Hello @Pushyanth 

Just to be sure, I re-created the project and only made the most important changes. Zipped project in the attachment. I recommend just writing something into FLASH before DFU process, the error is exactly the same.

I found that just changing the value from 1 to 0 on line 83 https://github.com/Infineon/mtb-pdl-cat1/blob/master/devices/COMPONENT_CAT1A/source/cy_device.c#L83  everything works fine, including the EEPROM library. At the moment it allows me to continue with the real project, but it suits to find a better solution.

Let me mention that I'm not going to use writing to FLASH outside of CM4. Writing to EEPROM and DFU will never run in parallel in my project.

Thanks,
PZbb

View solution in original post

0 Likes
8 Replies
PZbb
Level 2
Level 2
10 replies posted First solution authored 5 sign-ins

After changing applications sizes in shared_config.mk so that CM4 starts from address 0x10040000

PZbb_2-1669886359645.png

and according to https://community.infineon.com/t5/Knowledge-Base-Articles/PSoC-6-MCU-Code-in-main-executes-before-th... adding some delayin main()
I am able to jump to and debug CM4 application

PZbb_1-1669886334606.png

Regards,
PZbb

0 Likes
Pushyanth
Moderator
Moderator
Moderator
50 sign-ins 5 solutions authored 10 replies posted

Hi @PZbb ,


The HardFault in this case is caused by the Invalid cm4 application start address, I've also succesfully reproduced the issue using CY8CPROTO-062-4343W. CY_CORTEX_M4_APPL_ADDR is set to CM4_APP_FLASH_START(this is defined in the shared_config.mk) in the cm0_app makefile. Make sure the memory regions in the make file are configured correctly according to the device.

Regards,
Pushyanth
0 Likes
PZbb
Level 2
Level 2
10 replies posted First solution authored 5 sign-ins

Hi @Pushyanth

I solved the problem just before your reply, but your answer convinced me that I was right.

Thank you,
PZbb

0 Likes
PZbb
Level 2
Level 2
10 replies posted First solution authored 5 sign-ins

Dear @Pushyanth 

I have another problem that corresponds to the topic.

While performing DFU, the initial communication passes and the DFU process proceeds until the FW is written to the FLASH memory.

I was able to get to the last place where there is no HardFault yet:

PZbb_0-1669984793003.png

PZbb_1-1669984833228.png

When jumping to the Cy_IPC_Sema_Status function using F5 in ModusToolbox, the debugging session is suspended. After stopping debugging, the function stack looks like this:

PZbb_2-1669984869893.png

Debugger lands in the line:

PZbb_3-1669985341998.png

In another debug session I inserted breakpoint before the problematic line:

PZbb_4-1669985864393.png

There is a problem to read semaStruct , which can also be seen in the OpenOCD output:

PZbb_5-1669985957555.png

In the PDL documentation https://infineon.github.io/psoc6pdl/pdl_api_reference_manual/html/group__group__flash.html I  see information about waiting 700us for CY8C6xx7. 

What can I do about this topic? I also checked if the EEPROM is working and I noticed literally the same problem after jumping into Cy_Flash_SendCmd.

I haven't noticed any higher priority interrupts than IPC 3 and 4 in the project.

Best regards,
PZbb

 

0 Likes
PZbb
Level 2
Level 2
10 replies posted First solution authored 5 sign-ins

Here is where this address comes from:

PZbb_0-1669995462761.png

According to my shared_config.mk 

PZbb_1-1669995753725.png

  • addresses from 0x8000000 to 0x8010000 should be reserved for CM0,
  • shared 0x8010000 - 0x8018000
  • CM4 0x8018000 - 0x8040000

For the CM0 and CM4 app builds, addresses do not correspond to the assumptions:

PZbb_3-1669996187750.png

 

 

0 Likes
PZbb
Level 2
Level 2
10 replies posted First solution authored 5 sign-ins

Dear @Pushyanth 

I debugged original EVAL code and noticed that a completely different section is executing based on a flashRwwRequired value.

In the line https://github.com/Infineon/mtb-pdl-cat1/blob/master/drivers/source/cy_flash.c#L372 
there is an if statement differentiating my MCU and CY8C624ABZI-S2D44 from EVAL.

In the configuration file https://github.com/Infineon/mtb-pdl-cat1/blob/master/devices/COMPONENT_CAT1A/source/cy_device.c  I see that only MCUs with 1MB FLASH have 1 entered in this variable.

For testing purposes I modified flashRwwRequired value from 1 to 0 for cy_deviceIpBlockCfgPSoC6_02 and got exactly the same result related to semaStruct->maxSema. Only the address is slightly different, but also out of 0x8010000 - 0x8018000 range.

PZbb_0-1670230533549.png

Can I do something about it? I can't compare the code for my MCU with a working example because there isn't one for 1MB.

 

Also in the line 234 https://github.com/Infineon/mtb-example-psoc6-security/blob/master/shared/shared_config.mk#L234  in the original example there is a bug. I predict SRAM_OF_FLASH was supposed to be START_OF_SRAM, but that doesn't seem to be a problem in my case.

Best regards,
PZbb

0 Likes
Pushyanth
Moderator
Moderator
Moderator
50 sign-ins 5 solutions authored 10 replies posted

Hi @PZbb ,

Could you share the project, So that I can reproduce the issue and check what went wrong?

 

Thanks and Regards,

Pushyanth

0 Likes
PZbb
Level 2
Level 2
10 replies posted First solution authored 5 sign-ins

Hello @Pushyanth 

Just to be sure, I re-created the project and only made the most important changes. Zipped project in the attachment. I recommend just writing something into FLASH before DFU process, the error is exactly the same.

I found that just changing the value from 1 to 0 on line 83 https://github.com/Infineon/mtb-pdl-cat1/blob/master/devices/COMPONENT_CAT1A/source/cy_device.c#L83  everything works fine, including the EEPROM library. At the moment it allows me to continue with the real project, but it suits to find a better solution.

Let me mention that I'm not going to use writing to FLASH outside of CM4. Writing to EEPROM and DFU will never run in parallel in my project.

Thanks,
PZbb

0 Likes