The ADuCM4050 quickstart pushbutton example loads, build and runs in the debugger but it doesn't work for me. Pressing PB1 and/or PB2 has no effect. Has anyone else seen this? Thanks, Phil
Unfortunately, there is a known issue with ADuCM302x and ADuCM4050 software packs (DFP and BSP, revision 3.1.x and earlier revisions) that might result in some application examples working in debug mode but not in release mode.
Applications that use the 'DEBUG_MESSAGE' or 'DEBUG_RESULT' macros in their code, can hang because these macros map to the sprintf function that is supported via semi-hosting by default. Semi-hosting means, that the macros get executed only in debug mode. As a result, you might find some examples running in debug mode but not outside of debug mode (for example, when running in release mode).
A workaround for this issue exists, and comprises of modifying the common.h file that can be found in the Include directory of the device driver (DFP) installation (typical path in case of IAR as an example: 'C:\Users\<user-name>\AppData\Local\IAR Embedded Workbench\PackRepo\AnalogDevices\ADuCM4x50_DFP\3.1.1\Include\common.h'). The common.h file can also be modified within IAR workbench where it would be available under the '<project-name>\CMSIS-Pack\Device Examples Support' directory within the project hierarchy in the IAR source browser.
In the common.h file, modify the definitions of the DEBUG_MESSAGE and DEBUG_RESULT macros such that they don't map to sprintf function calls in case the NDEBUG macro is set. A modified common.h file is attached for reference.
The NDEBUG macro is set automatically when the 'Release' configuration is selected in the project workspace (see example IAR snapshot below where the 'Release Mode' is being selected). As a result of this workaround - the application example should now be able to run through completely, in release mode as well.
Note: With BSP revision 3.1.x and earlier revisions, there is an additional issue with the button_press example. In button_press.c, the application waits for a default number of core clock cycles, before exiting. As a result, even with the workaround above - while the application will run through completely in release mode, it would most likely exit too quickly for a user to experiment with pressing the buttons. To resolve this, modify the button_press.c file to comment out the default while() loop, and add a while(1) loop instead, that ensures that the user can freely experiment with the example in release mode for as long as required.
Thanks for the detailed reply and workaround. I am working with CCES 2.7 and the problems seem pretty severe. I commented out all the debug related message calls and built the code. And I modified the code for while(1) as you mentioned. It runs and I can use breakpoints. But pressing BTN1 causes the debugger to freeze. There are other issues with the debugger as well. The debugger pause operation does not work. It causes the debugger to freeze.The quick start guide is CCES specific. Do you work with CCES? Is there a quick start guide for IAR based development?
The MCU Cog development platforms for ADuCM3029 and ADuCM4050 are supported across multiple tool chains including CCES, IAR and Keil. You can find quick an IAR quick start guide for EV-COG-AD4050LZ at the link below:
EV-COG-AD4050LZ with IAR Embedded Workbench for ARM [Analog Devices Wiki]
Regarding the issues you experienced with CCES, please find some feedback below.
Hi Narsimh. I am not seeing a breakpoint issue. Pressing BTN1 or using cces debugger pause causes the debugger to freeze for the pushbutton example. Can you very? Thanks for your help. -Phil
Just pressing BTN1 should not have caused the debugger to freeze. I can verify this at my end. Could you please confirm the button you are using by reviewing the annotated Cog front-side image in the hardware user guide, available at the link below?
EV-COG-AD3029LZ MCU Cog [Analog Devices Wiki]
Regarding the pause button causing CCES 2.7.0 debugger to freeze, this is something I observe as well (and not specific to the particular project, example).. Kader.M or one of admins in the CrossCore Embedded Studio and Add-ins team should be able to forward to the right contact to help us on this issue.
btn1 and btn2 are closest to the board edge per the pcb and the guide. i guess it is fair to say pushing these does not cause the debugger to freeze. but if we set a breakpoint in the interrupt handler and push these buttons we see the code does not halt at the isr breakpoint. no leds toggle upon pushing these buttons. do your leds toggle when you push these buttons using the cces 2.7 debugger?
ps: i am typing with one hand due to injury .. that is why you see no capital letters
You report two issues related to pressing the buttons:
I'm not exceeding the breakpoint limit. Pushing either button 1 or 2 does not cause any change in LEDs. I've worked extensively with our M4 based CM408F and do not recall issues such as these. But I was working with IAR tools at that time ( a few years ago). With the CCES 2.7 PAUSE functionality not working as you confirmed, I don't have a lot of confidence in the setup. I'll wait to hear back regarding the pause issue. Thanks for your help.
I have informed about your query to our colleagues in IOT team. They will get back to you
Thanks Kader. I will stay tuned.
> CCES 2.7 PAUSE functionality not working as you confirmed
I am able to reproduce the problem. Sadly, it looks like a problem introduced into the Eclipse C/C++ Development Tooling (CDT) 509788 – Cannot pause/stop session of "C/C++ GDB Hardware Debugging" that CrossCore Embedded Studio uses. The problem affects CCES 2.7.0.
CCES 2.8.0, however, is due to be released in the next week or two and testing shows that the problem does not exist. We are double-confirming. CCES 2.8.0 is based on Eclipse Oxygen and the latest CDT.
Apologies for the inconvenience caused.
Retrieving data ...