nRF52832 GCC Issues

[josh]

Hello,

I'm trying to prototype an application on the nRf52 DK (PCA10040) using the GCC toolchain. I followed all of the tutorial for setting things up and I can build and flash things fine, but I don't think the application is working correctly.

I'm starting with the HID keyboard example as a baseline. I have not modified any of the source and it builds without errors. The application comes up, the light blinks, but my phone (galaxy S8) cannot see the device. I can occasionally see the device in nRF connect, but the advertisment frequency nRF connect shows does not jive with the configured advertising intervals of 25ms / 2 seconds in the example.

If I flash the board with the hex files provided with the examples everything works nicely. I'm guessing the examples were not built with GCC? I'm thinking this may be the problem may be with the tool chain. I, perhaps foolishly, grabbed the newest version of the GNU ARM (6 2017-q2-update). Are there any known issues with this version? Or is there an older version that is recommended?

I've tried SDK versions 12.3 and 14.2, with the same results

Thanks, Josh

Edit 1: Here is the hex file I referenced in the comment below, couldn't attach to a comment for some reason. Hex file

[Matt]

Weird indeed. Did you observe any funky compiler warnings from the armgcc? I believe the precompiled hex includes the softdevice already so when you flash in your own armgcc compiled bin do you flash in the softdevice first (the one that comes with the sdk12)? Do you use nRF cmd line utilities or the nRFgo studio to flash in the softdevice and your bin file?

[josh]

After a lot of trial and error last night I finally got things to work, and was able to zero in on the issue, but would like some help help understanding it.

It all comes down to how I do the programming, as you suggested Matt, I've tried a lot of different ways to program the application, soft device (S132 v3 that was bundled with SKD 12.3), and combined hex files containing both. What eventually worked was programming the combined hex file with the command line tools (nrfjprog).

If I command a --sectorerase the flashing goes fine but the application does not behave correctly, if I combine my application hex file and soft device and program them with a --chiperase things work perfectly. I also did some experimenting with programming the precompiled example (via nrfjprog), same behavior, --chiperase fails to pair, --sectorerase works. When I was originally troubleshooting I was programming my compiled hex files via the make file, which commands --sectorerase, and I was dropping the combined precompiled hex file into the USB mass storage device for the devboard and letting it do the programming. I'm guessing that the USB mass storage programming results in a chip erase, because things always seemed to work when I programmed the precompiled examples this way.

Any thoughts on what could be causing this? Seems like a problem with the programming tool?

[Hung Bui]

Hi Josh,

Could you provide a hex file you compile using one of our example that has the issue you are seeing (the issue with --sectorerase) so we can test here.

I attached here a hex file that I used gcc to compile ble_app_hrs SDK v14.2. Could you try to test ?

nrf52832_xxaa.hex

[josh]

@Hung Bui, I tried the hex file you provided, same behaivor a described in my previous post, --chiperase works, --sectorerase results in an application my phone can see but pairing is rejected. I merged the hex file you provided with SoftDevice 132 v5.0.0 before programming.

With this in mind, I think I'm pretty comfortable assuming it's not my build environemnt / GCC setup that is the issue, that said I've attached a hex file form the SDK 14.2 HRS example that I built with this GCC setup:

GNU_INSTALL_ROOT := D:/GNU_Arm/5_4_2016_q3/bin/
GNU_VERSION := 6.3.1

See Edit 1 in original post for link to file.

[Hung Bui]

Hi Josh,

Did you do bonding ? If you do bonding and then if you erase bond on the phone, the phone won't be able to connect to your device because the bond information is still on the device.

How did you test ? Please try to use only nRFConnect to test, don't use the phone Bluetooth setting as it will request pairing.

When you do chiperase, the bond information is erased as well so you connect normally.

I suggest you to check with debugger to see if the device assert any problem when you flash with sectorerase.