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

Problem with detecting Button push on PCA10056 and SDK 17.0.2

Description of setup/problem.

1 PCA10056 is defined as Central

1 PCA10056 defined as Peripheral.

 

I have used the “ble_app_uart_c” and “ble_app_uart” examples as starting point for my applications.

I have added functionality and removed functionalities from the examples. Everything works fine. On the peripheral and central  I use the app_button library and have defined 18 buttons on the peripheral with no problems. On the Central unit I have until now used Button 1 on the PCA10056 board as button for initiating pairing, but when it comes to our custom central board, I cannot use any of the pins that are assigned to Button1 to Button 4 on the PCA10056.

Yesterday I defined another pin as pairing pin; pin 19 (P0.19) but could not detect any event when that button (connected to pin 19) was pushed. (I use a breadboard to connects buttons, LED, analogue and digital sensors). If I use one of the PCA10056 buttons I can detect an event if the button is pushed, even that I have removed boards.h/boards.c, bsp.c/h bsp.btn.ble.c, etc.    

I have compared sdk.config on my peripheral unit with the central unit, I use the same app_button, etc, but cannot see why I can only use those pins defined as Button 1 to Button 4 on the board which are defined as central unit. If I flash a custom board with the same SW the push at the button connected to pin 19 is detected.

I assume there is something in the SDK that overwrite my settings, but I cannot figure out what it could be. Do you have any ide of what this may be due to?

Kind regards, Svein

Parents
  • Hello Svein,

    Thank you for your patience with this. The summer holidays have begun here in Norway, and DevZone is therefore operating with reduced staff for the time being. Sorry for any inconvenience this might cause.

    Sorry in advance for all the questions; I am not sure that I understand you issue correctly, with regards to what tests have worked on which device, and what tests have failed on the customer board.
    Is the issue here that you are unable to use the P0.19 pin for a button pin on the nRF52840 DK?
    Or is the issue that you are unable to use the pins that are used for buttons on the DK, as button pins on your custom board? In case of the former, it might be that the pins are already in use on the DK, and that you need to disable this functionality by cutting or soldering some solder bridges.
    In case of the latter we will need to look into the hardware of your custom board, to see why it is not registering the buttons presses on these pins.

    when it comes to our custom central board, I cannot use any of the pins that are assigned to Button1 to Button 4 on the PCA10056.

    Are you saying that this is an unexpected issue, or as a statement to explain why you need to use other pins for this?
    In case of the former, please elaborate what you mean when you say that you can not use these pins.
    In case of the latter, you can overlook this question.

    pin 19 (P0.19) but could not detect any event when that button (connected to pin 19) was pushed. (I use a breadboard to connects buttons, LED, analogue and digital sensors). If I use one of the PCA10056 buttons I can detect an event if the button is pushed,

    Are you saying that you were able to use the P0.19 pin on the DK (which by default is used for the QSPI external memory), but not on the custom board?
    Could you provide a small schematic to illustrate how you have connected the button to your P0.19 on the breadboard, or could you confirm that it is connected like the buttons are connected to the pins on the DK?

    I assume there is something in the SDK that overwrite my settings, but I cannot figure out what it could be. Do you have any ide of what this may be due to?

    As for this, there is only one instance of overwritten sdk_config that I know of, and that is the case when a legacy definition is left defined while you attempt to use the NRFX driver for the same peripheral.
    Basically, it means that if you leave *_ENABLED defined, while you simultaneously try to define NRFX_*_ENABLED 1, then the apply_old_config file will overwrite your NRFX_*_ENABLED define, to instead use the legacy driver.
    This feature exists to support backwards compatibility, but it is known to cause some confusion.
    You can read more about this in this ticket.
    However, I would not think that this is the case here, since you say that you are flashing the same firmware to both the DK and the custom board.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

  • Hi Karl,

    Thanks for the reply; it helped, and the problem has been found and solved.
    As you pointed out it was a conflict with PINs already in use on the DK10056 and those PIN we wanted to use.


    I was not aware about that those PINs we wanted to use in our custom design was allocated to external memory on PCA10056. I will put in front of me a list of PINs that is allocated on PCA10056 and then hopefully I will not run in to the same problem again. 


    Again, thanks a lot for your informative answer.

    Kind regards,

    Svein

  • Hello again, Svein

    Svein said:
    Thanks for the reply; it helped, and the problem has been found and solved.

    No problem at all, I am happy to help and glad to hear that the issue now is resolved.

    Svein said:
    As you pointed out it was a conflict with PINs already in use on the DK10056 and those PIN we wanted to use.
    Svein said:
    I was not aware about that those PINs we wanted to use in our custom design was allocated to external memory on PCA10056. I will put in front of me a list of PINs that is allocated on PCA10056 and then hopefully I will not run in to the same problem again. 

    Yes, the DK already uses quite a lot of the available pins for different purposes, to make development on the DK easier.
    However, you could of course choose to disconnect this functionality, by connecting or cutting the solder bridges, if there should be a particular DK functionality you do not need, or if you need to use a particular pin..
    Please also keep in mind the SoC's Pin Assignment when choosing pins to use on your custom board.

    Please do not hesitate to open another ticket if you should encounter any issues or questions in the future.

    Good luck with your development!

    Best regards.
    Karl

Reply
  • Hello again, Svein

    Svein said:
    Thanks for the reply; it helped, and the problem has been found and solved.

    No problem at all, I am happy to help and glad to hear that the issue now is resolved.

    Svein said:
    As you pointed out it was a conflict with PINs already in use on the DK10056 and those PIN we wanted to use.
    Svein said:
    I was not aware about that those PINs we wanted to use in our custom design was allocated to external memory on PCA10056. I will put in front of me a list of PINs that is allocated on PCA10056 and then hopefully I will not run in to the same problem again. 

    Yes, the DK already uses quite a lot of the available pins for different purposes, to make development on the DK easier.
    However, you could of course choose to disconnect this functionality, by connecting or cutting the solder bridges, if there should be a particular DK functionality you do not need, or if you need to use a particular pin..
    Please also keep in mind the SoC's Pin Assignment when choosing pins to use on your custom board.

    Please do not hesitate to open another ticket if you should encounter any issues or questions in the future.

    Good luck with your development!

    Best regards.
    Karl

Children
No Data
Related