[SOLVED] OZONE how to load to QSPI flash on STM32F769_EVAL board

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

  • [SOLVED] OZONE how to load to QSPI flash on STM32F769_EVAL board

    When I use eclipse (neon.1) and Ozone 2.46b with JLink 6.18c I am able to load my image that is linked for QSPI execution into that address space at 0x90000000. This is because I have an entry in my JLinkDevices.xml file:
    <ChipInfo Vendor="ST" Name="STM32F769NI" Core="JLINK_CORE_CORTEX_M7" />
    <FlashBankInfo Name="QSPI Flash" BaseAddr="0x90000000" MaxSize="0x01000000" Loader="STM32F769I_Eval_QSPI.elf" LoaderType="FLASH_ALGO_TYPE_OPEN" />
    </Device>
    and the proper FLASH loaded in the JLink 6.18c directory.
    When I look at the J-Link Control Panel, in the flash tab, I see the flash bank named CMSIS with the proper BaseAddr, etc. Along with the internal flash bank named Internal(Turbo).
    Ozone doesn't do this, apparently. When I connect with Ozone, I can tell the flash isn't loaded because my application is large and the load seems to take no time, vs. minutes with Eclipse.
    When I look at the J-Link Control Panel, in the flash tab, I only see the internal flash bank named Internal(Turbo).
    How can I get Ozone to load properly into my external QSPI flash, the same way Eclipse does?

  • Hello Bruno,

    Thank you for your inquiry.

    Could you try running the JLinkDLLUpdater.exe in the V6.18c install folder and make sure the Ozone V2.46b path is selected when selecting next?
    This should fix your problem.

    Best regards,
    Nino
    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 Bruno,

    Could you attach the flash loader .elf file you are using so we can try to reproduce the issue?
    For analysis reasons could you also please attach a J-Link log file for each case?
    One when you download with eclipse and one when you use Ozone.
    How to save a log file is explained here.

    Best regards,
    Nino
    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 Bruno,

    Thank you for providing the files.
    I set up a example project in our IDE Embedded Studio (can be used for free for evaluation) with the same hardware you were using including the QSPI flash loader provided.
    I had no issues whatsoever programming the QSPI flash and debugging the application running there.
    For reference you can download the example project here.
    I tested it on a STM32F769-EVAL board. You can also rebuild the project by using Embedded Studio or simply run the .jdebug file with Ozone with the precompiled output file.

    While looking over the thread again i noticed that your JLinkDevices.xml entry looked incomplete.

    It should look like this:


    <Device>
    <ChipInfo Vendor="ST" Name="STM32F769NI" Core="JLINK_CORE_CORTEX_M7" />
    <FlashBankInfo Name="QSPI Flash" BaseAddr="0x90000000" MaxSize="0x01000000" Loader="STM32F769I_Eval_QSPI.elf" LoaderType="FLASH_ALGO_TYPE_OPEN" />
    </Device>


    The opening <Device> seems to be missing. Was this a copy paste error or is it missing in the JLinkDevices.xml as well? That might already explain why the QSPI is not initialized correctly.
    Also the entry Loader=... sets the relative path to the flash loader .elf file. Make sure the .elf file is actually in the same folder as the JLinkDevices.xml.

    In my earlier reply i asked you to run the DLLUpdater from the install folder. The reason for this was not to update the DLL but to update the JLinkDevices.xml reference path.
    In the Ozone install folder you will find the following file if the reference to the JLinkDevices.xml could be set: JLinkDevices.ref

    Open that file in a text editor and check if the path is pointing to the folder where your edited JLinkDevices.xml is.
    Otherwise Ozone can't use the QSPI flash loader as it does not know where to find it.

    Best regards,
    Nino
    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.

  • Hi Nino,

    I tried your sample project, thank you for that. It loads, or rather, appears to load. While stepping at the assembly level noticed a step over an unconditional branch when the PC should have gone elsewhere. I've included some screen shots of this. I also let the application run, then halt it soon after, and the CPU is executing around address 0x92000000 which is all zeros. Note also that most of the registers are zero. It appears only opcodes zero were executed. The trace window also appears to be incorrect. I've included a screen capture of this. I also include the jlink.log file.

    SEGGER - Nino wrote:




    While looking over the thread again i noticed that your JLinkDevices.xml entry looked incomplete.

    It should look like this:








    The opening seems to be missing. Was this a copy paste error or is it missing in the JLinkDevices.xml as well? That might already explain why the QSPI is not initialized correctly.
    Also the entry Loader=... sets the relative path to the flash loader .elf file. Make sure the .elf file is actually in the same folder as the JLinkDevices.xml.

    In my earlier reply i asked you to run the DLLUpdater from the install folder. The reason for this was not to update the DLL but to update the JLinkDevices.xml reference path.
    In the Ozone install folder you will find the following file if the reference to the JLinkDevices.xml could be set: JLinkDevices.ref

    Open that file in a text editor and check if the path is pointing to the folder where your edited JLinkDevices.xml is.
    Otherwise Ozone can't use the QSPI flash loader as it does not know where to find it.


    Yes, it was a cut/paste error on my part. I did run the DLLUpdate even though the latest DLL was being used, I have the JLinkDevices.ref file and it points to the right place. My application still doesn't load.
    Images

    • Ozone_sample_beforeBranch_2017-09-12_15-45-33.png

      263.17 kB, 1,920×1,080, viewed 858 times

    • Ozone_sample_afterBranch_2017-09-12_15-45-33.png

      261.17 kB, 1,920×1,080, viewed 693 times

    • Ozone_sample_letItRunThenHalt_2017-09-12_15-45-33.png

      259.93 kB, 1,920×1,080, viewed 771 times
    Files

  • Hello Bruno,

    Thank you for the additional information.

    I should mention that I'm connected to the TRACE port on the STM32F769_EVAL board, not the JTAG port. My ultimate goal is to be able to trace using the J-Trace PRO.


    In that case i recommend using our trace example project from our wiki for that particular board to get a feeling for the trace features: wiki.segger.com/Tracing_on_ST_STM32F769

    More information about trace setup and troubleshooting techniques please visit: segger.com/products/debug-prob…hnology/setting-up-trace/

    I tried your sample project, thank you for that. It loads, or rather, appears to load. While stepping at the assembly level noticed a step over an unconditional branch when the PC should have gone elsewhere.


    You are correct i am seeing the same behaviour. May i ask where you got the flash loader from? Did you create it yourself or is if from ST directly?
    Because i suspect that there seems to be an issue with the flash loader code in this case.

    Best regards,
    Nino
    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.

  • Thanks Nino,

    I will study the two links you gave about tracing on STM32F769.

    I created the flash loader myself with assistance from Segger Support several months back. I will check my work. I was told that QSPI loading support for STM32F769 would be supported directly in J-Link software, do I need to ask Support for the official STM32F769 QSPI Flash loader?

  • Hello Bruno,

    I created the flash loader myself with assistance from Segger Support several months back. I will check my work. I was told that QSPI loading support for STM32F769 would be supported directly in J-Link software, do I need to ask Support for the official STM32F769 QSPI Flash loader?


    The "official" flash loader is shipped with the latest V6.20 version but it is currently only been tested for a STM32F746NG eval board.
    So for the STM32F769 some adjustment will be necessary.

    I noticed that with your flash loader you are setting the QSPI flash to 64 MByte, but the STM32F769_EVAL is only equipped with 16 MByte. Is that on purpose?

    Best regards,
    Nino
    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 - Nino wrote:



    The "official" flash loader is shipped with the latest V6.20 version but it is currently only been tested for a STM32F746NG eval board.
    So for the STM32F769 some adjustment will be necessary.

    What adjustments are needed? I looked at the schematic, it appears the same pins are used as with the 769 eval board. And it appears in the JLinkDevices.xml. But I did have a problem with Eclipse and V6.20 GDB Server.

  • Hello Bruno,

    According to st.com/en/evaluation-tools/stm32f769i-eval.html, it comes with 512Mbit QSPI. I was using the FlashAlgo code I got originally from Segger. I've also built and run the FlashAlgo for 16 and 32 MBytes.

    You are correct. Sorry i was looking at the wrong IC.

    What adjustments are needed? I looked at the schematic, it appears the same pins are used as with the 769 eval board. And it appears in the JLinkDevices.xml. But I did have a problem with Eclipse and V6.20 GDB Server.


    According to the Wiki article the used pins are different from the STM32F769I_EVAL

    746 uses:
    QSPI_CLK PB2
    QSPI_CS PB6
    QSPI_D0 PD11
    QSPI_D1 PD12
    QSPI_D2 PE2
    QSPI_D3 PD13

    769 uses:
    QSPI_CLK PB2
    QSPI_CS PB6
    QSPI_D0 PF8
    QSPI_D1 PF9
    QSPI_D2 PF7
    QSPI_D3 PF6

    So you can use the project from the Wiki, adjust the Pin init and you should be good to go.

    Edit: I found the reason why the reference project i send you was not loading the application properly. It was missing a QSPI init.
    Does your project have a QSPI init? If not this is most likely the reason why you cannot run an application from your QSPI flash while debugging with Embedded Studio or Ozone.


    Best regards,
    Nino
    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.