ARM920T test results and "issues"

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • ARM920T test results and "issues"

      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.

      The post was edited 4 times, last by ablbd ().

    • Hi,
      Thank you for your inquiry.

      We are not aware of such issues with ARM920T.
      Support has not been changed for a long period and
      there is no other single inquiry regarding this.
      Therefore, we assume that the issue is somehow related to your setup / procedure but not a generic one.

      Regarding 1)
      Not sure, we can offer you to have a quick look at this if you can
      provide us with a reproducer for an evaluation board.

      Regarding 2)
      I will have a quick look into this.
      There is most likely a good reason why we are doing this.

      Regarding 3)
      This is an SDK related question.
      You would have to contact us via the Support Ticket system regarding this (more info in my signature below this post).
      Please do not forget to provide your J-Link SDK registration number.


      Best regards,
      Fabian
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/


      Or you can contact us via e-mail.
    • Hi,
      I took at the CP15 handling:
      J-Link does this to disable the DCache for debugging purposes.
      Other wise J-Link might read cached data on read, and not the "real" data.

      Does this answer your questions?

      Best regards,
      Fabian
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/


      Or you can contact us via e-mail.
    • Hi Fabian, thank you for yout kind answer.

      Although I used to be years ago a professional programmer, now I am doing this as a hobby in my spare time. Except some cheap cortex M boards, I am using for tests factory devices like a complete GPS navigation with access to JTAG pins. As I mentioned in my first post, the ARM920T core in question belongs to a board equipped with Samsung S3C2440X and ram code is loaded and runs in the 4 kB steppingstone SRAM.

      Regarding the DCC issue I cannot raise a tichet becauseas for someone like me it would be usefull but far too expensive to buy and use the SDK. My tests are based on typedef's and a bunch of GetProcAddress(...) but I am carefully measurring the performance of each function. The values are: standard DCC around 210 kB/sec, fast DCC around 180 kB/sec.A hex comparison of the received data using both dcc methods showed no difference at all. It is only question of speed, of performance.

      The cp15 issue seams to be clear, probably at connect() cp15 c1 (maybe other registers too) is/are saved before I start to manipulate them. Anyway, a personal oppinion: I would be happier to control myself the I and D caches, MMU, so, which is a must before running a svc mode ram code.

      The post was edited 2 times, last by ablbd ().