• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 51 subscribers
  • Views 227 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: LL_Init causing crash

Hester Corne
Intellectual 790 points
Part Number: CC2640R2F

Hi,

I'm writing a custom application based on the simple_peripheral example.  I have previously had everything working fine but after some pretty substantial refactoring I'm finding my application crashes with a usage fault in the call to BIOS_start.  Stepping through with the debugger I can see this is occurring inside the LL_Init function called via ICall_taskEntry.  The problem seems to occur when the function tries to branch to 0x20004400, where there is no data.  When I debug to the equivalent point in my previous project there is valid data there.  Looking at the map file, I can see that RAM should be full of ble-r2.symbols but there's nothing there.  Please could you suggest where I can start to identify why that area is empty?

Thanks,

Hester

  • 0
    TI__Intellectual 2180 points

    Hi Hester,

    A couple of follow-up questions to better understand the issue:

    1. Is this using the BLE or BLE5? Also, which SDK version is the simple_peripheral project based from?
    2. Could you please clarify on what you mean when you debug your previous project and mention there is valid data at address 0x20004400? I believe that location is the address for the end of the program stack. Is the previous project you mention the out-of-box simple_peripheral example?
    3. Could you please specify where ble-r2.symbols is showing that data is stored in RAM in the map file? At least looking from an out-of-box simple_peripheral example, this data is stored in the flash region instead of RAM.

    Here is also the debugging guide in case if helps with your investigation of the issue.

    Regards,
    Michael

  • 0 in reply to Michael Hollister
    Intellectual 790 points

    Hi Michael,


    Thanks for your response.  As it turns out I managed to fix the problem just before!  The issue was NULL pointers being used in some of the ECC driver tables.  This was a result of the "invalid" data I mentioned in that area of RAM.  Studying the project options again I found we had missed the compiler extra options for build_components.opt, factory_config.opt and build_config.opt.  This resolved the issue.

    Thanks,

    Hester