Infineon recommended debugging solution for DFU Application

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

cross mob
John_K
Level 4
Level 4
25 replies posted 10 questions asked First like received

Is there a recommended procedure  from Infineon for Debugging a  PSOC6 DFU application in Modus Toolbox?

In the case of Psoc Creator and PSOC4, the usual routine ()although not entirely graceful) was to manually disable the 'Bootloadable Component'.

I see another user posted this question, noting the issues around the CRC Validation steps failing when in debug mode, and a kludgey workaround to manually edit the binaries,  but there wasn't much of a response:

 

https://community.infineon.com/t5/ModusToolbox-General/How-to-debug-an-app-that-is-normally-loaded-w... 

 

This seems to be a common enough scenario to warrant some tool, procedure,  or configuration hooks from Infineon to allow for DFU debug in applications that have a bootloader (aka App0).

0 Likes
1 Solution

@John_K assuming you meant debugging app1, not app0 the loader, my workaround is to link the only the Release config for DFU. Then your IDE debug links work they way they used to, and you don't even have the loader onboard.  Put this condition in the makefile for app1:

 

ifeq ($(shell tr '[:lower:]' '[:upper:]' <<< $(CONFIG)), RELEASE)
# Path to the linker script to use (if empty, use the default linker script).
LINKER_SCRIPT=dfu_cm4_app1.ld

# Custom pre-build commands to run.
PREBUILD=

# Custom post-build commands to run.
POSTBUILD="$(CY_MCUELFTOOL_DIR)/bin/cymcuelftool.exe" --sign $(CY_CONFIG_DIR)/$(APPNAME).elf CRC --output $(APPNAME)_crc.elf && \
"$(CY_MCUELFTOOL_DIR)/bin/cymcuelftool.exe" -P $(APPNAME)_crc.elf --output $(APPNAME)_crc.cyacd2
else
LINKER_SCRIPT=
PREBUILD=
POSTBUILD=
endif
$(info Linker Script: $(LINKER_SCRIPT))

 

View solution in original post

0 Likes
3 Replies
Alakananda_BG
Moderator
Moderator
Moderator
50 likes received 250 sign-ins 250 replies posted

Hi,

There might be few RESETs involved while debugging the DFU application.
For ex: device resets on successful downlaod and validation of image.
One recommendation would be to comment Cy_DFU_OnResetApp0(); API in main.c file and then debug
It will help your debugger to stay connected to the device.
However, customer/developer should be aware that  commenting out this will change the behavior of his application slightly (on startup only) . Please refer the function for more details.
There are no official recommendations for debugging a DFU application.
 
Regards
Alakananda
0 Likes

@John_K assuming you meant debugging app1, not app0 the loader, my workaround is to link the only the Release config for DFU. Then your IDE debug links work they way they used to, and you don't even have the loader onboard.  Put this condition in the makefile for app1:

 

ifeq ($(shell tr '[:lower:]' '[:upper:]' <<< $(CONFIG)), RELEASE)
# Path to the linker script to use (if empty, use the default linker script).
LINKER_SCRIPT=dfu_cm4_app1.ld

# Custom pre-build commands to run.
PREBUILD=

# Custom post-build commands to run.
POSTBUILD="$(CY_MCUELFTOOL_DIR)/bin/cymcuelftool.exe" --sign $(CY_CONFIG_DIR)/$(APPNAME).elf CRC --output $(APPNAME)_crc.elf && \
"$(CY_MCUELFTOOL_DIR)/bin/cymcuelftool.exe" -P $(APPNAME)_crc.elf --output $(APPNAME)_crc.cyacd2
else
LINKER_SCRIPT=
PREBUILD=
POSTBUILD=
endif
$(info Linker Script: $(LINKER_SCRIPT))

 

0 Likes

@Panometric ,

Yes, I did mean debugging App1.

I like your approach very much and that looks pretty clean. 

Infineon,

I think you should review and add something like this to the basic dfu upgrade sample projects (along with the sdk documentation). This should be a very common thing that customers will want  (ability to debug a DFU application in this environment).

0 Likes