Add a new flash device to the JLInkDevices database

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

  • Add a new flash device to the JLInkDevices database

    Hello,

    I'm playing with K82 and QSPI.

    Where is a problem with a BOOTROM. It uses LE64 format for data storage while jlink uses LE32.

    in this case I have couple of questions:
    1) Is it possible to have an access to the processor via script file right before QSPI flashing?
    I thought it could be SetupTarget(), but seems it isn't

    If 1) - no
    2) is it possible to extend JLinkDevices.xml without touching an original file?
    Like create a separate JLInkDevices.xml file and add it to the jlink.dll via cmd line parameters?
    I checked 10.2 paragraph and looks like it's impossible. Am I right?

    if 2) - no.
    Where can I find more information about Open Flashloader API?
    a) which section is mandatory?
    b) is it possible to use gcc for this loader creation?
    c) Is it possible to provide a custom JLInkDevices.xml file to the jlink dll and which cmd line param could be used?
    d) Is it possible to have a debug output in the custom loader from running gdbserver?
    e) Is it possible to have more logs in the gdbsever in the part of custom flashloader?
    f) At what address does jlink load the loader code in the target?
    g) if answer in f) RAM - should I specify a RAM address of my target or I can set 0 as a base address in the ELF ?

    Thank you for your answers.
  • Hi,


    1)
    While "SetupTarget()" is definitely executed before the first download, "right before" and "before each" flash download can be done with "HandleBeforeFlashProg()"

    HandleBeforeFlashProg() can be used with version 6.16c or higher of the J-Link software & documentation pack.
    It will be documented in the near future.

    Does this work for you?


    Best regards,
    Niklas
    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.
  • No, this stuff doesn't work.

    *** J-Link V6.16c Executing PCode ***
    HandleBeforeFlashProg
    *** J-Link V6.16c Executing PCode ***

    *** J-Link V6.16c Executing PCode ***
    value = 0x00000000
    *** J-Link V6.16c Executing PCode ***

    *** J-Link V6.16c Executing PCode ***
    read u32 from:0x400DA000
    *** J-Link V6.16c Executing PCode ***

    *** J-Link V6.16c Executing PCode ***
    MCR = value = 0xFFFFFFFF
    *** J-Link V6.16c Executing PCode ***

    *** J-Link V6.16c Executing PCode ***
    HandleAfterFlashProg
    *** J-Link V6.16c Executing PCode ***

    *** J-Link V6.16c Executing PCode ***
    MCR = 0xFFFFFFFF
    *** J-Link V6.16c Executing PCode ***


    Looks like this callback is called BEFORE QSPI module initialization.

    I need a callback which is AFTER QSPI init and BEFORE JLINKARM_MemWrite call

    schema is the following: SEGGER QSPI init -> callback -> real QSPI download data

    or the 2nd approach is to implement own flash loader binary (have no success here yet).
  • Hi Alexey,

    schema is the following: SEGGER QSPI init -> callback -> real QSPI download data

    This is not possible with the current version. Could you please explain what you are trying to achieve?
    Where is a problem with a BOOTROM. It uses LE64 format for data storage while jlink uses LE32.

    The QSPI flash loader should not need to care about the data format, but just program the data as it is given. Could you please elaborate?

    like create a separate JLInkDevices.xml file and add it to the jlink.dll via cmd line parameters?

    You can pass the command string "JLinkDevicesXMLPath <Path>" in order to specify a .xml which extends the original .xml file.
    This command string is neither officially documented nor can provide support for it.

    a) which section is mandatory?

    This is documented in UM08001 and the wiki article: wiki.segger.com/Adding_Support_for_New_Devices
    b) is it possible to use gcc for this loader creation?

    In SEGGER Embedded Studio you can choose between the gcc and the llvm/clang compiler
    c) Is it possible to provide a custom JLInkDevices.xml file to the jlink dll and which cmd line param could be used?

    If you do not want to extend but to replace the existing .xml file, you can do so by specifying your .xml in the J-Link settings file (please refer to UM08001 for further information regarding the J-Link settings file)
    d) Is it possible to have a debug output in the custom loader from running gdbserver?

    If I understand correctly that the question is if the custom flash loader can be used when using J-Link GDB Server, the answer is yes.
    e) Is it possible to have more logs in the gdbsever in the part of custom flashloader?

    ??
    f) At what address does jlink load the loader code in the target?

    In the work ram area which is specified for each supported device in the J-Link software.
    You can override the default work ram area by using the respective J-Link command string - please refer to UM08001 for further information.
    g) if answer in f) RAM - should I specify a RAM address of my target or I can set 0 as a base address in the ELF ?

    The ELF file needs to be position independent. This is done automatically when using SEGGER Embedded Studio and the provided example project.

    Please do not hesitate to ask if there are further questions.


    Best regards,
    Niklas
    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.
  • SEGGER - Niklas wrote:

    Quoted
    schema is the following: SEGGER QSPI init -> callback -> real QSPI download data


    This is not possible with the current version. Could you please explain what you are trying to achieve?
    The goal is simple, I want to run my application located in the QSPI using BOOTROM startup procedure.
    The application could be loaded to the QSPI in 2 ways.
    1) using jlink software
    2) using sbloader functionality of BOOTROM

    the way 1) is preferable because of sw debugging procedures.

    SEGGER - Niklas wrote:

    Quoted
    Where is a problem with a BOOTROM. It uses LE64 format for data storage while jlink uses LE32.


    The QSPI flash loader should not need to care about the data format, but just program the data as it is given. Could you please elaborate?
    the issue is in the QSPI controller configuration.
    before upload to QSPI jlink configures controller in the 32bit LE mode (byte ordering: B4 B3 B2 B1 B8 B7 B6 B5)
    at the BOOTROM start it confifures QSPI controller in the 64bit LE mode (byte ordering: B8 B7 B6 B5 B4 B3 B2 B1)
    as you can see DW1 and DW2 are swapped. in this case BOOTROM reads flash content at the address 0x68000000 and expects to have a qspi config block magic value, but it receives next 4 bytes and treated this situation as no qspi configuration present.

    I can put QSPI config block into the interanl flash, but the code in QSPI will also swapped and simple doesn't work.

    I can't change endianity in the chip, what's why I want to switch jlink to 64bit LE mode. I just need to write only 2 bits to the MCR register.....



    SEGGER - Niklas wrote:

    Quoted
    d) Is it possible to have a debug output in the custom loader from running gdbserver?


    If I understand correctly that the question is if the custom flash loader can be used when using J-Link GDB Server, the answer is yes.


    SEGGER - Niklas wrote:

    Quoted
    e) Is it possible to have more logs in the gdbsever in the part of custom flashloader?


    ??
    Those two questions are connected to the custom flash loader debugging procedure.
    I just wanted to know is there any way to make debug output from CustomFlashLoader into the gdbserver log (screen or file)
  • Hi Alexey,


    the SEGGER QSPI flash loader only works in LE32 mode. Therefore, changing the mode to LE64 before flash download will cause the flash loader to be defunct.
    If changing the mode in "HandleAfterFlashProg()" does not work for you, you need to use your own flash loader.

    before upload to QSPI jlink configures controller in the 32bit LE mode (byte ordering: B4 B3 B2 B1 B8 B7 B6 B5)
    at the BOOTROM start it confifures QSPI controller in the 64bit LE mode (byte ordering: B8 B7 B6 B5 B4 B3 B2 B1)

    I understand what LE32 and L64 do mean from a instruction or data fetch perspective, but from the flash programming perspective, i do not see the issue.
    If the data file contains
    Add Value
    0x00 0x11
    0x01 0x22
    0x02 0x33
    0x03 0x44
    0x04 0x55
    0x05 0x66
    0x06 0x77
    0x07 0x88

    does the data read from the flash differ?
    Which programm does generate the data file?


    Best regards,
    Niklas
    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.
  • SEGGER - Niklas wrote:

    the SEGGER QSPI flash loader only works in LE32 mode. Therefore, changing the mode to LE64 before flash download will cause the flash loader to be defunct.
    If changing the mode in "HandleAfterFlashProg()" does not work for you, you need to use your own flash loader.
    Looks like this callback is called AFTER UnInit loader function because of
    *** J-Link V6.16c Executing PCode ***

    HandleAfterFlashProg

    *** J-Link V6.16c Executing PCode ***



    *** J-Link V6.16c Executing PCode ***

    MCR = 0xFFFFFFFF

    *** J-Link V6.16c Executing PCode ***

    I suppose thie means: "The register can't be read."


    SEGGER - Niklas wrote:

    I understand what LE32 and L64 do mean from a instruction or data fetch perspective, but from the flash programming perspective, i do not see the issue.
    If the data file contains
    Add Value
    0x00 0x11
    0x01 0x22
    0x02 0x33
    0x03 0x44
    0x04 0x55
    0x05 0x66
    0x06 0x77
    0x07 0x88

    does the data read from the flash differ?
    Which programm does generate the data file?
    In the K82 processor there is BOOTROM which can configure QSPI flash by itself and pass an execution control to it later.
    to do so I have to prepare a special structure QSPI config block.

    to simplify things let imagine it has only 2 fields

    struct qspi_config{
    uint32_t field1; (magic: ABCD)
    uint32_t fielf2; (data: 1234)
    };

    in case of 64LE fields are placed like "1234 ABCD"
    in case of 32LE fields are palced like "ABCD 1234"

    at the startup BOOTROM reads uint32_t from the structure's 0 offset and check it against magic (ABCD)
    if I put data by Segger in 32LE format and BOOTROM reads it in 64LE format, then BOOTROM tries to compare 1234 against magic (ABCD).
  • Hi Alexey,


    if I understand you correctly, the boot header / QSPI config block is always read as LE64.
    Therefore, the issue can be resolved by swapping the bytes in the data file accordingly before passing it to the J-Link flash loader.

    Most QSPI flashes have different available configurations / modes regarding the data format (LE32/LE64/BExx/"striping" modes with another flash, etc [..]).
    Therefore, the J-Link flash loader always programs the flash in the same predictable way.

    For example:
    You have two QSPI flashes in "striping" mode. In order to work, the QSPI-Flashes need to be programmed as follows:

    Source Code

    1. QSPI_0: QSPI_1:
    2. [Magic Block] [Magic Block complement]
    3. [Configuration] [Configuration complement]
    4. DATA_000 DATA_001
    5. DATA_002 DATA_003
    6. DATA_004 DATA_005
    7. [..] [..]


    The correct way to program this using the J-Link software would program QSPI_0 with:
    [Magic Block]
    [Configuration]
    DATA_000
    DATA_002
    DATA_004

    and then programming QSPI_1 with:

    [Magic Block complement]
    [Configuration complement]
    DATA_001
    DATA_003
    DATA_005


    On first sight, this might seem more complicated that passing program the QSPIs with the following data to J-Link and expecting that J-Link handles to rest automatically,:

    DATA_000
    DATA_001
    DATA_002
    DATA_003
    DATA_004
    DATA_005


    but it makes things easier and more transparent to the User.
    Problems regarding the 2nd way of doing the QSPI progamming are for example:
    - Where and how does the user specify the [Configuration]?
    - Is the current QSPI controller configuration the configuration that is used afterwards?
    - In stand-alone mode / mass production, what should be done if the QSPI controller configuration differs from the prepared one?
    - It would be necessary the have a user interface for each QSPI
    - We would need to adapt the J-Link flash loader to be able to alter the data file for any QSPI configuration on the fly. This would also slow down programming speeds
    - [...]


    Best regards,
    Niklas
    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.
  • BOOTROM always uses 64LE, this is a hardware implementation of BOOTROM.

    BOOTROM is able to program the flash by itself using communication procedure with a host.
    Looks like the 64LE mode is forever.

    Segger is used only for debug purposes and the convenient way is just to pass "load a.elf' command to the gdb.
    The rest is handled by jlink.
    In this case application can't be run without jlink (dword swap issue).

    Doing a special dance with dword swap in the code/data sections in the ELF file is a bit strange
    8o

    The goal is to have XIP from QSPI of whole application.

    So as a resume it would be great to have more flexible QSPI configuration from the user side or have more detailed
    instructions about custom flash loader in the doc.


    PS. right now I'm trying to bring up my custom loader for the qspi.
    PPS. no need to invent a supporting a lot of modes inside jlink.
    any mode is handled by qspi controller.

    Two QSPI chips in parallel mode or 1 QSPI chip in a single mode the PAGE WRITE command is the same, but the data layout is different.
    Verify command will be different also.

    The post was edited 1 time, last by dark1st ().