Search Results

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 a…

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 implemen…

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 …

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 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 spec…

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 lis…

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…

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. …

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 man…

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 ...