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
- 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:
- The CM0 application is also fine, I can debug it. Here is the output:
- 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.
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.
The function argument value 0x10030000 is valid, as you can see in the screenshot from the debug session.
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:
#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
After changing applications sizes in shared_config.mk so that CM4 starts from address 0x10040000
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
Regards,
PZbb
Dear @Pushyanth_K
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:
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:
Debugger lands in the line:
In another debug session I inserted breakpoint before the problematic line:
There is a problem to read semaStruct , which can also be seen in the OpenOCD output:
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
Here is where this address comes from:
According to my shared_config.mk
- 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:
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.
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
