Hi. During the winter holyday I managed to make some extensive tests with my almost 6 years old V9.2 J_Link Edu. The target is ARM9T, more precisely S3C2440A. During the tests I noticed several issues regarding some API's and the emulator itself. Dll version 6.94.
Identification usually goes well
T2110 000:407.977 TotalIRLen = 4, IRPrint = 0x01
T2110 000:409.308 JTAG chain detection found 1 devices:
T2110 000:409.361 #0 Id: 0x0032409D, IRLen: 04, ARM9 Core
T2110 000:410.420 -- Max. mem block: 0x00010D90
T2110 000:410.544 - 6.111ms returns 0x00
T2110 000:410.575 JLINK_IsConnected()
T2110 000:433.928 CP15.0.0: 0x41129200: ARM, Architecture 4T
T2110 000:434.667 CP15.0.1: 0x0D172172: ICache: 16kB (64*8*32), DCache: 16kB (64*8*32)
T2110 000:434.700 Cache type: Separate, Write-back, Format A
but mesuring CPU speed I get a strange result:
T212C 007:663.719 JLINK_MeasureCPUSpeed(RAMAddr = 0x30000000)
T212C 007:663.756 -- ReadRemote(16 bytes @ 0x30000000)
T212C 007:665.368 - Writing 0x10 bytes @ 0x30000000
T212C 007:665.402 -- WriteRemote(16 bytes @ 0x30000000)
T212C 007:666.234 - Writing 0x08 bytes @ 0x30000000
T212C 007:666.327 -- WriteRemote(8 bytes @ 0x30000000)
T212C 007:667.088 -- ReadRemote(8 bytes @ 0x30000000)
T212C 007:677.441 J-Link: ARM9 CP15 Settings changed: 0xC0003278 from 0xC0003200, MMU Off, ICache On, DCache Off
T212C 007:688.147 ClockFreq: 801376000 Hz
T212C 007:688.271 - 24.569ms returns 801376000
It is absolutely impossible for the givven core to run at that frequency as the data sheet is very specific on that: 400MHz. I checked UPLLCON and MPLLCON settings: 200MHz / 400HMz, consistent with the specifications. Do you have an axplanation for this result?
The seccond observation is that it looks like jlinkarm.dll is "playing" with CP15 out of user control. In order to issue the CPU speed command at DRAM address (0x30000000), I previously had to disable MMU and caches but for test purposes I cleared instead of last 3 bits the last 8 bits of control register C1. I interpret the above log fragment that jlinkarm.dll has restored some of the original values (see line "CP15 Settings changed: 0xC0003278 from 0xC0003200"). Is this a normal and desired behaviour?
The third observation is related to DCC reads/writes and their "fast" versions. I am using an optimised PIC "driver" in DRAM which reads/writes the internal Nand through hadware registers and sends or reads data on DCC. The driver takes care of flag checks too. By mesuring the transfer speed of a large enough amount of data, I noticed that the fast API versions (JLINKARM_ReadDCCFast and JLINKARM_WriteDCCFast, which supposingly do not chech the transfer flags) are working 10% slower then regular API's. The core @400 MHz clock should be fast enough to handle the DCC transfer without flag check at host's side. Is there a particular reason at hardware or software level for the poor performance of the so-called FAST API's?
At the end an issue related to emulator which, in most of the cases works well. Although the ntrst pin is connected, at the initialisation phase I explicitely change the reset type into 3 (or 6, which seams to be the same). It happened not once that when the emulator stays connected a longer period of time to PC and target is on, someting is going wrong because when I launch my program, the emulator is hard resetting the target and imediately a message pops up informing me that connection is lost. The reason of the message is clear as no Close statement was sent to dll but I cannot understand why is hard resetting the target when it should'n do that. In order to restore normal functionality, I have to disconnect and reconnect the emulator.
Identification usually goes well
T2110 000:407.977 TotalIRLen = 4, IRPrint = 0x01
T2110 000:409.308 JTAG chain detection found 1 devices:
T2110 000:409.361 #0 Id: 0x0032409D, IRLen: 04, ARM9 Core
T2110 000:410.420 -- Max. mem block: 0x00010D90
T2110 000:410.544 - 6.111ms returns 0x00
T2110 000:410.575 JLINK_IsConnected()
T2110 000:433.928 CP15.0.0: 0x41129200: ARM, Architecture 4T
T2110 000:434.667 CP15.0.1: 0x0D172172: ICache: 16kB (64*8*32), DCache: 16kB (64*8*32)
T2110 000:434.700 Cache type: Separate, Write-back, Format A
but mesuring CPU speed I get a strange result:
T212C 007:663.719 JLINK_MeasureCPUSpeed(RAMAddr = 0x30000000)
T212C 007:663.756 -- ReadRemote(16 bytes @ 0x30000000)
T212C 007:665.368 - Writing 0x10 bytes @ 0x30000000
T212C 007:665.402 -- WriteRemote(16 bytes @ 0x30000000)
T212C 007:666.234 - Writing 0x08 bytes @ 0x30000000
T212C 007:666.327 -- WriteRemote(8 bytes @ 0x30000000)
T212C 007:667.088 -- ReadRemote(8 bytes @ 0x30000000)
T212C 007:677.441 J-Link: ARM9 CP15 Settings changed: 0xC0003278 from 0xC0003200, MMU Off, ICache On, DCache Off
T212C 007:688.147 ClockFreq: 801376000 Hz
T212C 007:688.271 - 24.569ms returns 801376000
It is absolutely impossible for the givven core to run at that frequency as the data sheet is very specific on that: 400MHz. I checked UPLLCON and MPLLCON settings: 200MHz / 400HMz, consistent with the specifications. Do you have an axplanation for this result?
The seccond observation is that it looks like jlinkarm.dll is "playing" with CP15 out of user control. In order to issue the CPU speed command at DRAM address (0x30000000), I previously had to disable MMU and caches but for test purposes I cleared instead of last 3 bits the last 8 bits of control register C1. I interpret the above log fragment that jlinkarm.dll has restored some of the original values (see line "CP15 Settings changed: 0xC0003278 from 0xC0003200"). Is this a normal and desired behaviour?
The third observation is related to DCC reads/writes and their "fast" versions. I am using an optimised PIC "driver" in DRAM which reads/writes the internal Nand through hadware registers and sends or reads data on DCC. The driver takes care of flag checks too. By mesuring the transfer speed of a large enough amount of data, I noticed that the fast API versions (JLINKARM_ReadDCCFast and JLINKARM_WriteDCCFast, which supposingly do not chech the transfer flags) are working 10% slower then regular API's. The core @400 MHz clock should be fast enough to handle the DCC transfer without flag check at host's side. Is there a particular reason at hardware or software level for the poor performance of the so-called FAST API's?
At the end an issue related to emulator which, in most of the cases works well. Although the ntrst pin is connected, at the initialisation phase I explicitely change the reset type into 3 (or 6, which seams to be the same). It happened not once that when the emulator stays connected a longer period of time to PC and target is on, someting is going wrong because when I launch my program, the emulator is hard resetting the target and imediately a message pops up informing me that connection is lost. The reason of the message is clear as no Close statement was sent to dll but I cannot understand why is hard resetting the target when it should'n do that. In order to restore normal functionality, I have to disconnect and reconnect the emulator.
The post was edited 4 times, last by ablbd ().