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

nrf52840 device hang with bootloader and app vector table discrepancy(fpu_irq_handler)

Hi,

I have a hang issue with my custom board using a custom bootloader and application.

The problem is device hangs when I downgrade the application on the latest bootloader.

I found that the difference was adding FPU_irq_handler so the issue happens with the latest bootloader with custom FPU_irq_handler and the older version app without the handler.

When I check the call stack, the point that the hang happened doesn't make sense and even if I remove the code, it still happens the next code which looks not related to the issue at all.

Also if I add custom FPU_irq_handler to the old app, the hang issue disappears.

So the only clue I found is FPU_irq_handler but I wonder if this vector table discrepancy can cause a hang or exception issue like this if so, why?

And one more thing I don't understand is the opposite case like upgrading app (a old bootloader without fpu irq handler + the latest application with fpu_irq_handler) is fine.

I'll appreciate it if anyone can help me with this issue.

Thank you.

[call stack]

[map file compare old app vs new app]

  • Hello,

    I am not sure what causes this behavior, but it could be that adding the FPU to the handler causes it to stick when you downgrade. Is Errata 87 implemented in your old and new application?

    Out of curiosity, when the device hangs after the downgrade, does it still hang after a power cycle?

    Have you considered preventing downgrading, or is that not an option?

    Best regards,

    Edvin

  • Hi Edvin,

    Thank you for the answer.

    I think  nRF5_SDK_15.3.0_59ac345 already has Errata 87 implementation so it should be in both of the applications

    at PWR_MGMT_FPU_SLEEP_PREPARE() and I am calling  nrf_pwr_mgmt_run() for sleep mode.

    And the device hangs at the same point even after power cycles.

    I can try to prevent downgrade but before that,  there are many product devices that are not available to flash bootloader so I need to know what causes the issue exactly and decide if I leave the old bl devices or try fixing it if it is possible.

    Thank You.

  • Hello,

    Note that it is possible to update the bootloader via DFU. You can generate a DFU image containing a bootloader and the softdevice. If you want to, you can also add an application to this image.

    It looks like the errata workaround is implemented in SDK15.3.0, yes.

    A couple of shots in the dark:

    What GNU toolchain version are you using?

    Have you by chance tried to replicate this using another IDE? I see that the dummy_handler is only present in armgcc. Have you tried e.g. SES?

    Best regards,

    Edvin

  • Thank you for helping.

    I found the issue that bl enabled fpu irq and the newer app doesn't have a handler for it. So it went to the default handler with while loop.

Related