We are using DFU to allow the application on our boards to be updated (app0 is the bootloader, app1 is our target application). Once DFU is integrated into an app, how do you go about debugging it within MTB2.3?
We've some up with 2 methods, but both are a little kludgy:
1) Rebuild the application as a non-DFU app by modifying the Makefile. Then debug as normal. That works okay for debugging, but it wipes out the bootloader/app0. After debugging, developers have to use the MiniProg4 to reprogram any boards used for debugging with the bootloader and the CRC-signed application. If one of our boards makes it out "into the wild" after a debug session without the bootloader, we have a problem because it can't be updated via DFU until it is reprogrammed using MiniProg4. The bottom line here is that we want all boards used for development to keep the bootloader in place.
2) Put a jumper on the board tied to a GPIO that tells the DFU bootloader/app0 to ignore the fact that app1 doesn't have a valid CRC. The hex file for app1 that is generated by the build process doesn't include a CRC, so we have to tell the bootloader to ignore a CRC mismatch when validating app1. In this way we are able to leave the bootloader in place and only update the application for debugging. Still, this is a bit kludgy and requires a GPIO to be allocated for the jumper. We don't want developers to accidently leave the jumper in the wrong position or accidently leave a non-CRC version of app1 programmed.
3) Find a way to debug CRC-signed hex files. To me this would be ideal, bit I'm having trouble manipulating the hex and elf files to make this possible. I made another post about this issue.
So, back to the main question, what is the best way to debug DFU-loaded applications? 🙂
Hi @JoLl_4741886 ,
Basically how we debug the DFU application is,
1.First we will bootload the application.
2.In App1 write this piece of code
3.Program the device.
4.Go to Run->Debug Configurations->Attach to target->Debug
6.Cursor will stop at the while loop.
7.Change the value of temp=1 and again resume and start to debug line by line.
Please let us know if this works.
Thank you for your reply. When we start a debug session, the bootloader/app0 runs first. We are not able to get past the bootloader because the call to Cy_Bootload_ValidateApp() fails. The problem is that when the debugger programs app1 into the flash, there is no CRC included.
If we modify the bootloader to ignore the status from Cy_Bootload_ValidateApp(), then we can start the debug session and the debugger breaks at main() in app1, so no while() loop is needed. But our goal is to have a fully-functional bootloader programmed at all times on all of our boards. We don't want to modify the bootloader when doing development/debugging.
So, I still have 2 questions:
- How do developers usually get around the fact the bootloader/app0 will fail to execute app1 if there is no CRC in app1?
- Why are we seeing the debugger break at main() of app1 when others need to use the while() loop you suggested? I'm not complaining about the behavior we are seeing -- it makes debugging much more convenient. I'm just curious why the debugger is working differently for us.
Thanks again for your help.
[Edit] We have come up with a possible solution to the CRC problem. To me it is a bit kludgy and I still want to understand what other devs are doing to work around the fact the the bootloader fails without a valid CRC.
Bump. I am still looking for the answer to this question:
When debugging a DFU application, how do developers usually get around the fact the bootloader/app0 will fail to execute app1 if there is no CRC in app1? The CRC is only created when generating the cyacd2 file.
Any help is appreciated.
Did you ever find a solution to this? I am facing the same problem. My app1 runs just fine without the app0 as a standalone app, but crashes when running as a a dfu app.
From your description, I'm not sure our issues are the same. My issue was I couldn't debug app1 in MTB because I couldn't get past the bootloader. That sounds different than "it [app1] crashes when when running as a dfu app" that you describe.
I worked around my problem by adding a toggle switch on the board that the bootloader can read through a GPIO. One position of the switch is labelled "Normal" (GPIO shorted to ground) and the other is "Maint" (GPIO pulled high). When the switch is "Normal", the bootloader performs the CRC check normally. When the switch is in "Maint" position, the bootloader skips the CRC check and just jumps into App1. So, when we are debugging App1, we put the switch in "Maint" position. Then we can debug App1 without messing with build files or CRCs.
The problem with the workaround that if we accidently leave the switch in "Maint" position on a production board, then there will never be a CRC check in the field. We have to make sure the switch is set to "Normal" after every debug session.
This is the kludgy workaround I chose because I wasn't getting answers. I'm sure there are better solutions that would work.