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

nRF51822 QFAA resets when connecting to it

As the title says, I'm having problems connecting to my device with my custom board and I don't know what else to do. This is my Layout:

image description

Whenever I upload my firmware to the nRF Kit it works perfectly, the chip is able to receive the data and it doesn't disconnect. The behaviour that I'm observing while trying to connect with my custom board (Malapascua) is the next:

image description

And this is with the nRF Kit:

image description

So the dBms are more or less the same but still, I don't understand why my custom board is sometimes reseting or not responding at all whenever a device tries to connect to it. The only difference I see is that my custom board is using a nRF51822 QFAA and the Kit is using a nRF51422 QFAC.

Thank you, Pablo. 

Parents
  • Hi Pablo,

    Your description is little confusing: is your "custom" board running GAP Peripheral role and you connect to it from your phone with nRF Connect app? Or is it GAP Central and it tries to connect to another BLE device (GAP Peripheral) which is Nordic Dev Kit? Also what FWs you run on the devices? Finally have you done any debugging on the embedded side? Like having UART logging and see what SD call returns unexpected error code, if it is asserted in your FW and you reset the board from FW or is it some total hard fault going from Soft Device? There are many things you can (and actually should) do before going further here on the forum...

  • Well black box or not, you have it in the source code, you have compiled it so I'm afraid you should debug;) LED is fine for the beginning but as this is 100% reproducible and in software then logical next step is to enable UART logging, attaching some UART serial to USB (virtual COM port) cable and looking into the log on PC (in some terminal like PuTTY) where is the assert. If not visible then put some more logging (just keep it short not to disturb the operation with too much processing) and dig into it until you will find the place. There is big chance that once you will see it you will understand the problem straight ahead. If not then there is good chance that someone here will help you with analysis. I don't think anyone here would (and should) spend time on debugging your FW...

Reply
  • Well black box or not, you have it in the source code, you have compiled it so I'm afraid you should debug;) LED is fine for the beginning but as this is 100% reproducible and in software then logical next step is to enable UART logging, attaching some UART serial to USB (virtual COM port) cable and looking into the log on PC (in some terminal like PuTTY) where is the assert. If not visible then put some more logging (just keep it short not to disturb the operation with too much processing) and dig into it until you will find the place. There is big chance that once you will see it you will understand the problem straight ahead. If not then there is good chance that someone here will help you with analysis. I don't think anyone here would (and should) spend time on debugging your FW...

Children
No Data
Related