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

Asset Tracker Program hangs before main on Thingy91

Hi,

We are having trouble getting the Thingy91 firmware running as is. We have achieved this in the past but I had made too many modifications and I decided to scrap it and start over. But I didn't realise that I could've just reused the cmake file so I uninstalled and reinstalled the SDK. 

We are trying to run the Asset Tracker project from the 1.3.0 toolchain.

So what happens is that when I build and debug instead of going to main() it stops here:

Then when it runs it hangs here:

I have tried to modify it to change the floating point configuration but I changed it back. I didn't try running it before the modifications

Parents
  • I see the exact same behaviour as you, and am able to debug without problems. First I would recommend you to set
    CONFIG_DEBUG_OPTIMIZATIONS=y in ncs\v1.3.0\nrf\applications\asset_tracker\prj.conf to optimize the code for debugging, then reopen the project and set the nRF Connect Options again (if you only build it, the changes in prj.conf will not be taken into effect).

    Regarding the first image, the one where it stops at arch_kernel_init(), in my case it always stops there and always has. I'm not sure why this is, but I can look into it. However, it has never affected the application in any way. After I continue the debugging, the program runs as expected.

    Regarding the second image, this is expected behaviour. If I click the break sign while the application is running I will see that the program is there as well. You can see that you're in cpu_idle and that wfi has just been run, which means the idle thread is running, the chip is sleeping, and there is currently nothing happening. Every once in a while the device will wake up from sleep and handle different kinds of interrupts, like cellular-related stuff, timers, callback handler for peripherals, but when that is handled it will go back to the idle thread an into sleep again. Take a look at this ticket about the System ON sleep and the idle thread.

    Could you check that the Asset Tracker application is actually working by checking the serial output and if it connects to your account on https://nrfcloud.com?

    By the way, I would urge you to open public cases instead of private ones, if you're not sharing any confidential information. Then other people may benefit from the answers given here and you may get answers from other DevZone users as well

    Best regards,
    Simon
Reply
  • I see the exact same behaviour as you, and am able to debug without problems. First I would recommend you to set
    CONFIG_DEBUG_OPTIMIZATIONS=y in ncs\v1.3.0\nrf\applications\asset_tracker\prj.conf to optimize the code for debugging, then reopen the project and set the nRF Connect Options again (if you only build it, the changes in prj.conf will not be taken into effect).

    Regarding the first image, the one where it stops at arch_kernel_init(), in my case it always stops there and always has. I'm not sure why this is, but I can look into it. However, it has never affected the application in any way. After I continue the debugging, the program runs as expected.

    Regarding the second image, this is expected behaviour. If I click the break sign while the application is running I will see that the program is there as well. You can see that you're in cpu_idle and that wfi has just been run, which means the idle thread is running, the chip is sleeping, and there is currently nothing happening. Every once in a while the device will wake up from sleep and handle different kinds of interrupts, like cellular-related stuff, timers, callback handler for peripherals, but when that is handled it will go back to the idle thread an into sleep again. Take a look at this ticket about the System ON sleep and the idle thread.

    Could you check that the Asset Tracker application is actually working by checking the serial output and if it connects to your account on https://nrfcloud.com?

    By the way, I would urge you to open public cases instead of private ones, if you're not sharing any confidential information. Then other people may benefit from the answers given here and you may get answers from other DevZone users as well

    Best regards,
    Simon
Children
No Data
Related