Content originally posted in LPCWare by bavarian on Tue Mar 17 04:36:26 MST 2015
With regards to the debug problem I think the FallGuy was on the right track 8-)
[u]Think about what happens normally at startup with the two cores:[/u]
1. Reset (this can also come from the debugger)
2. Cortex-M4 executes the ROM bootloader
3. Cortex-M4 enters your application code and configures + enables the Cortex-M0
4. Cortex-M0 enters the application code
What does a debugger do? It connects to the debug access port, applies a reset and then gets the core under control.
For the Cortex-M4 this always works fine, because it's started by the hardware. The M0 is in reset until the M4 executes the instruction to let it out of reset. If you don't reach this point, you will not get the M0 core under control.
And what you have set in the debug options for the Cortex-M0 is a "Reset after Connect"!
Most likely the debugger is too fast after the reset and tries to catch the M0 before the M4 let it out of reset. I don't think that you can influence this timing, it's part of the JLink firmware.
Please remove this setting, the debugger will therefore try to connect "silently".
[u]My debug strategy for the Cortex-M0 looks like this:[/u]
1. At the beginning of the M0 code there is a simple wait loop, let's say for 3 seconds
2. I do not check the "Reset after Connect", so the debugger jumps on the chip & core without applying a reset
3. I apply a hardware reset to my board and then start the debugger. The time between these two actions is normally sufficient to get into the wait loop in the M0 code.
4. The debugger catches and stops the Cortex-M0 when it's running in the wait loop.
The same I do if I want to debug both cores at the same time. I insert a wait loop in the M4 code, this guarantees that I catch the M4 before it does anything strange (strange things I have programmed :) ). This setup can work with the "Reset after connect". I have two instances of µVision open, the one for the Cortex-M4 catches the M4 and I step through the instruction where the M0 is taken out of reset. Directly after that I start the debugger in the second instance of µVision, which I have prepared to connect to the M0. Then the M0 is catched while it's running in the wait loop. I end up with two debugger and two cores which are stopped. Then I can step through the code.
Consider that all information goes through one interface. The more windows you have open in both debuggers, the more data needs to updated when you do a step or stop at a breakpoint. Take your time when clicking on the step buttons and limit the number of open windows in the GUIs.
[u]With regards to your screenshots, that "Flash download failed":[/u]
If you have no flash specified in your memory map, then it's more than clear that a flash download fails.
You have specified as RO section some part of the internal SRAM (0x20000000) and as RAM and area in external SDRAM (0x29C00C000).
I assume this works fine when you execute your without debugger. This means that the M0 code is part of the M4 binary image and after reset the M4 relocates the M0 code into 0x20000000.
So you don't need to do any flash download.
[u]A debugger setup works like this:[/u]
1. You compile and link an application code for execution from flash
2. You the resulting binary with whatever tool to this flash memory
3. When you start the debugger, µVision just loads the map, symbols etc into the debugger program, it doesn't download anything to the microcontroller.
To make this a little bit more handy, the debugger offers to compile & link and download to flash before before the debugger connection is started, in order to ensure that the image in the microcontroller and the image in the debugger are really the same.
I attached a short training document from Keil which might be useful for you
Hope this helps,
NXP Support Team.
