• State Verified Answer
  • Replies 11 replies
  • Subscribers 68 subscribers
  • Views 2601 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 235284
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Is the SDK ble_app_template project for PC10056e properly working?

Julian

I'm getting started developing an app for nRF52811. have worked with nRF52832 before. 

I was wanting to start my development on top of the basic ble app template project, from the supplied example code in SDK15.3.0 and running the p10056e version (which is simulating the smaller nRF52811 on the nRF52840-DK)

But the app crashes and runs off into the weeds on the call of ble_stack_init() from main

This crashing does not happen when I load up the "native" 10056 version of the project and run it on the same nRF52840-DK, I end up with a board happily sitting there advertising itself to my phone.

I'm using segger embedded studio as my IDE. 

This should be pretty fast to duplicate as it's 100% nordic DK and SDK . 

Full disclosure - I've got hardware made with a real nRF52811 I'm trying to use.. with a modified copy of the 10056e project made following the process as described in the nordic docs - that also fails the same way as the 10056e project on the official DK board. I'm expecting that the crash can be fixed for the emulated project on 52840-DK and that will also apply to my custom hardware.

Parents
  • +1

    Hi,

    I have no trouble running the (unmodified) ble_app_template_pca10056e_s112 example from nRF5 SDK v15.3.0 on a PCA10056 board here. Are you running the unmodified example?

    One first trick is to erase flash on the DK before programming. in case anything is left in UICR or in application storage flash pages. ("nrfjprog -e", or use the nRF Connect programmer app.)

    As suggested by , with the Debug configuration you should get more information about what may be the issue.

    Regards,
    Terje

  • 0 in reply to tesc

    When I first noticed the issue, it was originally in a modified folder as I was trying to target my new hardware as well as the DK board... but I had jumped back to a brand new untouched whole SDK folder in a different HDD location before posting this, and was getting the same issue. 

    Anyway- manually attaching the debugger and manually clearing from there seems to have fixed my issue (on the DK board at least... will check the problem is also better on my custom board tomorrow when I get back to it) 

    So whats the deal with the un-erased flash? is there a way I can configure my project to actually clear out the whole chip on programming for a debug session? If something so crippling can happen when things go wrong, I feel that might be useful.

  • 0 in reply to Julian

    This was a "previously enjoyed" DevKit - wasn't it?

    So some previous project had probably been correctly configured to use FDS.

    But now you've changed the whole memory layout (to emulate a different chip) - so the FDS gets confused byt finding some "left over" bits in Flash.

    It's not a bad practive to do a full chip erase whenever you start a new project.

    The thing with persistent storage is that it will, well ... persist!

Reply
  • 0 in reply to Julian

    This was a "previously enjoyed" DevKit - wasn't it?

    So some previous project had probably been correctly configured to use FDS.

    But now you've changed the whole memory layout (to emulate a different chip) - so the FDS gets confused byt finding some "left over" bits in Flash.

    It's not a bad practive to do a full chip erase whenever you start a new project.

    The thing with persistent storage is that it will, well ... persist!

Children
Related