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? 

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

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

[webzoid]

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.

[Edvin]

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)

 

 ppi-simple-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