No source available for "0x300860a"

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

No source available for "0x300860a"

2,372 Views
danielcoleman
Contributor II

Hi,

The bare metal BLE beacon example for the QN9080DK board (qn908xcdk_wireless_examples_bluetooth_beacon_bm) is failing to run to main and when suspending I hit the above error, No source available for "0x300860a". The same is true for the RTOS version of the example, with a different address quoted. I'm running MCUXpresso IDE v10.0.2 [Build 411] [2017-07-11]  with the SDK_2.2_QN908xCDK_Beta_win_b170713.

I've deleted the debug config associated with the project and double checked break at main() is selected in the debug options, to no avail. I've also reinstalled the MCUXpresso and SDK packages several times. I recently moved from MCUXpresso v10.0.0 [build 341 (i think)] in which I was experiencing a hardfault error with the same SDK and example (faulted after calling BLE_init() which seemed to be declared but not defined), this prompted the move to v10.0.2.

If more info is needed or if there's any queries, just ask. Any help would be greatly appreciated.

Thanks and regards,

Daniel

Tags (2)
0 Kudos
Reply
4 Replies

1,696 Views
lpcxpresso_supp
NXP Employee
NXP Employee

That message is basically erroneous. The debugger has at some point of during the connection to the target tried to access memory at a point when the PC was not "valid", and then tried to display the source related to the "invalid" address - which has triggered the edit box with the"no source..." message in it. Preventing this happening is actually very hard, as it depends on all sorts of configuration and timings between the host computer, the debug probe and the target. And most users won will never actually see this in their particular setup.

 

But this shouldn't actually stop you from debugging. Just close that particular edit box, and potentially click on the "main" in stack frame displayed in the Debug View at the top of the screen, and you should then be back in business.

Aside : for details of how to change the location used for the initial breakpoint set when you start a debug session, see 

section 14.3.2, "Controlling the initial breakpoint (on main)" in the MCUXpresso IDE v10.0.2 User Guide.

Regards,

MCUXpresso IDE Support

0 Kudos
Reply

1,696 Views
gerardo_rodriguez
NXP Employee
NXP Employee

Hello Daniel,

I can't reproduce your issue on my side. I was able to debug the code succesfully using MCUXpresso IDE v10.0.2 [Build 411] and a QN9080 DK V1.2.

The MCUXpresso SDK for QN908x requires Rev C or later silicon. Can you check what chip revision is you are using?

You can check the marking description on the QN908x data sheet section 5.

Regards,

Gerardo

0 Kudos
Reply

1,696 Views
danielcoleman
Contributor II

Thanks for the reply, Con Verse. I appreciate your time and effort.

The HowTo you pointed me at mentions the 'stop on startup' field in the debugger tab in debug config, which is missing in my version of MCUX.

I tried adding ResetISR to the 'Set breakpoint at:' option in the startup tab for the debug config, with 'Halt target on startup' checked in the Debugger tab, no joy there. Then I used Reset_Handler (which is indicated as the ENTRY point in the linker script), to no avail. I tried using the address' the Reset_Handler manipulates with a logical OR (0x00000001, 0x40000014 and 0x40000015), again with no consequence.

Do you have any other suggestions or material you could point me in the direction of?

Regards,

Daniel

0 Kudos
Reply

1,696 Views
converse
Senior Contributor V

Set the breakpoint on ResetISR and single step from there, until you see the problem. This is the code that executes before main()

https://community.nxp.com/thread/389022 

0 Kudos
Reply