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?

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
  • 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

  • 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.

Reply
  • 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.

Children
  • 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!

  • Hi,

    Let me add that for many use cases it is a better default behavior to keep application data when (re)flashing the application, than to remove it.

    It is easy to erase all before programming, when an empty data storage is needed.

    It can be complicated to restore application data that was erased during programming, when that is what you need.

    Regards,
    Terje

  • for many use cases it is a better default behavior to keep application data when (re)flashing the application

    I agree.

    It is easy to erase all before programming, when an empty data storage is needed

    Indeed.

    But it can be a surprise that stuff is "left over" - as here, and as I referenced earlier.

    Maybe this could be noted in the FDS and/or fstorage documentation ... ?

  • Hi,

    I think a better location would be in the "Testing" section of all examples. A note that application data is not erased when programming , so we recommend to erase flash before programming if the board has been previously used with a different application.

    Or maybe instead a small FAQ / troubleshooting page, covering typical error situations (like this one), that can be linked to from each example documentation page?

    Regards,
    Terje

  • I think a better location would be in the "Testing" section of all example

    Sounds reasonable - like the note that says, "remember to program the SoftDevice" on the BLE examples...

    Or maybe instead a small FAQ / troubleshooting page

    That would be good - in general.

    Although we know that people don't look at such things, but just jump straight onto the forum...

    Disappointed

Related