Friday, December 15th 2017, 8:42pm UTC+1

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Date of registration: Aug 18th 2017

Posts: 15

1

Friday, September 8th 2017, 1:10am

[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?

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 467

2

Friday, September 8th 2017, 9:58am

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

Date of registration: Aug 18th 2017

Posts: 15

3

Friday, September 8th 2017, 5:19pm

Running the JLinkDLLUpdater.exe in the V6.18c didn't help. Ozone V2.46b was already using V6.18c.


What do you recommend as the next thing to try?

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 467

4

Monday, September 11th 2017, 3:25pm

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

Date of registration: Aug 18th 2017

Posts: 15

5

Tuesday, September 12th 2017, 12:55am

JLink_Eclipse.log.txtJLink_Ozone.log.txtSTM32F769I_Eval_QSPI.zip

Hi Nino,

I've attached the files you requested. Our application is large, the stripped elf is ~13Meg, the symbol only elf is ~100M. I had to delete some of the Eclipse log in order to upload to the forum.

Note also at the end of the logs that the connection is lost to the CPU. This will be a follow on question in another forum post.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 467

6

Tuesday, September 12th 2017, 2:19pm

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:

Quoted


<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

Date of registration: Aug 18th 2017

Posts: 15

7

Tuesday, September 12th 2017, 11:22pm

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.



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

It should look like this:

Quoted








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.
brunobittnersick has attached the following images:
  • Ozone_sample_beforeBranch_2017-09-12_15-45-33.png
  • Ozone_sample_afterBranch_2017-09-12_15-45-33.png
  • Ozone_sample_letItRunThenHalt_2017-09-12_15-45-33.png
brunobittnersick has attached the following file:

Date of registration: Aug 18th 2017

Posts: 15

8

Wednesday, September 13th 2017, 2:50pm

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.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 467

9

Thursday, September 14th 2017, 10:59am

Hello Bruno,

Thank you for the additional information.

Quoted

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: https://wiki.segger.com/Tracing_on_ST_STM32F769

More information about trace setup and troubleshooting techniques please visit: https://www.segger.com/products/debug-pr…tting-up-trace/

Quoted

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

Date of registration: Aug 18th 2017

Posts: 15

10

Thursday, September 14th 2017, 4:33pm

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?

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 467

11

Thursday, September 14th 2017, 6:19pm

Hello Bruno,

Quoted

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

Date of registration: Aug 18th 2017

Posts: 15

12

Thursday, September 14th 2017, 9:47pm


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?

According to http://www.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.

Date of registration: Aug 18th 2017

Posts: 15

13

Thursday, September 14th 2017, 10:35pm



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.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 467

14

Monday, September 18th 2017, 11:01am

Hello Bruno,

Quoted

According to http://www.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.

Quoted

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