LPC1549 debugging issues (LPCRunBootRomReset.scp)

[lpcware]

Content originally posted in LPCWare by mubes on Thu May 08 04:52:26 MST 2014
Folks,

LPCXpresso 7.1.1 has the following script in the file LPC15RunBootRomReset;

100 REM Reset script to run the boot rom at Reset
110 cmresetvectorcatchset this
120 cmsysresetreq this
130 print "Halt on reset vector catch"
140 cmresetvectorcatchclear this
150 cmwatchset this 0 4
160 cmrun this
170 cmwatchset this 0 0x40074380
180 cmrun this
190 print "Halt on watchpoint write of ROMWSCTRL register"
200 cmwatchclear this 0
210 poke32 this 0x40074380 1
220 end

Can anyone help out with what this is for?  I cannot find a register at 0x40074380 ... according to Pg. 40 of the user manual UM10736 the whole area from (0x40074)220 to 3F0 is just marked as reserved. I'm pretty sure this code will have been copy/pasted from another script, but the register location doesn't appear in any of the other scripts in the directory.

If I leave this script in my (defaulted) debug config for my custom board then the part doesn't halt and I get 'cannot access registers while CPU running' type of errors. Removing it makes all good, but I cannot access the trace functionality (complains it can't find the rom) which I think may be related to this...

Regards

DAVE

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue May 20 01:04:07 MST 2014

---

Quote: mubes
I'd still like to know what that access to the undocumented memory location is actually used for though, since the debugging session seems to work without that script running. What is it's purpose?

---

In many cases, the scripts may not actually be necessary for a successful connection to LPC15. But their use ensures connection/reset behaves consistently (for example connections being made when the MCU has powered up with an erased flash).

Basically this particular pair of scripts is setting a watchpoint on a memory write (to an internal 'waitstate' register) that takes place towards the end of the bootloader code. We then know exactly where we are in the bootloader operations. But because we watchpointed on the access, we are then actually carrying out the write to memory that the bootloader code would have made.

You should also note that we make no guarantees that redlink scripts will not change between releases.

Regards,
LPCXpresso Support.

[lpcware]

Content originally posted in LPCWare by mubes on Mon May 19 16:31:53 MST 2014
Guys,

Could you please reply on this?

Regards

Dave

[lpcware]

Content originally posted in LPCWare by mubes on Wed May 14 16:13:32 MST 2014
Guys,

Thanks for this. I'm quite comfortable with the 'it could prevent problems in edge conditions' kind of argument for the resistors...they will go on the next edition.

Even with the script, I do see issues with redlinksrv not closing correctly on occasion...I am travelling (again!) but will try to see if I can create a reliable problem scenario for you.

I'd still like to know what that access to the undocumented memory location is actually used for though, since the debugging session seems to work without that script running. What is it's purpose? This board is also intended to work with openocd .. I can happily put a similar script in there but the justification 'cos it's in LPCxpresso' is a bit weak  :)

Regards

Dave

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed May 14 00:17:10 MST 2014
In the past, with LPC-Link1 / Red Probe+, any part specific operations needed to make debug connections were "hidden" within our part family specific debug connection stubs (the 'crt_emu_* executables). For example, we might need to carry out a special operation to ensure that the whole of the MCU's bootloader has completed running before we grab debug control. With Redlink, for various reasons, the debug connection stub is more of a generic mechanism, and we are using external script files to carry out these sorts of operations. However from your point of view, the execution of these scripts can generally be considered a black box.

With regards to the pullups/pull-downs, then yes sometimes you might get away with not putting these on, depending upon lots of factors including the exact details of your board design, the MCU being used etc. But generally we recommend them because with them you are much more likely to get a successful and reliable debug connection.  Leading to less stress for you in your development, and less support for us!

And yes, SWO trace is on our roadmap for Redlink - but I can't provide timescale details at present. If you need SWO trace functionality with LPCXpresso urgently, then I believe Mouser still has limited stocks of the Code Red Red Probe+ debug probe left, which do support this functionality.

http://uk.mouser.com/ProductDetail/Code-Red-Technologies/RP-PLUS/?qs=sGAEpiMZZMsPDM5321osT3CGI%2fi8F...

Finally, note that there are no known issues connecting to LPC1549 with LPCXpresso. We are using LPCXpresso1549 boards, as well as Keil MCB1549 here - using both onboard and offboard debug probes - without problem.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by mubes on Tue May 13 23:46:30 MST 2014

---

Quote: mubes

* What exactly is that reset script doing?
* Why add resistors on the SWD/SWDIO lines?
* Is there any plan to add any SWO trace functionality to the CMSIS-DAP/Redlink interfaces?  If so, is there an ETA?

---

Folks,

Do you need any more information from me to be able to answer these questions?

Regards

Dave

[lpcware]

Content originally posted in LPCWare by mubes on Mon May 12 01:00:54 MST 2014
OK, a little more information, the full markings on the chip are;

LPC1549JBD100
S63501.1    02
ZSD13502A

I have just run the script again (to collect the error log) and it's all worked perfectly (no board changes, no resistors, CMSIS-DAP)!  So, now I am very confused indeed and I'm afraid I've still got questions;

* What exactly is that reset script doing?
* Why add resistors on the SWD/SWDIO lines?

and, since this board will have an associated debug interface board;

* Is there any plan to add any SWO trace functionality to the CMSIS-DAP/Redlink interfaces?  If so, is there an ETA?

Regards

DAVE

[lpcware]

Content originally posted in LPCWare by mubes on Fri May 09 09:34:39 MST 2014
Hi R2D2,

---

Quote: R2D2


Several LPC1549 boards are working here without thousands of pull-ups and pull-downs with Link2  :)

Reset pull-up and ISP pull-up are required, then your board should run with minimal Debug connection (GND, SWDIO, SWCLK, Reset)...

---

Yup, I've got all sorts of boards (812s through to 4330s) here running with no resistors at all, and none are specified in chapter 43 of the user manual, but it's easier to spend ten mins soldering resistors than four hours arguing the case :-)

I suppose I'd like to understand the purpose of the resistors on the SWD/SWDIO pins anyway...the reset and ISP pins are just good practice, but I do wonder if the others are just a a result of someone once having a problem and this passing into folklore..

Regards

Dave

[lpcware]

Content originally posted in LPCWare by R2D2 on Fri May 09 04:17:33 MST 2014

---

Quote: mubes
Certainly the debug wiring isn't the same as in your referenced documents due to a screwup on my part, but I will add resistors next week and see if it changes the behaviour.

---

:O

Several LPC1549 boards are working here without thousands of pull-ups and pull-downs with Link2  :)

Reset pull-up and ISP pull-up are required, then your board should run with minimal Debug connection (GND, SWDIO, SWCLK, Reset)...

[lpcware]

Content originally posted in LPCWare by mubes on Fri May 09 01:51:30 MST 2014
Guys,

Thanks for the fast response on this. Unfortunately I'm travelling now until Monday so I can't give you some of the information you've asked for at the moment. The board is open source so I can post any info that's useful when I'm back.

I am indeed using standalone lpc-link2. The problem seems to occur in both cmsis-dap and redlink mode, but I need to verify that. The parts are recent (last month or so) NXP-direct samples, but I don't have a good enough picture here to verify coding.

Certainly the debug wiring isn't the same as in your referenced documents due to a screwup on my part, but I will add resistors next week and see if it changes the behaviour.

What exactly is this script doing (and the other, connect, script that is also referenced) and what do you achieve by using it? Even in the absence of the resistors the part does appear to be responding to debug correctly without the script being there...I've certainly done a few development sessions on it (first break at main) without issue. I'm a bit concerned if I'm using a part that needs undocumented special incantations to make it do things - in my prior experience that's not been the 'NXP way'...

Regards

Dave

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu May 08 07:09:39 MST 2014
These addresses are internal registers, not public ones. We are needing to access them order to ensure that the part comes out of reset correctly for debug purposes. Do not remove these accesses!

Anyway…

Please can you confirm the full markings (text) on the top of the MCU you are using?

Can you also double check your debug/reset circuitry against http://www.lpcware.com/content/faq/lpcxpresso/debug-design. [It might also be worth checking against the LPCXpresso1549 board schematics too (http://www.lpcware.com/LPCXpressoV2Boards).

I assume that you are using a (standalone) LPC-Link2? Can you confirm that you are using this in redlink mode (rather than CMSIS-DAP for example)? ie ensure that JP1 is open, as per http://www.lpcware.com/lpclink2

Can you also provide the debug logs from when you start a debug session?
http://www.lpcware.com/content/faq/lpcxpresso/debug-log

And finally, can you clarify exactly what trace functionality you are trying to access? There is no ETM support in LPC15xx, and LPC-Link2 does not support SWV trace currently.

Regards
LPCXpresso Support