This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

BSP driven buttons don't work with a bootloader

Situation

  1. I have an app, that use a BSP to detect pressing of the buttons. It works.

  2. I have a bootloader. It also works.

Problem

When I flash bootloader AND app simultaneously, BSP cannot handle button pressing. No errors during init - just bsp_button_event_handler() never fire.

Environment

  • SD 120 v.2.0
  • NDK 8.0.0
  • board PCA10001
  • compiler GCC 4.9 2014q4
  • I use a Hung Bui (@hungbui) proposed bootloader (see here), and memory values are as in answer here
  • my app is based on the ble_app_multilink_central example from NDK8

Note

Doesn't matter if I flash bootloader then app or vice versa. Also, I try to flash bootlader and then load app with bootloader DFU. The result is the same - app is flashed, started, but buttons do not work.

Thank you.

Parents
  • That's pretty curious.

    Are you correctly finishing the bootloader process with bootloader_app_start(). That fixes up the softdevice handler table to point to the start of your code. Is your code in the right place and is CODE_REGION_1_START evaluating to something sensible (see bootloader.c).

    It should be that your app code, when executed, re-sets up all the GPIOTE from scratch, including enabling the event, enabling the interrupt etc, if it didn't then it seems it wouldn't work standalone, however I'd break into the code whilst running and check all those things, is the PORT event enabled, is the IRQ enabled. The bootloader does disable all IRQs as the last thing before running user code, the startup code should re-enable them all, but it's worth checking.

    You could also trace the IRQ handler, it's not that hard. It starts at 0x012a, it should load 0x1000 from 0x20000000, add 0x58 to it and branch to what's at that address, which should be 0x21e4. That in turn should load your vector table start from 0x20000004, add 0x58 to that and branch to your IRQ handler. Just putting a hardware breakpoint at 0x012a you should be able to see where it goes. If it doesn't even get hit, then the IRQ is somehow disabled.

Reply
  • That's pretty curious.

    Are you correctly finishing the bootloader process with bootloader_app_start(). That fixes up the softdevice handler table to point to the start of your code. Is your code in the right place and is CODE_REGION_1_START evaluating to something sensible (see bootloader.c).

    It should be that your app code, when executed, re-sets up all the GPIOTE from scratch, including enabling the event, enabling the interrupt etc, if it didn't then it seems it wouldn't work standalone, however I'd break into the code whilst running and check all those things, is the PORT event enabled, is the IRQ enabled. The bootloader does disable all IRQs as the last thing before running user code, the startup code should re-enable them all, but it's worth checking.

    You could also trace the IRQ handler, it's not that hard. It starts at 0x012a, it should load 0x1000 from 0x20000000, add 0x58 to it and branch to what's at that address, which should be 0x21e4. That in turn should load your vector table start from 0x20000004, add 0x58 to that and branch to your IRQ handler. Just putting a hardware breakpoint at 0x012a you should be able to see where it goes. If it doesn't even get hit, then the IRQ is somehow disabled.

Children
  • Hello, thank you for your answer.

    1. Yes bootloader is finished with: bootloader_app_start(DFU_BANK_0_REGION_START). Where DFU_BANK_0_REGION_START == CODE_REGION_1_START == SOFTDEVICE_INFORMATION->softdevice_size (it's info from dfu_types.h). My code starts, so I think it's in the right place. Maybe IRQ Vector table not in the right place, how can I check where linker places IRQ vector table?

    2. Yes, you are right, as far as the app code works standalone - all IRQs should be set up correctly.

    3. I use a gcc compiler for app, not Keil so I cannot debug. Alev

  • RK, thank you for your help. The problem was solved (see comment upper). Thanks again.

Related