Major IAR Embedded Issues

[webzoid]

So literally, I cannot trust what IAR is doing. Running version 8.22.1, it crashes every time I attempt to debug an nRF52832 device (SparkFun board).

I've already programmed in the S132 softdevice as part of the nRF5 SDK and then while attempting to load the Blinky App, things just end up going wrong.

Trying to put a simple piece of code in which waits for a button press before advertising just doesn't work - how do I know IAR is actually programming the device? It tells me it is but even the most basic code to detect a button press is not working. I know that the pins are mapped correctly (the BLE service tells me via a notify when the button is pressed).

This is so frustrating. What are the viable other options other than using IAR? 

[webzoid]

I’ve since attempted to flash the Blinky App (S132) onto a SparkFun nRF52832 breakout board. After single-stepping successful, approximately 4 seconds after allowing the application to run, I then get a “Failed to read CPU status after 4 attempts” error yet the application is still running on the board.

Going backwards to SDK 14 has the same issues.

As much as it pains me to say, the Arduino code runs perfectly on the board!

[Edvin]

Hello,

I haven't tested IAR too much, so I can't say I am familiar with any known issues. But if you are asking for alternatives, there are the obvious ones that you see in the SDK. We have Keil, Segger Embedded Studio (SES) and using a standalone gcc compiler and a makefile.

 

SES is free for Nordic Semiconductor users, as you can see here, so if you are interrested, you can try it out (no fees, and no limitations in code size or time limit). See this video on how to set it up.

Best regards,

Edvin

[webzoid]

Hi, thanks for your response. The most important thing for me at the moment is a working, reliable debugging mechanism so I can single step however, IAR just isn't allowing this. If I knew that my code-base was working then I'd definitely turn to a makefile-based platform.

[Edvin]

That being said, it is not certain that this is the problem. Again, I haven't experimented too much with IAR, but stepping through a project that is using the SoftDevice is not that easy, as the SoftDevice will miss some time critical events after starting advertising, or while in a connection, which will cause some asserts. However, it shouldn't crash the IDE. 

 

But feel free to try out SES if you are not satisfied with IAR.

 

Best regards,

Edvin

[jev]

We use a slightly older version (8.11.2 to be exact) and whilst the IAR debugger isn't the most advanced in the world it certainly allows you to step through your code.

Did you switch off interrupts during stepping? If not, try that first. Assuming you use a segger J-Link, go to the J-Link menu in the IDE and make sure "Disable interrupts when stepping" is ticked.

On-chip debugging code in any system that uses a live environment and requires hard realtime behavior is tricky. The environment doesn't stop producing data for example when the CPU hits a breakpoint or when you step through your code.

Other toolchains will suffer from the same issues. We use a mix from IAR's build-in debugger and SEGGER's oZone. Sometimes IAR performs better, in other situations oZone is the tool for the job. Again, provided you use a J-Link, give oZone a try (however, be aware that oZone requires some tinkering with scripts to make sure it initializes the softdevice correctly).