Search Results

Search results 1-15 of 15.

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

  • Quote from SEGGER - Nino: “ 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.

  • Quote from SEGGER - Nino: “ 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 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.

  • Thanks you. You can consider this request solved. For informational purposes: nJTRST is not connected to TRACE connector, nor is JTDI which is JTAG signal not needed for SWD.

  • Hi Niklas, Thanks for getting back to me. The most recent email was sent to support@segger.com Sep. 6 2017 with subject "J-Trace PRO and STM32F765NI". Our custom board uses STM32F765NI, not STM32F769NI. There was also an email Aug 18 2017 "Re: J-Link: connection to target device lost" which was a follow on to an original request of Jul 11 2017 that you may have considered solved. We did get responses from segger.com/support/technical-support/. I understand it has been the holiday period. Right, …

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

  • The other thread started as an issue with loading code into QSPI. I felt this tracing issue is separate from QSPI loading, so I made a new forum post. We don't use any low power modes and the JTAG/TRACE pins are not changed from their Alternate Function 0 settings.

  • I sent an email to support several weeks ago and heard nothing. It was for more than the schematic, now I have several forum entries to try to get my problems solved. I will send email again. BTW, there are 2 resets involved with JTAG/SWD/TRACE. nRST for the processor core and nJTRST for the JTAG "port". J-Link/J-Trace documentation gives the impression the nJTRST is optional, I want to see if it's used on CM Ref Board. And to make things more confusing, these signals have different names with d…

  • We have STM32F769_EVAL board with a large (12Meg) application that sometimes loses connection with J-Link. We have now purchased a J-TRACE PRO in order to get streaming trace in order to see why this is happening. How can I setup OZONE (currently using V2.46b), or any other tool, to get most up to date execution trace? In ozone, when I try to halt execution, I only get the message "J-Link: CPU could not be halted", and J_Link (V6.18c) only shows JLINK_Halt() with no other information.

  • I know the Cortex-M Trace Reference Board is very simple, but I'd like to compare the JTAG/Trace connection on our proprietary board with the reference board. I'm specifically curious if the nJRST pin is connected for TRACE purposes. I'm having problems tracing a large application on our board. I can't find the schematic on the Segger website.

  • 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 the STM32F76x Reference Manual I found the following statement: ST Document RM0410 Section 44.15.1 ETM General description, page 1870 Note: N.B: Cortex-M7 ETM is compliant with ARM ETM architecture v4, which programming model is not backward compatible with Cortex-M4 ETM one (ETM architecture v3.5). Does the J-Trace support ARM ETM architecture v4?

  • 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 a…

  • forum.segger.com/index.php/Att…b75f66bc5dd040a422ac6c97cforum.segger.com/index.php/Att…b75f66bc5dd040a422ac6c97cforum.segger.com/index.php/Att…b75f66bc5dd040a422ac6c97c 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 po…

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

  • 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 di…