UBLOX-NINA-B1 (nRF52832) softdevice not working with IAR as assumed

[edablan]

I think this issue is related to what has been talked about here: https://github.com/ARMmbed/mbed-os/issues/5167

I have a UBLOX NINA-B1 (it uses the nRF52832 chipset). This micro is especially designed for people needing a supported BLE stack (nordic SDK). I have cloned the mbed-os-example-ble repo, and then chosen the BLE_HearRate. I clone the latest mbed-os (5.9.2) repo into this directory example, export to IAR (8.20.2.14838), and MTB_UBLOX_NINA_B1 target name using mbed cli (1.3.0). I can open the created workspace, build, and even go into debug mode. While I step through in the main function everything works, except when it is time to initialize the ble peripheral and thus enable and start the SoftDevice I end up getting a hardfault. I am debugging using an IAR I-JET. On futher inspection of the linker configuration file (.icf) it seems it is setup by default for no softdevice:

/* Default to no softdevice */ if (!isdefinedsymbol(MBED_APP_START)) { define symbol MBED_APP_START = 0x0; }

At the bottom of the .icf file this is written:

/*This is used for mbed applications build inside the Embedded workbench Applications build with the python scritps use a hex merge so need to merge it inside the linker. The linker can only use binary files so the hex merge is not possible through the linker. That is why a binary is used instead of a hex image for the embedded project. */ if(isdefinedsymbol(SOFT_DEVICE_BIN)) { place at address mem:__code_start_soft_device__ { section .noinit_softdevice }; }

However, the SOFT_DEVICE_BIN is not defined anywhere in the .icf file. I also can't find the softdevice binary file in any of the mbed-os directories specifically the S132. Obviously this can be downloaded, but not sure where to put the .bin file for it to do the merge.

Though no workarounds are mentioned, it seems anyone using the nordic nRF52x chips won't be able to actually use them with nordic SoftDevice running mbed and building in IAR currently? Any suggestions or workarounds would be great. At this point I'm dead in the water.

[X ] Question
[ ] Enhancement
[ ] Bug

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-1156

[0xc0170]

export to IAR (8.20.2.14838)

Please be aware IAR 7.x is currently supported

@ARMmbed/team-ublox @pan- Can you help with IAR debugging ?

@edablan Note, don't please remove headings from the template (description, issue type). We have tools that automatically parse these fields

[screamerbg]

@marcuschangarm Do you know whether the Nordic nRF52-DK (based on nRF52832) has issues with IAR?

[marcuschangarm]

@edablan

IAR should work with NRF52832 but from your description it sounds like the SoftDevice is missing. If you use the command line tool we'll merge the SoftDevice automatically but if you use the IDE you'll have to add the SoftDevice manually.

Regarding the comment in the linker script, I don't know what the original intention was with that piece of logic and since I'm not sure what it does I didn't remove it.

Coincidentally, there is a bug with NRF52840 and IAR but that should be solved here: https://github.com/ARMmbed/mbed-os/pull/7486

[marcuschangarm]

@theotherjimmy

Does mbed_app_start work when you use the exporter? If you export a project with a bootloader defined will the tools still setup the correct mbed_app_start address?

[theotherjimmy]

@marcuschangarm The tools should be including the linker defines, but they can't make the IDE do the merge process.

[edablan]

So I'm a little confused because the .icf by default puts the mbed_app_start at 0 (assumes no soft device) Though it seems the soft device would start at 0 if it were flashed. So wouldn't I end up writing over the soft device when it came time to flash (or debug) my application using the IDE? So is the work around for me to manually flash the soft device using nRFgo studio, then editing the .icf to make the mbed_app_start begin at 0x23000? According to the nRFgo studio software firmware application starts at 0x23000. This is where I got that specific address.

[theotherjimmy]

@edablan Your project settings should include a non-default value for mbed_app_start. If they don't then that's a bug.

[edablan]

@theotherjimmy

Yes the linker tab has this set to 0x23000. Though I just tried manually writing the soft device using nRFgo studio, and then flashing the u-blox in debug mode in IAR. Still getting hard faults. This is still from the exported mbed-os-example-ble. So I have not changed any code.

[theotherjimmy]

@edablan You may want to verify that the IAR flasher settings don't erase the whole chip.

[edablan]

As far as I can tell IAR is not erasing the whole chip when I flash to debug. I have checked this by flashing to debug, then using nRFgo studio to read back out the contents of where the soft device should be in flash and then comparing that to the s132 .bin file. It passes this verification check in nRFgo studio.

Right now I am using a UBLOX-NINA-B1 on a protoboard, but was able to talk to it using the U-BLOX provided firmware (ublox connectivity software) so I know the chip is capable of running a firmware application and communicating over UART. I will try it on a EVK-NINA-B1 board to see what happens

[edablan]

@theotherjimmy

So I verified the same behavior by exporting and testing on an EVK-NINA-B1 board. To debug I used the built in USB J-Link emulator that comes stock with the EVK-NINA-B1. I used a clean clone of the mbed-os-example-ble repo, and verified the softdevice was left in flash after entering debug mode. I used the description in the above comment to verify the softdevice was left intact after entering debug mode and not being erased. The soft device version is 5.0 which is the version found in the mbed_config.h file. Should this be escalated as a bug?

[edablan]

Also, to test another angle I compiled using the med cli (mbed compile -t IAR -m UBLOX_EVK_NINA_B1), and then programming the final image using nRFgo studio. The device does not advertise the heart rate example (advertising name HRM). So it looks like the ble stack is not running.

[theotherjimmy]

AH!

export to IAR (8.20.2.14838)

We support 7.80 on export and compile. This may be your problem.

[edablan]

@theotherjimmy

I just exported using version 7.80.4, and still seeing the same behavior. Attempted using both built in J-LINK emulator, and using an external J-LINK debugger. I also compiled the BLE_HEARTRATE example using the mbed-cli and then programming the final .hex file with the soft device merged, and I cannot see it advertising.

[theotherjimmy]

Thanks for giving it a go @edablan. Does the application get stuck somewhere? does @marcuschangarm have any ideas on how we could debug this?

[marcuschangarm]

I went back and took another look at the linker script and there is a bug in the memory allocation. Can you try this PR and see if it works please? https://github.com/ARMmbed/mbed-os/pull/7533

[edablan]

@marcuschangarm

Yes the BLE_HeartRate example now runs and advertises. However, when it tries to connect from an iOS, Android, or Windows device it does not connect. I guess this is out of the scope from the original issue. Do you want me to close this issue since it fixes the hard fault issues occurring on the BLE stack, and create a new one under the mbed-os-example-ble repo?

[marcuschangarm]

Yes, please. But open the issue on mbed-os.