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]

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