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

nRF52832 bootloader is not working?

Hello Sir,

We developed one application in that we use WiFi and interface this to nRf52832 chip using UART. The WiFi Ch_PD(Chip enable Power down = GND for low power consumption if CH_PD = 1 it working condition). In my application i have also implement secure DFU and able to sent zip file to device. but problem is when i control this WiFi CH_PD pin through nordic GPIO with bot loader flash my WiFi is not working it continuously reset. And if i upload only flash device S132 and Application into nRF52832 it is working well and also controlled CH_PD via Nordic GPIO. But only problem comes when i upload bootloader my uploading sequence is first Softdevice --> Bootloader -->using NRF go studio then .zip file using BLE Nordic toolbox. Please tell me what i am going wrong is it need to change bootloader program. In my application i am also use WDT for wake my device every 1 Hr. Is it any problem for bootloder if i use wdt in application. Why my application is not working only when i use bootloder for OTA flasing.

Thanks in Advanced......... 

  • Hi Vishal,

    when i control this WiFi CH_PD pin through nordic GPIO with bot loader flash my WiFi is not working it continuously reset

    When running the bootloader the application is not running at all. When the device switch between the application and bootloader all peripherals are being reset (except the watchdog, more about that later). You will have to include all the code to set the WiFi Ch_PD GPIO pin as intended by your design. The continuous reset may be because of some problem with the configuration of this GPIO in the bootloader. If you do not use the WiFi during bootloader operation you may want to simply keep the WiFi in a disabled state while the device is being updated.

    In my application i am also use WDT for wake my device every 1 Hr. Is it any problem for bootloder if i use wdt in application.

    Sounds like quite a long Watchdog timer, but if it's actually a full hour you shouldn't need to do anything related to the watchdog in the bootloader. When you start the watchdog in the application it can not be shut down later on. You have to use the watchdog in both the bootloader and the application, but with a long enough timeout, you can ignore it in the bootloader. 

    Why my application is not working only when i use bootloder for OTA flasing.

    When you perform the DFU update does it end with a message saying that the update was successful? As I understood you flashed the SoftDevice and bootloader though nrfjprog/nrf Go studio/some other debugger interface and then performed an application DFU to get the application into the system. You have to verify that the application update was successful and that the bootloader is able to find and verify it.

    What sort of symptoms are you seeing which indicate that the application doesn't work? Is the application present and never starter, started and then crash or does it work in an incorrect way?

    Best regards,
    Rune Holmgren

  • Thanks for great explanation,

    but now is working by changing GPIO pin of nordic p0.12 to p0.16. if i use p0.16 pin for EN/Des WiFi is should great work.

    but i am not understand what happen on pin p0.16.  

  • Sorry, but I do not understand the question. p0.16 can be used for general I/O, but be aware that on the nRF52832 development kit this pin is used for one of the buttons.

    Best regards,
    Rune Holmgren

  • Ya write, I am saying when i use other pin on my custom board which p0.16 instead of p0.12 then WiFi application and able to switch boot loader mode is work. 

    Other question is if i use P0.16 pin on nRF52832 DK board and it is High Low in program anything problem or wrong. Because this pin have already connected with switch.

    Thanks.....

  • Thank you for the clarification.

    In the same way as p0.16, p0.12 is also available as a general I/O pin. Either pin should be available for general use.

    The only reason I can think of which can explain the difference is that you have either damaged one of the pins on the development kit or you have some code running which overwrites your configuration. The last can be checked by reading the registers related to the pins to see if the expected configurations are present. If you have something like the nRF5 SDK BSP present it's possible that pin0.16 is configured to being an input after you configured it to be an output.

    Best regards,
    Rune Holmgren

Related