Posts by SEGGER - Rolf

This sounds as if Codesourcery had changed their GDB interface.
Normally, the vErase packet should not be sent (It should only be sent if the GDBServer reports that it can handle this packet).
Since J-Link handles Erase automatically, there is no need to handle this packet, and it should not be sent.

In any case, we will look into this and either modify the J-Link GDBServer or get in touch with CodeSourcery (Mentor) asking them
to fix it, assuming that we can reproduce it.
Until then, it seems an easy workaround is to use an older version of CodeSourcery, especially as you write
that an older version of this stuff works:

Quote

I don't think it is a hardware problem as most of the boards have been successfully debugged before using an older version of CodeSourery.

Which older version are you using that works and can you verify it also works with the STM32F205?
J-Link can handle that device.

Hi emBlocks,

you are right, per default, flash memory is treated as fully cacheable, and it does not get invalidated when the CPU runs.
We have a functionality to not cache it or to invalidate a certain part of it (the part that one would use for data storage).
The settings are stored in the settings file (Control panel).
However, the best way would probably be a monitor command that does the same thing and allows automatic
invalidation of the flash area or a part of it. I guess we will implement this functionality next week.

Will keep you posted. Happy Easter

We do not have eval boards for these devices, so we do not know for sure.
In general, if they are build around a supported core such as an ARM7TDMI, a Cortex-M, a 926EJS
or any other supported CPU, it should be possible, but no guarantees. After all, we do not
know if there is any protection in the device.
Besides, If you want to "crack" cell phones or other devices, please do NOT expect us to support you.
We sell tools for developers, not hackers.

You should try the latest Beta. It fully supports download and debugging with an unlimited number of breakpoints
in both Internal Flashes of supported microcontrollers as well as external NOR flashes (currently CFI compliant ones only).

Thanks for providing the solution to the problem.
You are right, the chip samples RTCK after Reset and it requires a pull-down.
This may indeed be a problem for many people designing their own hardware, but it is
clearly written in the NXP manual.
May be worth considering to copy it to the J-Link manual under "device spcifics", but I do not
think we really want to do so.
We expect customers to either read the chips manual or simply copy the relevant parts
of the schematic of the eval board when designing your own hardware.

So, in general the procedure we recommend we doing a new design:

a) Get an eval board with the device
b) Test J-Link and your tool chain with the eval board. There should not be any problems. If there are, get in touch with
the tool provider (be it Segger for the J-Link or anybody else for the compiler/debugger)
c) Design your own hardware. Schematics should be close to the schematic of the eval board.
d) Test your custom hardware. If it does not work like the eval board, look for differences.

Again, thanks for proving the answer.

Hello Fran,

it seems like your hardware simply is not working correctly.
J-Link should connect and work find with the LPC2158.

On an other note:
You write:
"(it's an old one...will only run firmware up to 4.08l"

There should not be a problem running the latest software.
What happens when you use the latest software ?

Can you download either the latest release or the latest Beta
from http://www.segger.com/download_jlink.html
and run J-Link commander and post the output ?

Hello All,

It seems the script file feature is something that is needed by quite a number of users.
In order to make sure the script file feature can be used with any software using the
J-Link software, we just added a feature:

When the JLinkArm.dll is loaded, it checks if a file called "default.jlinkscript" is located
in the same directory as the dll. If so, it is automatically loaded.This allows activation of
a script even if the debugger does not set a project or supports an other way of specifying
a script file, so it works for IAR, Keil, GDBServer and everything else.

This feature is present from V4.11n on.

BTW, the latest Beta contains also documentation of the commands available in script files.

Below a sample connect file for an TI OMAP L138.

//
// J-Link Target setup file for IcePick on TI OMAP L138
// Note that a very similar init works for other TI devices. In case of of doubt, please contact support@segger.com
//
//Dialog.MessageBox("Setting up Icepick");
//
// Setup Icepick
//


// In order to use the "WriteIR" and "WriteDR" commands,
// IRLen of device has to be set first.
// If you have multiple devices in the scan chain at boot up time
// IRPRE, DRPRE, IRPOST and DRPOST have also be set in order to use the "WriteIR" and "WriteDR" commands
//
JTAG.IRLen=6;
JTAG.Speed = 1000;               	// Set high JTAG speed
//
// JTAG.Write Syntax JTAG.Write(NumBits, <TMS>, <TDI>)
//
JTAG.Write  (6, 0x1F,0x1F);      	// TAP Reset
JTAG.WriteIR(7);
//
// JTAG.WriteDR Syntax JTAG.WriteDR(NumBits, <TDIData>)
//
JTAG.WriteDR(8, 0x89);
JTAG.WriteIR(2);
JTAG.WriteDR(32, 0x81000080);
JTAG.WriteDR(32, 0xA2002008);
JTAG.WriteDR(32, 0xA2002108);
JTAG.WriteIR(0x3F);              	// Bypass
JTAG.Write  (10,0,0);            	// Write 10 clocks


//
// Configure JTAG chain, so J-Link knows to which devices it has to "talk"
//
JTAG.IRPRE=0;
JTAG.DRPRE=0;
JTAG.IRPOST=6;
JTAG.DRPOST=1;
JTAG.IRLen=4;
CPU=arm926ejs;

Hello M3Guy,

we'll take a look at this soon, probably tomorrow.
Thanks for the zip file in disguise. You are right, it probably does make sense to allow
zip files.Will be changed, more soon.

Hello K.,

we have just published a new release V4.10d.
Currently, the release is newer than the Beta (Maybe we should indicate this on the web ...),
so if you could try that it would be appreciated.
Independent of this, we'll also take a look at this next week.

BTW: We'll increase the 20K limit, it is a bit small indeed.

Let me try to clarify things (I know it is a bit confusing):

Yes, download to flash is free. This means that all flash loaders that we have
integrated in the J-Link software can be used with any J-Link or OEM product such as
SAM-ICE or Midaslink without requiring an extra license.
The supported devices are basically all popular ARM7/9 or Cortex-M3 / M0 microcontrollers
with built-in flash.

Which devices are supported?
You should either look it up in the manual or (better) check the drop-down list in the
J-Link control panel which lets you select the microcontroller.
Of course devices like AT91SAM7xxx, AT91SAM3xxx, LPC23xx, LPC24xx or STM32 are supported,
but also many others.

Can I use the free flash download in production ?
The idea we at Segger had was different. We basically made our flash loaders available because we felt
that a lot of times the flashloaders that come with a tool chain (in this case IAR) didnot work reliably
or not nearly as fast as our flash loaders. We felt this makes it easier to use a lot of tool chains (such as IAR, Keil,
but also GDB) with J-Links. So the plan was to use the J-Link flash download for development purposes;
in other words you'd use the debugger to load the program and then J-Link to program the flash.
Of course, this can also be used in production. However, if you do, you are basically responsible for telling J-Link
which device it is programming and for loading the program. There are multiple ways to do this:
As shown above, you can use GDB with a script (see above). You could also use J-Link commander (free, in the
software and documentation pack) to do the same thing, so you do not need to use GDB. This probably keeps it
a little simpler.
An other option is to buy the SDK (@398 Euros) and write a little application (typicall in "C") which does the same thing.
This is not a difficult task, especially since the source code of J-Link commander is part of the SDK.
If there is interest to find out how to program the flash using J-Link commander, let me know, we can
post a small sample script.

JTAG Isolation
In general, when you are using J-Link to program your micro in a production environment, we recommend you also
use the JTAG Isolator. This will protect J-Link against voltage spikes and different ground potentials, as well
as protect the PC used and your target hardware.

So what about J-Flash ?
J-Flash is a program which requires an extra license. It can also program external flash on basically any system,
which is something the flashloaders in the J-Link software can not (at least not now).
J-Flash is also used as setup-program for our stand-alone programmer, Flasher ARM.
So: To use J-Flash with a standard J-Link, you still need a license. With Flasher ARM or J-Link PRO, that license
is already included. If the flash download from the debugger or J-Link commander is all you need,
you do not need to anything else, no extra license.
So the choice is yours. Hope this helps to clarify it.

But I could always download from the IAR debugger into flash. What is the difference to the J-Link flash loaders ?
The flsh loaders in the J-Link software are optimized for both the target system and J-Link. They are very fast,
typicall much faster than the flash loaders that come with EWAR.
ANd they work very reliably and do not typically need any setup information (all we need to know is
which micro is used)
Try it out. All you have to do is typically to disable the flash loader of the debugger.
The J-Link flash loader should now automatically take over when you download program into the flash.

Why are the J-Link flash loaders so fast ?
Because we know what we are doing ...
We take full advantage of the available RAM, avoid operations that are not required,
let the processor program as much as possible at once.
But we also typically check if a sector already contains the correct program
(something that happens quite frequently when modifying a program ... Sometimes
a lot of sectors remain unchanged when you do a small change in the program).
This, just like verifying, is done typically by a fast 32-bit CRC algorithm which runs in the
target controller.
An other reason is that typically we setup the PLL to let the target CPU run at high speed,
something that will also help to accelerate programming and CRC computation.

Hope this helps to clarify things ...

Rolf

Hello,

as a general rule: Simply copy this part of the schematic from the eval board.
And of course: Get an eval board. Does not cost much, but this way you have a stable platform
for first experiments. And if you copy the relevant parts of the schematics, you hardware should work the
same way.

Reg. Pull-ups: NRESET should always have one, and typically also TCK. But again: follow what the experts
do on an eval board. Some processors have built-in pull ups, so it does not hurt to read the manual.

Best regards,
Rolf

Can you try the latest Beta to see if it behaves differently ?
Do you have any other eval board to see if you can connect ? (Maybe the J-Link or target board has a hardware defect)

What is strange is that J-Link can not pull RESET low. Can you check if the RESET line goes low when you use
the command r0 ?
If not, it may explain things: The STM32 may be in power down mode and needs a Reset, but it never gets a Reset
because Reset line does not go low.

Just guessing, maybe you can test this ?

Piet,

it seems the problem is that the reset after download of the flash loader does not work right.
Can you send the content of the flash memory or (even better) the IAR project which has
caused this to support@segger.com ?

Also: Which board are you using ?
We would like to investigate what is going on.

BTW: As a work-around, you should be able to use NXPs flash magic tool. Since it puts the CPU in
a bootloader mode, it should be possible to erase the flash and continue to work with IAR EWARM.

Best regards,
Rolf

Makes sense & is already on the ToDo-List.

However, feel free to also suggest this to Keil, as they could also add it.

--Rolf

Hi Richard,

just a side note:
J-Flash is one option to program the target, but the download into flash should also work.

With the init file you describe, you should be able to download into flash.
If it does not work, you should look at the Log-tap of the J-Link status window.

Does flashing the device from GDB/Eclipse work ?

Best regards,
Rolf

Hello,

the reason why the core is not recognized when you add an additional device is probably
that it can not be recognized automatically.
The recognition is currently based not only on the JTAG Id, but also on the IR Print and other information.

Unfortunately, this does not work under all circumstances.
What you will have to do is configure the scan chain:
For J-Link commander, the command is
Config <IRPre> <DRPre>

Example:
Config 0 0
Config 4 1

For details, please refer to the J-Link user manual.
When writing your own program, you should use a similar command; check out the SDK Doc.

--Rolf

You probably put the CPU in some state in which JTAG is disabled or blocked for some other reason.
For ATMEL AT91SAM7 devices, you should use the ERASE Pin to erase the chip and you should be back in business.

With SAM7 devices, this is in a lot of cases the only way to gain control of the CPU since nRESET is per default disabled
(A bit of a strange design).

Hello Thomas,

which package (for which tool chain) did you download and which version of the compiler did you use ?
We'll try to reproduce this and fix it if it is a problem on our side.

Thanks,
Rolf

This should work. Maybe you should hook up a scope and check the JTAG signals.
Maybe you should also read the "trouble shooting section" of the J-Link manual.

Eugene,

it does not work this way. The first process will modify the ICE registers, so they are temporary registers
that are not consisten between processes.
You can still read write ICE registers from a second process, but you should be aware that the first process can modify them at any time as well.
After all, it is only one CPU ...