This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Example code utilizing softdevice will not work properly with IAR compiled hex

Hello,

I have an issue regarding using IAR tools with the examples provided in SDK v13.

I have:

Issue:

  • Followed tutorial provided by you guys on using IAR and provided examples from the SDK (devzone.nordicsemi.com/.../)

  • Used the HRM example from v13 of SDK and for board PCA10056

  • After starting debug session in IAR, I am unable to find the device. (Note that I have hit the play button so I'm not stuck at main).

What I've done:

  • I have a simple phone app that ID's advertising devices and counts bytes of data passed once a connection is established

  • When I flash the provided hex files from the SDK using nRFgo Studio I can see the device and talk to it

  • When I flash the device from within KEIL I can see and talk to the device (after programming the softdevice hex using nRFgo Studio)

  • When I flash the device from within Eclipse I can see and talk to the device (after programming the softdevice hex using nRFgo Studio)

  • Looking at the map files for IAR/KEIL I dont see any significant differences with start/stop locations for RAM/ROM (but I may have missed something).

  • Confirmed that downloading a non-softdevice example works. I debugged with blinky and had no issues. So to me at least this narrows down to softdevice specific problem on the nRF52840 PDK.

I am at a total loss here. Seems like I am missing something simple since at some point you guys at Nordic must have gotten this working as your provide the .eww and .ewp files for the example in IAR.

Please help.... Otherwise I am going to have to go to IAR with this and I dont think that will prove too helpful since they didnt write the application.

Thanks in advance for any help/pointers

UPDATE: Flashing the compiled hex file built by IAR (from within IAR, or from another utility like nRFgo Studio) does not work either. AKA it is not debugger specific

Parents
  • Admittedly I am no ARM instruction set or compiler expert, but there is a problem with the way the latest IAR toolset is dealing with the asm code block in nrf_delay.h -> nrf_delay_us() function call.

    We are currently working with IAR and you guys to resolve this.

    One work around is to add/edit these two lines to the nrf_delay.h -> nrf_delay_us function:

    • "SUBS %0, %0, #1\n" --> Replace %0 with %1 in both locations

    • add this to the input operand list: [number_of_us] "r" (number_of_us),

    This will break the loop I was stuck in. However this does not guarantee that the rest of the project is 'safe' since there may be other asm volatile sections (I havent looked yet) that are not acting as expected. Sigurd is correct, reverting to v7.20.2 did aslo fix the problem.

    I will update this blog when I/we find out more.

Reply
  • Admittedly I am no ARM instruction set or compiler expert, but there is a problem with the way the latest IAR toolset is dealing with the asm code block in nrf_delay.h -> nrf_delay_us() function call.

    We are currently working with IAR and you guys to resolve this.

    One work around is to add/edit these two lines to the nrf_delay.h -> nrf_delay_us function:

    • "SUBS %0, %0, #1\n" --> Replace %0 with %1 in both locations

    • add this to the input operand list: [number_of_us] "r" (number_of_us),

    This will break the loop I was stuck in. However this does not guarantee that the rest of the project is 'safe' since there may be other asm volatile sections (I havent looked yet) that are not acting as expected. Sigurd is correct, reverting to v7.20.2 did aslo fix the problem.

    I will update this blog when I/we find out more.

Children
No Data
Related