Search Results
Search results 61-65 of 65.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
Joerg, We would like to reproduce the problem you are reporting; it does sound like a problem in the GBDServer. Can you use the Beta version, generate a log file and send it to support@segger.com, along with a short bug report or link to this thread ? Thanks, Rolf
-
Hello Viscell, J-Flash should automatically insert the correct checksum from 0x14 to 0x17 for NXP LPC 20xx - 24xx devices. If this is not the case can you send the J-Flash project file and hex file to support@segger.com ? Thanks, Rolf
-
Hello Gaby, if the disassembly window shows (and therefor reads) memory before 0x40000000, similar corruption can occur. You should be able to get rid of this by enlarging the indirect read area as follows: > map indirectread 0x3fffc000-0x3fffffff instead of > map indirectread 0x3fffc000-0x3fffcfff Can you confirm that this solves the problem ? Thanks, Rolf
-
Hello, thanks for sharing the idea. We will create a little (free) utility. We are quite busy right now, so it may take a few weeks. In the meantime, we'll add a command to J-Link commander (jlink.exe) which does the same thing: "term" will act as a DCC terminal until the user presses Crtl-C. It is already working; we'll make this available in the next Beta version, probably tomorrow. Happy holidays!
-
Hello Gary, Hello Faessle, this is a problem in the NXP chips. When the fast I/O ports are read in debug mode (using LDMIA instructions), a write access to occurs to the address right after the last read. J-Link reads up to 13 words at a time, so if you read an area of 0x100 bytes at once, you will see problems at offset 13 * 4 = 52 = 0x34, 0x68, 0x9c and 0xd0. Again, this is a problem in the chips, but there is a way to avoid this: The problem does not occur if the fast I/O area is read by the …