JTAG "cannot halt processor"

[lpcware]

Content originally posted in LPCWare by mch0 on Thu Aug 28 10:16:26 MST 2014
Hello all,

somehow the debugger (LPCXpresso + LPCLink 2) is starting to drive me mad.
I'm spending more time with the setup than with my project.
What I need is either some pointer where to look in the setup dialogs/files or a foolprof way to set up a custom(!) project.

OK, now the details/problem/setup:

I have two LPCLink2 boards and a custom design, also LPC4370. I am *sure* that all HW works (1).
The custom design uses a Spansion SPIFI flash, this also works (verified) within the board.

Now I need to execute from internal SRAM because I have to erase/write sectors of the SPIFI.
So I have to use a modified project setup:

- custom memory map file to include a flash region
- custom linker scripts to relocate code
- custom startup code to copy code+vector table from flash to SRAM and update the VTOR.

This *all works*. I have been able to load/debug code by a LPCLink2 to the custom board.

The problem is that *every time* I start a new project based on the current one (keping the "old" as a working milestone) I spend hours(!!) to get the debugger setup working again and when I finally succeed I don't know why - the next time I can expect the same drama!

In any setup I made sure that only the LPCLink2 debug probe is visible on USB. When I first start the new debug session the debugger asks me to select one of the three cores it has found (good) on the JTAG target and I select the M4 core. But then things start to go wrong for a long time.

The most common error I receive is "cannot halt processor" like the following one:

LPCXpresso RedlinkMulti Driver v7.3 (Jul  1 2014 11:18:44 - crt_emu_cm_redlink build 130)
Found chip XML file in C:/Users/mch/Documents/nxp/ws/mm06_uart_flash/Debug/LPC4370.xml
Cannot halt processor
Cannot halt processor
Emu(0): Conn&Reset. DpID: 4BA00477. CpuID: 410FC240. Info: (null)
Debug protocol: JTAG. RTCK: Disabled. Vector catch: Disabled.
Cannot halt processor
Failed on chip setup: Ep(04). Cannot halt processor.


I interpret this as: the debugger has connected via the LPCLink2 to the target successfully, but then something in the target does not react as expected.

Questions:
- How can this happen?
- What can I do in the setup?

At other times I can download the code and the debugger stops or seems to stop at the ResetISR.
This is OK and the same behaviour as when I'm finally in the "working state".
But when in "fighting state" I cannot single step ion any way (F5, F6).
Instead the debugger will show the target as "running" and when I stop it I'm still seemingly at the ResetISR.
I cannot interpret this behaviour.

Question:
-What could possibly go wrong here?

There is another, less frequent, error I get in "fighting mode":

"  15: Target error from Read register
  Cannot access core regs when target running."

Someone who has more insight in the combination of LPCXpresso, LPCLink2 and LPC4370 as JTAG target, please help!

I feel I can't stand the next "project setup fight" any more ...

Regards,

Mike

(1)The HW works, because I can load a "standard project" like "blinky" ANY TIME I like to both to a LPCLink2 or the custom board. Without ANY CHANGE of the connected HW.

[lpcware]

Content originally posted in LPCWare by mch0 on Sat Aug 30 07:24:52 MST 2014
"In an earlier post, you may recall we pointed out the processor selection for the new_milestone was incorrect."

You are correct, I just scrolled back because I did not remember that comment.
For some reason, when I got the notification yesterday about an answer I went to the last comment immediately and thus I did not see/read your first two answers which would have pointed me directly to something strange.
Thanks again.
I don't know why I should have selected 4357, probably a "late night click error".
Anyway, at this point I do make progress with the application code again and the tools run just fine ;-)

Even if I select the 4370 correctly, I'll have to modify the linker skript again, because I not only need the new SPIFI region but I also have to tell the linker which parts of the code to relocate. I don't mind that, this is something one cannot realistically expect to be automated. Most users can permanently execute from SPIFI, for them all is done with managed scripts.

If I have anything else on my "wish list" it would be that someone looks into the two issues of the clock setup code in 2.12 I think I have found.
For me and right now the problem is solved, but I feel others could run or already have run into the same glitch.

Best regards,

Mike

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Sat Aug 30 06:51:45 MST 2014

In an earlier post, you may recall we pointed out the processor selection for the new_milestone was incorrect.

You have one foot in the ether here. Whenever you change an MCU setting, the IDE adopts the default memory map for that MCU, overwriting any memory definitions you might have edited. For an LPC4370 part, you would normally modify the default memory map to add your external flash memory region, then select the appropriate flash driver. This probably meant little to you if you intended not to use managed linker scripts. However, you still need to specify the flash driver which corresponds to the flash device in use.

I mentioned the changes I made to the  mm06_uart_Debug_mem.ld script. At this time, I also switched over the MCU setting to LPC4370, and selected the LPC18_43_SPIFI_1MB_64KB.cfx flash driver *.

If you import a project, you get the MCU settings which come with it. There's no way to copy over just the settings part of a project.  :)


Regards,

LPCXpresso Support

* I also deleted and recreated the debug launch configurations which should be whenever you change the MCU settings.

[lpcware]

Content originally posted in LPCWare by mch0 on Sat Aug 30 05:30:19 MST 2014
Second Update (maybe problem solved at last):

After spending more time with the "new_milestone" I may have found the problem.
Within "Project Properties" -> "C/C++ Build" -> MCU settings I found that for my newly created project there was neither the Flash in the memory configuration nor a flash driver selected.

For the missing flash section:
I thought it was derived from the linker script, but maybe either not in general or not because I use unmanaged linker skripts.

Anyway, I entered the flash region manually (top of the list).
Then I selected a suitable flash driver (here: LPC18_43_SPIFI_8MB_64KB.cfx for LPCLink2.

Voila: now I can load & debug the new project!

I hope that this was the missing link and that I now have a way to create "new" milestones in a reliable way.

Is there a way by files to copy over that information from old to new?

Regards,

Mike

[lpcware]

Content originally posted in LPCWare by mch0 on Sat Aug 30 03:27:53 MST 2014
Small update based on your observations:

I made the following changes to the working project (old milestone):

1.  Set size of SPIFI flash to 1 Mbyte (to match Winbond on LPCLink2)
Reason:
To facilitate test setup at NXP site

2. Commented out function Chip_SystemInit() in local file sysinit.c:

#if defined(NO_BOARD_LIB)
/* Chip specific SystemInit */
//Chip_SystemInit();
#else

Reason:
Don't depend on called code in 2.12 sysinit_18xx_43xx.c any more. I made a modification there a few weeks ago and then forgot about it - not good. Thanks to NXP for detecting that. In local files my changes will survive and there I know what I do (hopefully).

Effect:
Clocking is left as is at this point, just as the chip comes out of reset or boot ROM.

3.
Manually set up chip clocking in main().

int main(void)
{
// enable crystal clocking
Chip_Clock_EnableCrystal();
// now use own routine to get finer resolution and stable >150MHz operation
Chip_Clock_SetupMainPLL_mch(CLKIN_CRYSTAL,200000000);
// and switch to PLL1 clock
Chip_Clock_SetBaseClock(CLK_BASE_MX, CLKIN_MAINPLL, true, false);
// update clock variable
SystemCoreClockUpdate();

Reason:
Since the chip is still in default boot clocking at start of main(), I must now initialize all clocking myself. This may look more tedious but since the clock tree setup is non-standard and the 2.12 PLL setup function crashed under some circumstances I better rely on my local code for now.

Effect:
Chip base clock is set to PLL1 output, source is XTAL and frequency is as desired (e.g. 200MHz)

Note:
I still have the small correction left in 2.12 function uint32_t Chip_Clock_GetMainPLLHz(void) in the last line:

//mch return (m / (2 * p)) * (freq / n);
return (m * freq) / (2 * p * n);

The original upper line will produce wrong results due to the integer math for odd values of m.

-----
Overall result:
The "old project" is running as it is expected to. I can debug, the chip runs at 200MHz from RAM and the USART2 outputs my debug print().

The same code in "new_milestone" still fails at the JTAG load stage with "cannot halt processor".
I have used HW-bkpt on ResetISR, since the location is in SPIFI and if I understand correctly the debugger always uses HW bkpt for that region.

I will try a little more with your suggestion of killing processes, but have little hope at this point:/

Best regards,

Mike

[lpcware]

Content originally posted in LPCWare by mch0 on Sat Aug 30 01:37:14 MST 2014
Hi,

great, an answer on Sat (in Europe ), I'm impressed!
Even more thanks for looking into the issue.

I migrate from Atmel to NXP, LPCXpresso is relatelively new to me. I'm sure I miss several things that could make live easier, some I skip even though I know there exists a library.

1 Framework/Libs:
I have choosen "LPCOpen" as base for the project since I want to use the LPCOpen chip libraries and for that it *seemed* the natural choice. I'm aware that at some points by the definition of "__USE_LPCOPEN" code gets activated/deactivated in the default startup code.
However, since the chip currently comes out of the internal bootloader anyway with some configuration I do at this point not care at which frequency it runs or based on what oscillator - I can't change that anyway.
What I can do and what I must do is reconfigure the chip to my setup.

As for now I use the PinMuxing-Functions of the library individually as needed for testing, but I'll most probably do it with the array solution later, if that's what you are referring to.

2: Clocks
We plan to make full use of the 80MSPs ADC, Ethernet and HS USB and use *only* a single crystal.
This can be done with careful selection/use of the PLL1 (USB0PLL of course) and the dividers.
As a consequence I derive the 50MHz required by the ethernet phy from the main clock by using multiples of 50 MHz for PLL1.
This is the reason for the reconfiguration of the PLL1 in main(), here to 50MHz directly.
But 100MHz and 200MHz have been tested and verified by an oscilloscope on a selected high speed CLKOUT pin as well.

In my project and with my HW the call to SystemCoreClockUpdate() sets the variable SystemCoreClock precisely as expected to 50MHz and that is what I see on the oscilloscope.
I do not understand why that is different on your setup.
At one point you refer to 48 MHz instead of 50 MHz.
I am almost 100% sure that this is because you naturally use the 2.12 library as provided (of course!). I had the very same experience. it said 48MHz when in reality it was 50MHz.
The reason is a rounding error (integer math) in the original code of
uint32_t Chip_Clock_GetMainPLLHz(void).
I have posted the problem and the fix in the 2.12-library thread. Can I link to a post? If so, i'd do it for convenience, for now I have to "describe" where I posted.
I think the small bug has gone undetected until now because no one would fiddle with his own PLL1 setup if not needed. But as said, I have to

I agree with you that a stable clock is vital to anything. That is why I spent something around 3-4 days with understanding (hopefully!) how to configure the PLL to my custom requirements.
I have experienced reproducable crashes when using the 2.12 clock setup code and *others* have had the same effect (see my other posts on the 2.12 thread). It's not me alone.
Now that I use my own PLL1 setup code it works rock stable "up and down" for me. Please believe me that I did not spend these days just for fun - had the supplied code worked I would have gladly used it.
I also understand that 99,99% of users never see any of the problems since they simply can live with the "usual" standard setup of the clock domains.

3. Thanks for hinting what to kill when I get stuck with the redlink server.
Is this the same as the "terminate"-button in the "redlink console" window?
That one gives me a "closed" as reaction in the window and usually also helps to recover.

You are correct:
The 64Mbyte for the flash region is a "left over" from the custom board setup where we use as Spanion 64MByte device. Interestingly it is the same wrong size in the "old project" which works and can be downloaded an debugged both on a LPCLINK2 with the Windbond and the custom board with the Spansion.
The new one works on neither. Therefore, although the setting is incorrect for the LPCLINK it does not seem to be the cause of the problem, since in that case it should not work in the old project + LPCLINK2 as well. But I will adapt it, test it and report the effect, if any.

Now for the changes;
First of all I have to apologize, I forgot that I made a modification in the clock set up in the 2.12 file:

/* Set up and initialize hardware prior to call to main */
void Chip_SystemInit(void)
{
Chip_SetupCoreClock(CLKIN_CRYSTAL, 130000000, true);
}

So my code is already running from the crystal and temporarily at 130 MHz. BUT I should indeed not have modified it there in the library file but either in my own file or by a direct call in main().
Yet the second of your points is already done, you could not possibly know that and I forgot either! I apologize! It was a left over from another test. I'll rework that in my project.

For item 1:
I will change clock frequencies later as needed, so I setting a MAX is not useful, or if it were then 200MHz.
It has no consequence anyway here.

For item 3:
The replacement is not what I want, since I want to *set* the PLL1 to a new frequency.
Getting the frequency back and updating the variable is a second issue after that.


For item 4:
This I can and will try now!
I'll report later.


----
Now for the functionality:
You write: "I'm not able to debug your new_milestone project as delivered. It takes a hardfault."
I cannot debug that one either, so I don't know whether it would deliver a hardfault also here.
Yet it is exactly the same code as the *working* "old" milestone.
I can run and debug that one perfectly, no hardfault.
Can you load/debug the old project at your site?
If so that would indicate that the *code* does work at your site as well and that the debug problem has it's cause elsewhere.
Please also replace the IRC clock init by the XTAL clock init as you suggested anyway and I did already to make sure the hardfault does not come from that.
Well, I'll test that now, too.

Thanks for your effort,

Mike

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 29 22:22:49 MST 2014
A few observations about your new_milestone project.

1. I think there's a bit of confusion on how you use LPCOpen. In your compile, you use the __USE_LPCOPEN define to link in LPCOpen code which ultimately sets your cpu core frequency to the a maximum frequency of 204 MHz based on the IRC. Later, in your main routine, you reset the cpu core frequency to 50 MHz (actual 48 MHz) based on the external crystal. I notice you're bypassing the board library, which you could leverage for setting up pin muxing among other things. You should decide on a way forward here.

2. In your main routine, the SystemCoreClockUpdate call is setting your SystemCoreClock variable to 12 MHz. I think you want to display the cpu core frequency here. The SystemCoreClock variable does not reflect the value I think you're after. I don't claim to understand the operation of this call, but perhaps I can find more information for you.

Note the reason I focus on clock setup, is an unstable clock/PLL can affect the operation (and debug operation) of the part. Anytime you encounter a fatal error while connecting a debug session (e.g. "Ep(04). Cannot halt processor."), open the process list and kill the following processes, if present:

redlinkserv.exe
arm_none_eabi_gdb.exe
crt_emu_cm_redlink.exe

There's also a feature within the Redlink Server console to kill the existing server process.

Finally, erase the flash and cycle power.

3. I'm not able to debug your new_milestone project as delivered. It takes a hardfault. I tested your project running from SPIFI flash on an LPC-Link2 board which utilizes an LPC4370. The Winbond SPIFI flash is an 8 M-bit flash device, so I had to modify the mm06_uart_Debug_mem.ld script.

Here's a list of the changes I made.

1. In clock_18xx_43xx.h, define MAX_CLOCK_FREQ 50000000.

2. In Chip_SystemInit (sysinit_18xx_43xx.c), replace the call to Chip_SetupIrcClocking with Chip_SetupXtalClocking. The chip library now configures your cpu core frequency to 50 MHz using the external crystal and main PLL.

3. In main, replace the call to Chip_Clock_SetupMainPLL_mch, and SystemCoreClockUpdate with the following:

   SystemCoreClock = Chip_Clock_GetMainPLLHz(); // I think this is what you want

4. Configure all RAM breakpoints in your list as hardware breakpoints if these breaks exist in the break list prior to starting the debug session.

Regards,

LPCXpresso-Support

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 29 11:42:00 MST 2014
Further to that, in particular, the LPC4357 MCU selection creates a default debug configuration that initially uses the LPC18LPC43InternalFLASHBootResetscript.scp reset script, when you actually want to use the LPC18LPC43ExternalFLASHBootResetscript.scp reset script. This doesn't make a difference right now (virtually identical), but we can't guarantee that won't be the case in the future.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 29 11:06:56 MST 2014
Initial observation from quick skim at project (not debugging, I don't have hardware to hand at the moment).

You are using LPC4370, right? Because the new_milestone project is set to LPC4357 (ie a part with dual bank internal flash).

If you created your project for the correct part, it would definitely make your life simpler - if for no other reason that the linker script produced by the managed linker script would then be correct (or just need SPIFI adding using the memory configuration editor) - rather than you having to hand craft.

It would also mean that the debug connection created for the project would be suitable out of the box for use with external SPIFI flash, rather than internal flash (which doesn't exist on the LPC4370).

Please read the various LPC43 related FAQs before you go any further, as well as the LPCXpresso User Guide.

FAQs include..
http://www.lpcware.com/content/faq/lpcxpresso/lpc18-lpc43-support
http://www.lpcware.com/content/faq/lpcxpresso/lpc18-lpc43-external-flash-drivers
http://www.lpcware.com/content/faq/lpcxpresso/lpc18-lpc43-internal-flash-drivers
http://www.lpcware.com/content/faq/lpcxpresso/using-lpclink2-as-lpc4370-eval

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 29 10:40:05 MST 2014

Thanks, we'll have a look.

[lpcware]

Content originally posted in LPCWare by mch0 on Fri Aug 29 09:51:09 MST 2014
Hi,

I was able to reproduce the problem again.
I have attached an archive that contains both an "old milestone" and the copied "new milestone".
Setup:

LPCXpresso 7.3.0 (free edition)
Both projects cleaned up and exported.
The old one works and can be debugged.
The new one (same code) cannot be loaded due to JTAG error.
The HW is untouched, two LPCLink2 boards.
Only one LPCLink2 visible on USB (probe).
Both set up for "USB Boot".
On the target LPCLink2 I use USART2 TXD on J3 for an output test, but this is optional. If nothing connected, no problem. The LED will blink as in blinky. In the working milestone the USART also works.

The code is totally stripped down, I just want to make sure that the "customizations" which are important are in.

I have also included a step-by-step log to show what I did, it should contain all steps I took since I wrote it down during the action.

Result:
Old project can be loaded/debugged. New one not.
Somewhere I miss a vital step.

I'd really appreciate if someone can have a look at it.

Best regards,

Mike

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 29 02:59:53 MST 2014
Please post to this forum.

[lpcware]

Content originally posted in LPCWare by mch0 on Fri Aug 29 02:43:08 MST 2014
Waah!
Just 2h too late!
After my last comment I deleted (==erased on disk) my last attempt to create a new project stage out of frustration.

But I'll take the bait, it's important for me to understand where the problem is.

So I'll try to repeat (and note down) all steps I take when creating the new project.
I only hope I get the same problems again (but in the past I go them).

I'll use a LPCLink2 as target and a stripped down project (my custom board has not the same SPIFI flash, would not run directly on the LPCLink2).
But the essentials (modified startup code+linker skripts) will be in.

Then I'll send you the "cleaned up" project. Where to send once ready, please?

Best regards,

Mike

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 29 00:21:58 MST 2014
Can you please post a project that exhibits the problem you are reporting, and give us details instructions on how to reproduce. Preferably this should be for a board that we have access to here, such as LPC-Link2, Hitex-LPC4350, Keil MCB4357, or NGX-Xplorer 4330/4337.

Once we can see your projects and can reproduce your problem, we will then be able to offer advice on what is going wrong and how to resolve.

[lpcware]

Content originally posted in LPCWare by mch0 on Fri Aug 29 00:03:32 MST 2014
Thanks for your help!
I still fail to get a new project working in a consistent way.
But at least I can see that we have both the same understanding of the boot sequence.
Before your response I didn't know about the reset context you wrote about.

I indeed do not copy because a simple name change does not rename the details in the files I have to edit manually like the linkerskripts.
As you say I start with a clean project with a new nsame, copy the working headers and sources and then edit the setup (SPIFI initial driver, memory layout, linkerskripts) I have to change for the custom board.
Somewhere in that stage I still miss something, it's just frustrating as I start celan and I know the code ist working at that point (old milestone).

If I find the missing item, I'll post.
For now I must revert to exporting a "milestone" as a backup and continue with the setup that works.


Thanks again,

Mike

[lpcware]

Content originally posted in LPCWare by LessThanZero on Thu Aug 28 15:59:23 MST 2014
The sequence as I understand it is:

1. LPCXpresso connects debug to the processor.
2. LPCXpresso loads the selected flash driver into target RAM, and operates the driver to flash the image.
3. LPCXpresso resets the part. If a reset script is specified, the script is executed. One thing to note here is the debugger attempts to establish the reset context based on the image you loaded. If your board has a way to configure the boot pins you don't need to check the jumper configuration is correct. If you don't use a script, the "Reset Handling" configuration is used (SYSRESETREQ, VECTRESET, or Default). Note the Default is SYSRESETREQ. Don't use it. In this case, you must make certain your boot configuration is correct to debug.
4. The breakpoint requests are processed, and execution starts.

I will say something about "copying" an existing project to make a new one. Avoid the urge to copy a project folder directly to a new location. You should only import and export projects. When you import, it is preferably to a new workspace. When you import a project, it gets imported as is. To make a new project out of it, and you have to change the name, and likely other details. IMO it's better to create a new project, copy over the files you need, and make the appropriate changes to the project settings.

LessThanZero

[lpcware]

Content originally posted in LPCWare by mch0 on Thu Aug 28 14:13:59 MST 2014
Yes, as far as I can tell the debug configuration is the same.
Specifically, the reset script is indeed "LPC18LPC43ExternalFLASHBootResetscript.scp".
The Reset Handling was initially empty in both configurations.
To test your suggestion I tried the other settings availabe in "Reset Handling", but the effect is the same.

My startup code works so far. Within the "old projects" that are beyond the fighting stage.
I do not alter the startup code when copying the project.
Even if it were corrupted for some reason I still don't understand why the message "can not halt processor" would appear. After loading to the SPIFI the first breakpoint (Reset ISR) is still located in the SPIFI address range. So it would get hit before the startup code itself starts, modified or not.
Or do I not understand the whole process at all?

I thought that basically these are the steps:

Debugger loads first loader to the target into internal SRAM.
This loader uses the preselected SPIFI driver.
Then the image to be debugged is loaded into target SPIFI (using the just loaded driver).
Then the first breakpoint is set.
Then the processor starts (or is reset?) using the vector table at SPIFI 0x14000000.

Since the first HW breakpoint is set at the Reset ISR it will get hit immediately.

Is my understanding correct or do I miss something?
If the latter, that could help me locate why I get into all this trouble :(

Mike

[lpcware]

Content originally posted in LPCWare by LessThanZero on Thu Aug 28 12:03:46 MST 2014
So, the first question I'll ask is what's different between the blinky project debug configuration, and the one you're using for your project (besides the image you load)? I'll take you at your word the custom memory map, linker scripts, and startup code work. The next question is, are you using the default reset script, LPC18LPC43ExternalFLASHBootResetscript.scp, in your debug configuration? The reason I ask is the script forces a core reset, aka VECTRESET. You could configure the debugger to use a core reset (i.e. "Reset Handling" setting) without using the script, but the default setting is system reset, aka SYSRESETREQ, if you do not select a value. System reset is not going to work for the LPC4370.