Flashing the code to nRF52832 BLE module.

[PKANNAN]

Hi, I need some help on flashing the code to nRF52832 BLE module.
I would like to mention that I am flashing the code to nRF module using ST-link v2 debugger with the help of open-OCD tool.
Whenever, I flash the example hex file provided by nordic (i.e. ble_app_uart_pca10040_s112.hex file), it is flashed successfully and I could see "Nordic_UART" while scanning for BLE.
However, when I try to flash my custom nRF application, only on repetitive flashing I could see the BLE advertisement.
May I know why it occurs this way? i.e. only after flashing the same code multiple times, it's working?
Please help. Thanks in advance.

[Edvin]

Hello,

This is not really a debugger that we support, but it seems like you get it to almost work, if it is advertising. Did you remember to reset the nRF chip after you have programmed it? I don't know how you program it exactly, but you can try to power cycle the nRF52832 after it has been programmed.

Best regards,

Edvin

[PKANNAN]

Thank you very much for your response. 

I would like to mention that I'm resetting the nRF chip every time after programming it. 

May I know if there are any other solutions that would help? Thanks in advance!

[Edvin]

Perhaps you are not flashing the softdevice? I don't know what softdevice your application is using, but I guess it is either S132 or S112 (you should be able to tell from your project settings. If not, let me know what example your application started from).

Try flashing the softdevice before flashing your application. The softdevices are found in (depending on which one you are using):

SDK\components\softdevice\s132\hex\s132_nrf52_7.2.0_softdevice.hex

SDK\components\softdevice\s112\hex\s112_nrf52_7.2.0_softdevice.hex

(the softdevice version, which is 7.2.0 may differ from your case, depending on what SDK version you are using. These names are from SDK17.1.0).

Best regards,

Edvin

[PKANNAN]

Thank you for the response. 

Yes, I'm using S112 softdevice, and SDK17.1.0 only.  I'm using ble_app_uart example. 

As you suggested, I tried flashing the softdevice from SDK\components\softdevice\s112\hex\s112_nrf52_7.2.0_softdevice.hex and then flashed my application. But no changes were seen. It shows chip is programmed and target has been reset but BLE broadcasting is not seen.

[Edvin]

Did you do any modifications to the application (ble_app_uart)? How do you flash the .hex files? And where exactly do you find the .hex file for the application?

And you are sure that the flash is not erased between flashing the softdevice and the application? 

[PKANNAN]

Hi, thank you for your response.

Yes, modifications are made in ble_app_uart application. I am flashing the hex file to nRF52832 module using ST link v2 debugger with the help of open OCD tool. 

In nRF5SDK, I'm taking the hex file from the location: examples\ble_peripheral\ble_app_uart\pca10040\s112\ses\Output\Release\Exe

Edvin said:

And you are sure that the flash is not erased between flashing the softdevice and the application? 

I am not sure how to verify this, may I know how can I ensure that the flash is not erased?
Thank you!

[Edvin]

Sorry for the late reply. I was out of office last week. 

I am not familiar with the open OCD tool, but I guess you don't actively erase the chip between programming the softdevice and the application. 

Have you tried debugging the application? Is your main() function reached? Do you see any log output? I guess RTT Logging isn't supported over ST Link by default.

What UART pins is your application using? Are the UART pins connected to anything? If not, perhaps you can try to comment out uart_init() and see if the behavior changes. (The application may crash if the UART's RX pin is left floating). 

Please let me know if you have access to debugging and/or any logs.

BR,
Edvin

[PKANNAN]

Hi, no worries.

Thank you for your response!

Edvin said:

I am not familiar with the open OCD tool, but I guess you don't actively erase the chip between programming the softdevice and the application. 

Correct. I program the softdevice followed by application. I rarely do mass erase.

Edvin said:

I guess RTT Logging isn't supported over ST Link by default.

Yes, I am not able to debug/log using ST link.

Edvin said:

What UART pins is your application using? Are the UART pins connected to anything? If not, perhaps you can try to comment out uart_init() and see if the behavior changes. (The application may crash if the UART's RX pin is left floating). 

I am using UART pins 6(TX) and 8(RX). These UART pins are connected to the application chip (STM32MCU).

Edvin said:

Please let me know if you have access to debugging and/or any logs.

No, this is the challenge I'm facing using ST link debugger. I could only flash the code, not able to debug.

Thank you.

[Edvin]

Ok, you need to be able to debug to see why the application faults, or whether the application's main() function is reached at all. 

I guess one more thing you can try is to do is:

Since you need to program the application twice before it starts working. Try to program it only once, and read back the flash. I don't know how to do that with your programmer, but if you get hold of a JLink you can use nRF Command Line Tools and the command "nrfjprog --readcode my_flash_dump.hex" to read it back. Then we can use that to compare the flash after programming it only once, and after programming it twice. Are they identical?

Best regards,

Edvin