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

program crash at NRF_BREAKPOINT_COND only when board is connected in some pins, what can cause this ?

hello Nordic

i am working with nrf52832, on the Central app_ble_blinky axample (with pwm, saadc, timer, app, timer, uart ), sdk 16.0, s132 v7

when running my code on my board without the other device connected, the program works fine and does not crashes.

but when i connect the device via some pins i am getting to NRF_BREAKPOINT_COND after connecting the device through some pins to the board.

what hardware fault can make my program crash, how can i find the failing condition in my program ?

also it is hard to debug the ble examples with segger since for some reason it gets to the same NRF_BREAKPOINT_COND after every breakpoint even if i did not start the ble scanning or even commented the ble_stack_init() and ble_scan_init() which i thought at first causing the crash since it was always crashing in the sdh_enable function, but still, without this function in my code, it still crashes

hope to read from you soon cause i am now in integration of my whole system and this bug is a big set back

best regards

Ziv

Parents
  • Have you read you logs? 

    Have you check the error code?

  • i could not because it crushed quickly and i don't always see in Segger's consul for what reason, it is possible that it was a result of some unstable voltage .. one of the pins was set to '1' by the nrf52 and configured as output but when connected to the other device in those pins the voltage was unstable and below 3.3v (as seen in an oscilloscope), unstable around 2v .. i don't know why it cause a program fail though, and not some other error.. in general i don't really get this sort of exception of NRF_BREAKPOINT_COND and i wonder how it works when in running, 'release' mode and not in debug. 

    i am not sure its a legit question but can my final code for the device include this "APP_ERROR_CHECK(err_code), or should i go over all the sdk's function that i use to read there return values and decide my own action (it does not make much sense because some functions call other functions that uses the APP_ERROR_CHECK and this is in the sdk's components, libraries files .. also what to do with build in ASERTS in sdk's functions ? (i use a watchdog but it does not seem like a good enough solution) 

    the initial problem was solved once the hardware issue was fixed in the other device but i still don't know how to avoid program crash like this in case something similar might break down with the hardware ? for me, if it is possible, the Firmware i am writing should be able to inform of a problem in hardware rather then crash from it.

    hope to read from you soon 

    best regards

    Ziv

Reply
  • i could not because it crushed quickly and i don't always see in Segger's consul for what reason, it is possible that it was a result of some unstable voltage .. one of the pins was set to '1' by the nrf52 and configured as output but when connected to the other device in those pins the voltage was unstable and below 3.3v (as seen in an oscilloscope), unstable around 2v .. i don't know why it cause a program fail though, and not some other error.. in general i don't really get this sort of exception of NRF_BREAKPOINT_COND and i wonder how it works when in running, 'release' mode and not in debug. 

    i am not sure its a legit question but can my final code for the device include this "APP_ERROR_CHECK(err_code), or should i go over all the sdk's function that i use to read there return values and decide my own action (it does not make much sense because some functions call other functions that uses the APP_ERROR_CHECK and this is in the sdk's components, libraries files .. also what to do with build in ASERTS in sdk's functions ? (i use a watchdog but it does not seem like a good enough solution) 

    the initial problem was solved once the hardware issue was fixed in the other device but i still don't know how to avoid program crash like this in case something similar might break down with the hardware ? for me, if it is possible, the Firmware i am writing should be able to inform of a problem in hardware rather then crash from it.

    hope to read from you soon 

    best regards

    Ziv

Children
  • ziv123 said:
    i am not sure its a legit question but can my final code for the device include this "APP_ERROR_CHECK(err_code), or should i go over all the sdk's function that i use to read there return values and decide my own action (it does not make much sense because some functions call other functions that uses the APP_ERROR_CHECK and this is in the sdk's components, libraries files .. also what to do with build in ASERTS in sdk's functions ? (i use a watchdog but it does not seem like a good enough solution) 

     That's up to you, I would keep the APP_ERROR_CHECK and then choose what to do in certain situations, depending on what the error code is and what function returned it. Not all errors are critical, some requires you just try again.

  • ok, i am not sure what to take from this so i will ask more..

    1. if i have a watchdog and i get stuck in the NRF_BREAKPOINT_COND will the watchdog restart the system ?

    2. will i get stuck in the NRF_BREAKPOINT_COND even when working in non debug mode (which is just running without debugging) ?

    3. where can i find a list of all the possible errors that APP_ERROR_CHECK receives, (if i get it right, the list of err_code_t) ? so i can try to choose myself what to do or maybe to notify user via gui before i get stuck ?

    best regards

    Ziv

  • ziv123 said:
    if i have a watchdog and i get stuck in the NRF_BREAKPOINT_COND will the watchdog restart the system ?

     Yes, as long as it's not fed. 

    ziv123 said:
    will i get stuck in the NRF_BREAKPOINT_COND even when working in non debug mode (which is just running without debugging) ?

     No, in that case I believe the CPU initiates a soft reset.  

    ziv123 said:
    where can i find a list of all the possible errors that APP_ERROR_CHECK receives, (if i get it right, the list of err_code_t) ? so i can try to choose myself what to do or maybe to notify user via gui before i get stuck

     You are correct, also the error handling library will print out what file and line number the error was returned from, you will then know what function returned it, and from the API docs you will know why that error code was returned. 

Related