LPC1343: Code Red debugger/upload issues

lpcware · ‎06-15-2016

Content originally posted in LPCWare by hmherzog on Wed Jan 11 15:16:36 MST 2012
Folks,

[U]ISSUE1[/U]: I am finding that starting the debugger for a 10kbyte firmware in Code Red is taking close to 12-seconds from click (on debug) to launch. My machine is a 4-core 2.4 Ghz, 4GB RAM, Fedora 16 with nothing else really running). I am running the latest code-red downloaded about 2-weeks ago (I don't have the version # handy).

CodeRed (Eclipse) launches and compiles almost instantly, but when it comes to uploading firmware during debugger launch, it's really slow. This is reducing my productivity. :) Anything I can do about this?

[U]ISSUE2[/U]: Often after launching the debugger once, subsequent debugger launches do not work unless I actually disconnect the the LPCXpresso board from USB, annoying and time-consuming the say the least. I understand the LPCXPresso based on the LPC1768 has a reset-button -- is that to eliminate this issue? Do I have to wire in a reset button on the LPC1343 board to get productive?

Thanks for your advice. I look forward to releasing some open-source drivers based on this platform very soon.

Hanan

lpcware · ‎06-15-2016

Content originally posted in LPCWare by hmherzog on Sat Jan 14 18:17:43 MST 2012

Quote: Rob65
Just remembered something - I thought it might be worth mentioning this.

If you are playing around with different settings in your application, have them as dynamic configurable items (i.e. global variables) instead of fixed values.

I was just now playing around with a FreeRTOS application and was testing different delay values.
So instead of writing:

vTaskDelay(50);

and changing this value at compile time and reloading the application, make this a variable:

uint32_t my_delay = 50;

func()
{
    ...
    vTaskdelay(my_delay);
    ...
}

As soon as you press the restart button, the debugger restarts the application and breaks at the entry of main(). At that time the global variables already got their default values as in the declaration (this happens in the ResetISR function inside cr_startup_lpc13.c)
This could save you a lot of time compiling and reloading.

I've just fixed my own test application to use a number of these variables for different timers and clock settings.

Just remember to press theSuspend button (the '||' pause icon). If you press terminate (the stop icon) the debugger quits.

Regards,[INDENT]Rob
[/INDENT]

These are all great tips! Thanks again very much for taking the time.

Best,

Hanan

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Sat Jan 14 11:41:26 MST 2012

Quote: Rob65
I don't know.
If the support for the Red Probe+ comes as a separate module then maybe you could plug it into another taste of arm-gdb tools but if this is coded inside gdb then you might be stuck with the gdb that comes with the LPCXpresso toolkit.

I am not even sure if it is possible to use commandline GDB or another flavour of IDE on top of GDB to do debugging.

Maybe CodeRed can answer.

Rob

The driver for Red Probe+ are provided with LPCXpresso IDE / Red Suite, not with the probe, and we don't provide support for the use of the probe with non-CodeRed tools.

Information on using the gdb (debugger) command line can be found in the following two FAQs...

http://support.code-red-tech.com/CodeRedWiki/UsingGDB
http://support.code-red-tech.com/CodeRedWiki/AccessingGDBwithinGUI

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Sat Jan 14 04:23:51 MST 2012
Just remembered something - I thought it might be worth mentioning this.

If you are playing around with different settings in your application, have them as dynamic configurable items (i.e. global variables) instead of fixed values.

I was just now playing around with a FreeRTOS application and was testing different delay values.
So instead of writing:

vTaskDelay(50);

and changing this value at compile time and reloading the application, make this a variable:

uint32_t my_delay = 50;

func()
{
    ...
    vTaskdelay(my_delay);
    ...
}

As soon as you press the restart button, the debugger restarts the application and breaks at the entry of main(). At that time the global variables already got their default values as in the declaration (this happens in the ResetISR function inside cr_startup_lpc13.c)
This could save you a lot of time compiling and reloading.

I've just fixed my own test application to use a number of these variables for different timers and clock settings.

Just remember to press theSuspend button (the '||' pause icon). If you press terminate (the stop icon) the debugger quits.

Regards,[INDENT]Rob
[/INDENT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Sat Jan 14 00:15:41 MST 2012

Quote: hmherzog

Does the Red Probe+ work only with code red or can it be used with other open-source JTAG software?

I don't know.
If the support for the Red Probe+ comes as a separate module then maybe you could plug it into another taste of arm-gdb tools but if this is coded inside gdb then you might be stuck with the gdb that comes with the LPCXpresso toolkit.

I am not even sure if it is possible to use commandline GDB or another flavour of IDE on top of GDB to do debugging.

Maybe CodeRed can answer.

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Sat Jan 14 00:11:45 MST 2012

Quote: hmherzog
However, I do think and think a lot before I program especially on a new platform, but once I am "done" programming one mini-iteration, I like to be able to see the "result" as soon as possible,

Great, it seems there are some 'newbies' that tend to ask first and think later.

One thing you can do (if your board works that is) is to halt the lpcXprosso module and use the 'Peripheral' view (one of the tabs in the top left pane). There you can enable peripherals and view the memory content in the 'memory' pane (bottom of the screen). On my PC I sometimes need to tick a box twice before it appears (with content) in the memory window.

Now you can play around, reading and setting registers of the peripheral.
Still ... refreshing the content of the memory window seems a bit buggy - I never got refresh to work but I need to write to a register in order to see it updated.
Updates seem to be reliable only after single stepping through your code.
Still not perfect but it does give some possibilities.

Quote:
I come from the non-embedded programming world where build-to-test cycles are short, if not instant, and this super-quick cycle is what makes a engineers very happy and productive. It encourages fine-iterative testing (of every tiny change),

It all depends on your software ...
I am not too fond of those super quick cycles but I do use it sometimes (I'm learning Qt and do a lot of those 'what if I change this one bit' tests).
Especially on embedded targets where you have to program a Flash but even downloading to RAM takes some time.
The Flash programming of 40 kBytes/sec. that the CodeRed+ probe support is about the maximum you can get since programming takes time.

Quote:

if that's what you want to do. I guess in the embedded world, or at least with low-cost platforms like LPCXpresso this is not the case.

I spend a lot of time setting up the design and reading through the user manual before actually programming and testing a piece of code. But then, I am an experienced programmer on these platforms so I know what to look for.

Quote:
Would something as seemingly "simple" as the blinky example cause the CPU to get into an undebuggable/uploadable state?

If this indeed is the standard blinky from the examples then there might be some other issue with your hardware or PC installation.

I've seen some strange problems being solved on this forum by just uninstalling and reinstalling the LPCXpresso software and device drivers.

Do you have the possibility to test this on another PCand OS (Windows), just to see if it is your system or the board?

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by hmherzog on Fri Jan 13 15:44:41 MST 2012

Quote: Rob65
The easiest thing to do - and it is even free - is to "look before you leap" : first think, then program. I'm a bit older and grew up with 8751 chips (a 8051 micro with UV erasable EPROM) where every error means that I'd have to erase the chip (25 minutes), reprogram (3-5 minutes) and then test again.
The last few weeks I've been working on a windows device driver, there it takes about 2-5 minutes to recompile, remove the old driver, install the new one, reboot and test.
It really pays of to check your code for completeness and errors before programming. If 12 seconds is reducing your productivity that much then I think your development cycles are too short :eek:

Rob, a genuine thanks for your advice. I am not experienced on this platform, so I need all the help I can get. However, I do think and think a lot before I program especially on a new platform, but once I am "done" programming one mini-iteration, I like to be able to see the "result" as soon as possible, so I can know if I screwed something up. I come from the non-embedded programming world where build-to-test cycles are short, if not instant, and this super-quick cycle is what makes a engineers very happy and productive. It encourages fine-iterative testing (of every tiny change), if that's what you want to do. I guess in the embedded world, or at least with low-cost platforms like LPCXpresso this is not the case.

Quote: Rob65

I think that we get what we pay for: low price, low speed (although I am still quite happy since this is a lot faster than ISP download over a serial port).
The easiest thing to do is just to buy a Red Probe+. The Red Probe+ is not only faster than the LPC-Link, it also provides tracing - that will improve your productivity during debugging even more.

Does the Red Probe+ work only with code red or can it be used with other open-source JTAG software?

Quote: Rob65

No, a reset button alone will not do the trick. You also need to be able to stop the lpc1343 (or any of the other LPCXpresso chips) in the boot ROM, just in case your program does something that leaves the chip in an undefined state.

In order for the debugger to work, you need to have a valid CPU clock (called CCLK in the user manual). If your program does something that leaves the PLL in a funny state there is no (or an invalid) CCLK and the debugger is not able to run.
Also, if there is some interrupt that loads the system the debugger may have a hard time getting attention.

Would something as seemingly "simple" as the blinky example cause the CPU to get into an undebuggable/uploadable state? I was quite surprised that even some of the simple examples provided with LPCXpresso for (PC1343) caused me to be unable to upload new firmware. Since this is the first time I am using LPCXPresso hw/sw I want to be sure I don't have bad hardware (unlikely, I know) or something other configuration issue causing my board to become "unreachable" so often.

Quote: Rob65

If this happens, first pull the ISP pin low, then reset the chip. This will place the lpc into ISP mode - running a piece of code that is inside the boot ROM.
This makes sure that you are able to download a new pogram and start debugging that program.

I will certainly try this again. Unfortunately, I don't have the board with me right now, but you can be sure I will check on it as soon as I get my hands on it.

Thanks a ton!

Hanan

Quote: Rob65

Regards,[INDENT]Rob
[/INDENT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Fri Jan 13 12:49:07 MST 2012

Quote: hmherzog
This is reducing my productivity. :) Anything I can do about this?

The easiest thing to do - and it is even free - is to "look before you leap" : first think, then program. I'm a bit older and grew up with 8751 chips (a 8051 micro with UV erasable EPROM) where every error means that I'd have to erase the chip (25 minutes), reprogram (3-5 minutes) and then test again.
The last few weeks I've been working on a windows device driver, there it takes about 2-5 minutes to recompile, remove the old driver, install the new one, reboot and test.
It really pays of to check your code for completeness and errors before programming. If 12 seconds is reducing your productivity that much then I think your development cycles are too short :eek:

I think that we get what we pay for: low price, low speed (although I am still quite happy since this is a lot faster than ISP download over a serial port).
The easiest thing to do is just to buy a Red Probe+. The Red Probe+ is not only faster than the LPC-Link, it also provides tracing - that will improve your productivity during debugging even more.

Quote:

[U]ISSUE2[/U]: Often after launching the debugger once, subsequent debugger launches do not work unless I actually disconnect the the LPCXpresso board from USB, annoying and time-consuming the say the least. I understand the LPCXPresso based on the LPC1768 has a reset-button -- is that to eliminate this issue? Do I have to wire in a reset button on the LPC1343 board to get productive?

No, a reset button alone will not do the trick. You also need to be able to stop the lpc1343 (or any of the other LPCXpresso chips) in the boot ROM, just in case your program does something that leaves the chip in an undefined state.

In order for the debugger to work, you need to have a valid CPU clock (called CCLK in the user manual). If your program does something that leaves the PLL in a funny state there is no (or an invalid) CCLK and the debugger is not able to run.
Also, if there is some interrupt that loads the system the debugger may have a hard time getting attention.

If this happens, first pull the ISP pin low, then reset the chip. This will place the lpc into ISP mode - running a piece of code that is inside the boot ROM.
This makes sure that you are able to download a new pogram and start debugging that program.

Regards,[INDENT]Rob
[/INDENT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Thu Jan 12 01:09:59 MST 2012
1. I think this is mostly due to the speed of LPC-Link. So, nothing you can do about it.
2. Did you read the FAQ: http://support.code-red-tech.com/CodeRedWiki/DebugAccessChip
Note, there are no RESET buttons on any of the LPCXpresso boards.