Major IAR Embedded Issues

RE: Major IAR Embedded Issues

Edvin — Fri, 22 Jun 2018 08:58:36 GMT

I am not sure exactly why IAR is crashing all the time. Do you see this behavior only on one computer, or have you tested on several different?

On the clock part.

The HFXtal has to be turned on in the application. The chip uses the RC oscillator until this is done. This can either be done manually, or by activating the SoftDevice.

If you use bsp_board_led_invert(), this will not toggle the pin on every clock cycle, so what you are seeing is not unexpected. If you want accurate toggling on that frequency, I would suggest that you use the PPI together with GPIOTE.

Attached is a project that does this. It starts the hfclk, and initializes a PPI channel to toggle a pin on a timer compare event. The project is not much to debug, as the main loop does nothing, but you can use this to check that the HFXTAL is running.

Note that the attached project only has the Keil IDE (I'm sorry). But the main.c file is the important file here. If you replace the main.c file in any of the peripheral examples with the main.c file from this one, it should compile. It only uses a handful of included .h-files. (no .c files)

devzone.nordicsemi.com/.../ppi_2D00_simple_2D00_toggle.zip

(written in SDK14.0.0, but It uses only nrf specific macros, so I think you should be able to run it on any SDK for the nRF52)

This project results in the pin toggling like this:

Best regards,

Edvin

RE: Major IAR Embedded Issues

webzoid — Thu, 21 Jun 2018 10:32:17 GMT

Hi jev, exactly - I've used older versions of IAR before without issue but the more recent ones crash left, right and centre.

So I have made some progress - I've taken the BLE Blinky example and stripped back the code to remove all bluetooth functions, just some simple LED toggling. This works and I no longer get the same type of IAR crashes which I used to with the Bluetooth enabled.

However, it does still crash.

As for interrupts being switched off, I'm using the SDK examples as they are (apart from minor tinkering as above) - I'm new to the SDK to I'm still figuring my way around and working out what is enabled and how things are actually enabled. Some times are still a mystery!

One thing I am a little puzzled about is the lack of external clock usage by the SDK. I have both a 32MHz crystal and a 32.768kHz crystal but neither of them generate any clock signals. My guess is that the internal RC is being used. If I do nothing more than toggle an LED in the main loop (using bsp_board_led_invert), I can see the frequency of the toggle is 400kHz - I would expect this to be up in the MHz range.

RE: Major IAR Embedded Issues

jev — Thu, 21 Jun 2018 10:21:12 GMT

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).

RE: Major IAR Embedded Issues

Edvin — Thu, 21 Jun 2018 07:47:20 GMT

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

RE: Major IAR Embedded Issues

webzoid — Thu, 21 Jun 2018 07:43:40 GMT

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.

RE: Major IAR Embedded Issues

Edvin — Thu, 21 Jun 2018 07:40:21 GMT

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

RE: Major IAR Embedded Issues

webzoid — Thu, 21 Jun 2018 06:48:15 GMT

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!