Problems Debugging with IAR EWARM

[cam2]

Posted on September 29, 2008 at 19:14

Problems Debugging with IAR EWARM

[cam2]

Posted on May 17, 2011 at 12:42

Hi all,

I have be using the Codesourcey tools for my development, but once in a while I build my code with the kickstart version of the IAR EWARM in order to use the J-link debugger to test a certain feature. My code builds with both the IAR compiler and GCC with no warnings and runs fine when it is loaded via the bootloader. The problem arises when I try and debug within EWARM. The code downloads and verifies via the J-Link with no warnings but it does not get to main, it just hangs and if I click the break button the code seems to be stuck in the __iar_data_init2 assembly routine. If I try and reset via the reset button in the EWARM I get a message that indicates the CPU is not halted. After this EWARM usually crashes or the debugger exits. This happens about half the time, the other half of the time I can debug normally with no problems. I am using the Olimex STM32-P103 dev board with a STM32F103 part that is rev Z. Thanks

[jj]

Posted on May 17, 2011 at 12:42

I have the ''H'' version of your board and recently loaded IAR V 5.2 and the most recent version of Segger ''J-Link ARM Ver 3.90.'' There is an STM patch for IAR V. 5.1 - ST ONE has alerted. (believe this patch is embedded w/in V 5.2.)

If you need a few more pins I recommend you shift from JTAG to SWD - saving 2-3 pins for your ap. If you have an older ver of IAR you will have to review your .H and .inc files as their format has changed. I believe that a fresh start with V 5.2 (using its example files) will be the simplest way for you to get going quickly/easily. Good luck...

[cam2]

Posted on May 17, 2011 at 12:42

Thanks JJ.

I already have the latest versions of IAR and the Segger J-Link software. My project includes an RTOS and other third party libraries and does not use any of the standard IAR include or header files. It does however make use of the IAR C library and I think this is were the problem lies. I have commented out the sections of code that use the library functions (I think it might be something to do with memset??) and debugging seems to be working fine. I would appreciate any other theories as to what __iar_data_init2 does and what could cause it to hang... Thanks

[16-32micros]

Posted on May 17, 2011 at 12:42

Hi cam.christie,

Just a hint to refer to this technical note

http://www.st.com/stonline/products/literature/tn/14898.pdf

Regards, STOne-32.

[jj]

Posted on May 17, 2011 at 12:42

STOne-32,

Thank you for the ''hint.'' TN0067 says, ''ST offers a free replacement with the latest IAR starter kit and ST evaluation board.'' Rev B or Z will be replaced with Rev Y of the medium density STM32. We have SIX such starter kits/eval bds - ALL have (of course) the B/Z Rev. (Read the errata doc to discover the location of the Rev marking [usually bottom right]) So we called local ST office - dispatched instantly to NOT ST but Rep/Sales Office (who knew??? - and they of course knew NOTHING! Upgrading to IAR 5.20 solved several of our earlier issues - and has had the unintended consequence of now causing our system to fail like cam's...

[jwormsley2]

Posted on May 17, 2011 at 12:42

I'm having this problem too. I have no idea what triggered it. I was using the latest FWLIB example for the RTC (the calendar app) and it compiled and ran fine, I made a few mods, still worked, made a few more mods, now it hangs in the same place as the OP. Reversing the last set of mods gets me back to where I was, but nothing about that set of mods, that I can see, should have caused this issue. What I did was extend the user interface to ask for year/month/day in addition to hour/minute/second, and put that into a struct tm time structure for mktime to convert to a 32 bit number to then put into the RTC, and remove the reset to 0 at 23:59:59 from the interrupt routine. Unless forcing the include of code from ''time.h'' or ''stdlib.h'' causes the error, that is.

[ This message was edited by: jwormsley on 29-09-2008 22:17 ]

[jwormsley2]

Posted on May 17, 2011 at 12:42

As a further point of note, my expansion of the UI involved adding three more variables (Tmp_YY, Tmp_MO, Tmp_DD) and copy/pasting the same loops to set them. Doing this resulted in the lockup. I thought it might have been the initialization of the new variables to 0xFF, like the originals, that put it over the edge, but that wasn't the case. Commenting out the the three loops fixed it. Commenting out the first and second new loops did not, nor did commenting out only the first, but oddly enough, commenting out just the second did. Factoring out the three entry loops into one entry routine called with the prompt string and limit as parameters also fixed the issue.

Something in the code generator is amiss, but I can't easily spot what it could be. Perhaps these hints could give someone from ST or IAR the clues needed to fix this. I'm going to put in a support request to IAR about this as well.