RAMCode

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

  • RAMCode

    I have questions about the RAMCode_SDK.
    I am trying to download 13MB files through J-Link to a Freescale K20,
    through a mini-FilingSystem (UBI) to NAND FLASH. I got a copy of RAMCode_SDK.ZIP that targets an
    ARNM7TDMI device that is lacking in API documentation. Could you answer the following :

    • Is there any document that describes the
      RAMCode_SDK, especially the API called by the PC-based software, resources
      used, and Specific_ARM_ASM_LE.o library?


    • ·
      What functions (FLASH_GetDesc()); prototypes, functional descriptions, when
      executed; does the RAMCode_SDK need to provide for the PC-based software?


    • ·
      Is there a RAMCode_SDK build for the Freescale K20?


    • ·
      RAMCode_Specific_Debug.icf and RAMCode_Specific_Release.icf reference
      memory not available on the Freescale K20, do I just adjust the values to RAM
      locations in Freescale K20 address space?


    • ·
      Is there any reserved memory or peripherals that RAMCode_SDK cannot access?


    • ·
      What’s in Specific_ARM_ASM_LE.o and will the one that is written for an ARM7TDMI
      work for a Freescale K20?


    • ·
      How do you debug the RAMCode_SDK?


    • ·
      Any other helpful suggestions?


    · Is

  • Hi all,

    Just noticed that this thread has never been answered. In the meantime, we have heavy improved the RAMCode SDK documentation so that it can be used intuitive. Furthermore, it comes with an example implementation which can be used as reference.

    The RAMCode SDK can be used to create a custom RAMCode for any kind of flash / memory connected to the MCU. Therefore, it allows customers to add flash programming support for custom setups on their own to J-flash / stand-alone mode of the Flasher. For further information, please refer to the J-Flash User Manual.


    Best regards
    Erik
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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.

  • We also got the Ramcode SDK free of charge (=without support), and somehow the 'rules' used by SDK do not match what can be seen by JFlash.
    when using Cortex R4/A9 processors.
    For example i would expect that JFlash first sets the PC to where FLASH_Prepare offset points to.
    Seen here is that PC = RAM start+2.

  • Which "rules" you are referring to? The defined entry point for custom RAMCodes is RAMAddr start + 2 so everything seems to be correct to me. RAMAddr start + 0 is the breakpoint instruction which is used to halt the CPU after the RAMCode function has been executed. Depending on which information has been filled from J-Flash into the Context which is evaluated by the code located right after RAMAddr start + 2, the corresponding RAMCode function is called.


    Best regards
    Erik
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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.

  • Hello Erik,

    the Ramcode SDK here has in the linker configuration file:

    Source Code

    1. place at address mem:0x00000000 { readonly section .intvec };


    where the .intvec symbol is implemented in Specific_ARM_ASM_LE.o,
    when looking with an disassembler looks like:

    Source Code

    1. .intvec:00000000 ; Segment type: Pure code
    2. .intvec:00000000 AREA .intvec, CODE, READWRITE
    3. .intvec:00000000 CODE32
    4. .intvec:00000000 EXPORT _RAMCode_Entry
    5. .intvec:00000000 _RAMCode_Entry DCW FLASH_GetDesc ; Alternative name is '__iar_section$$root'
    6. .intvec:00000002 DCW FLASH_Read
    7. .intvec:00000004 DCW FLASH_Program
    8. .intvec:00000006 DCW FLASH_Erase
    9. .intvec:00000008 DCW FLASH_Prepare
    10. .intvec:0000000A DCW FLASH_Restore
    11. .intvec:0000000C DCW FLASH_FeedWatchdog
    12. .intvec:0000000C ; .intvec ends
    Display All


    also this matches JLink_V510g\Samples\JFlash\ProjectFiles\MC13224V\RAMCodeV2_MC13224V_InternalSPI_LE.mot

    which at the start has a table of offsets 0x0030+1, 0x0058+1, 0x00AC+1...
    also the 6 other mot files in JFlash subdirectory look similar.

    I assume that the ramcode for the MC13224V works on an MC13224V, however when using on for example an Cortex-A9 or R4,
    JFlash executes this in a different way (as you describe).
    For Ramcode written using the SDK it looks like it sets the PC into the table, instead of where the table offsets point to.

    Maybe there exist a different kind of RAMCode SDK?

    Depending on which information has been filled from J-Flash into the Context which is evaluated by the code located right after RAMAddr start + 2, the corresponding RAMCode function is called.

    The function would have to look at the RAMCODE_CMD_INFO.Cmd field then?
    I will give it a try.

  • tried again with a code jump table of

    Source Code

    1. _RAMCode_Breakpoint: BKPT #0
    2. RAMCODE_ASM_CHECKRAM: BKPT #0 ;//b RAMCODE_ASM_CHECKRAM
    3. RAMCODE_ASM_CHECKBLANK: b RAMCODE_ASM_CHECKBLANK
    4. RAMCODE_ASM_CALCCRC: b RAMCODE_ASM_CALCCRC
    5. RAMCODE_ASM_GETDESC: b RAMCODE_ASM_GETDESC
    6. RAMCODE_ASM_READ: b RAMCODE_ASM_READ
    7. RAMCODE_ASM_PROGRAM: b RAMCODE_ASM_PROGRAM
    8. RAMCODE_ASM_ERASE: b RAMCODE_ASM_ERASE
    9. RAMCODE_ASM_PREPARE: b RAMCODE_ASM_PREPARE
    10. RAMCODE_ASM_RESTORE: b RAMCODE_ASM_RESTORE
    11. RAMCODE_ASM_VERSION: b RAMCODE_ASM_VERSION
    12. RAMCODE_ASM_READ_CFI: b RAMCODE_ASM_READ_CFI
    Display All


    Output of JFlash:

    Brainfuck Source Code

    1. - Custom RAMCode file read successfully (3232 bytes, 1 range)
    2. - ERROR: PC of target system has unexpected value after checking target RAM. (PC = 0x01A00002, CPSR = 0x0000003F)!
    3. ---------------------------------------------------------------------- Registers -------------------------------------------------------------------------------------
    4. PC = 01A00002
    5. CPSR = 0000003F (System mode, THUMB)
    7. Current: R0 = 0045B471, R1 = 292D3A7B, R2 = B050F160, R3 = 80000000
    8. R4 = FFFFFFFF, R5 = B0600000, R6 = 5CACCE55, R7 = 9E000002
    9. USR: R8 = 7FFFFFFF, R9 = 00004B00, R10 = 00800000, R11 = 0000FFF8, R12 = 00000000
    10. R13 = 01A00DA0, R14 = 008D684B
    11. FIQ: R8 = FEFEFEFE, R9 = FEFEFEFE, R10 = FEFEFEFE, R11 = FEFEFEFE, R12 = FEFEFEFE
    12. R13 = 0001E670, R14 = FEFEFEFE, SPSR = B60D0038
    13. SVC: R13 = 0000FE88, R14 = FFFF042F, SPSR = 0000003F
    14. ABT: R13 = 0000FF90, R14 = FEFEFEFE, SPSR = FE0F61C1
    15. IRQ: R13 = 0001E570, R14 = 008D623E, SPSR = 2000003F
    16. UND: R13 = 0001E670, R14 = FEFEFEFE, SPSR = DE078073
    17. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    Display All


    corresponding J-Link log file

    Source Code

    1. T0E38 004:477 JLINK_WriteMemEx(0x01A00000, 0x0CA0 Bytes, ..., AccessWidth = 0) - Data: 00 BE 00 BE FE E7 FE E7 FE E7 FE E7 FE E7 FE E7 ... -- CPU_WriteMem(3232 bytes @ 0x01A00000) returns 0xCA0 (0013ms, 1469ms total)
    3. ^ this transfers the RAMCode
    5. T0E38 004:490 JLINK_ReadMemEx(0x01A00000, 0x0CA0 Bytes, ..., AccessWidth = 0) -- CPU_ReadMem(3264 bytes @ 0x01A00000) -- Updating C cache (3264 bytes @ 0x01A00000) -- Read from C cache (3232 bytes @ 0x01A00000) - Data: 00 BE 00 BE FE E7 FE E7 FE E7 FE E7 FE E7 FE E7 ... returns 0xCA0 (0012ms, 1481ms total)
    7. ^ verifies the RAMCode
    9. T0E38 004:503 JLINK_WriteMemEx(0x01A00DA0, 0x0024 Bytes, ..., AccessWidth = 0) - Data: 01 00 00 00 40 0F A0 01 C0 F0 00 00 00 00 00 40 ... -- CPU_WriteMem(36 bytes @ 0x01A00DA0) returns 0x24 (0001ms, 1482ms total)
    10. T0E38 004:504 JLINK_ReadReg(CPSR) returns 0x400000F3 (0000ms, 1482ms total)
    11. T0E38 004:504 JLINK_WriteReg(CPSR, 0x0000003F) returns 0x00 (0000ms, 1482ms total)
    12. T0E38 004:504 JLINK_WriteReg(R13_USR, 0x01A00DA0) returns 0x00 (0000ms, 1482ms total)
    13. T0E38 004:504 JLINK_WriteReg(R15 (PC), 0x01A00002) returns 0x00 (0000ms, 1482ms total)
    14. T0E38 004:504 JLINK_GoIntDis() (0003ms, 1485ms total)
    16. the code is passed the argument not in R0/.. but in SP??
    18. Cmd 1 = RAMCODE_CMD_CHECKRAM
    19. pBuffer = 01A00F40 (after the ramcode and this structure)
    20. BufferSize = 0000F0C0 (remainder to 64 KiB system ram)
    22. T0E38 004:507 JLINK_IsHalted() returns TRUE (0002ms, 1487ms total)
    23. T0E38 004:509 JLINK_ReadReg(R15 (PC)) returns 0x01A00002 (0000ms, 1485ms total)
    Display All


    So it seems that assembler code is needed to prepare a stack and and call a C function with registers in R0/R1/R2..

    Also in the example is no implementation of RAM check.

    Newest file in RAMCode_SDK.zip is readme.txt from 2010-08-31.
    Is there a newer RAMCode SDK that has an example of for example RAMCODE_CMD_CHECKRAM implemented?

  • Hi,

    Newest file in RAMCode_SDK.zip is readme.txt from 2010-08-31.
    This is the latest / current version of the RAMCode SDK.
    Is there a newer RAMCode SDK that has an example of for example RAMCODE_CMD_CHECKRAM implemented?
    CHECKRAM is part of the generic RAMCode part which is included in the J-Link DLL and merged with the specific ramcode (the one created using the RAMCode SDK) during run time. Therefore it must not be implemented manually.

    In general, all files are included in the RAMCode SDK to create the RAMCode on your own. We have many customer who are using the RAMCode SDK successfully. Manual changes like setting the PC or R0, R1, etc... is not needed. In general, we would recommend to compile the RAMCode Specific Template as release configuration and give it a quick try using J-Flash (e.g. implementing the Read function so that it does not access any SFRs but simply set the pDest to a fixed value like for example *pDest++ = 0x11223344)


    Best regards
    Erik
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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.