Search Results

Search results 1-20 of 49.

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

  • Adding that watch does not cause a crash in 2.56w . I have had a lot of other problems with versions > 2.60 , hangs and crashes when resetting and reflashing. Looking forward to things getting stabilized.

  • One follow-on here: If I try to enter in a watch of *(uint32_t*)0x200221D8 , Ozone crashes immediately. Version 2.60e running on OSX 10.14 Mojave.

  • Alright, for a little more exposition, the error can be captured in a simple printf of the address before and after the function call. e.g.: C Source Code (1 line) Looking at the disassembly, this compiles to: Source Code (4 lines)Where 0x080B0070 is the address of the const string. So it looks like R7+0x10 = 0x2001C090 is storing the address of the variable. In the suspicious function, R7 is getting stacked, but then the incorrect value in unstacked, ergo my suspicious function must be clobberi…

  • I can't profile the elf, since it would contain our proprietary source. Maybe if we put an NDA in place? But then you would need very specific hardware for the ELF to even run. This issue also happens when using gdbserver + eclipse + GNU Arm Eclipse plugin suite; the behavior is reproduced in the Eclipse watch window. How is Ozone/Jlink even resolving the variable name to a location? There isn't a symbol in the ELF for it, as far as I can see ...

  • I am debugging a project with Ozone, and I am seeing something that I do not understand the cause of. It may have a clear cause ... or it may be an Ozone bug. I'm unsure. In the code that I debugging, I am setting a watch on a stack variable (a struct), and Ozone reports the location as 0x2001C090. The size is correctly reported as 121 bytes. After a returning from the call to a function that is suspected to contain bugs (by step-over before entering), the location reported by Ozone changes to 0…

  • Interesting. Will J-Link support OpenFlashLoader loaders, if they are added to the XML file? I remapped the external flash bank to a base of 0xC0000000, which is unused on my micro, in both the FlashDev.c and in the XML file. J-Flash works as expected when operating from these addresses, but J-Link commander only returns "Could not read memory" when trying: mem 0xC0000000,0x1FF

  • I have a setup that I will be deploying soon that is using J-Flash to do an operation with a custom flash loader. These are just last details, to get it set up in the "best" way: Presently, I can get J-Flash to start, do production programming, and then exit with: JFlash.exe -loadprj.\myproject.jflash -auto -exit and I can make JFlash run in "hidden" mode with" JFlash.exe -loadprj.\myproject.jflash -auto -hide -exit But when using -hide, there is nothing shown on-screen at all. Is there a way to…

  • Hrm, OK. I did misunderstand the approach, and I thought I needed to define a new representative device, rather than just add a new FlashBank to the existing part. Oddly, the JLinkDevices.xml file did not already have an entry in it for the STM32F412VE. But I upgraded to the JLink package 6.34b, which does now have an entry there for STM32F412VE, including a loader for a memory mapped QSPI. I added the line for the flash bank info into that <Device> entry: <FlashBankInfo Name="128MbSPIFlash" Bas…

  • Eh I am getting closer with we lap we do here. No need to go to contract just yet. So, using that option, plus a few more, I can get the project to build. This is what my Placement_release.xml contains: XML Source Code (14 lines)Obviously, this is not quite right because it is pulling in the entire CRT, setup, stack and heap regions, etc. I will revise and try to take out all the CRT and use just the bare minimum of setup. But we will need clocks to be set up and running for this to work ... the…

  • Whoops ... that was because I added in the original template project (out-of-source) so I could do side by side comparisons. New version is attached with that project removed, so now it should work. I am not certain what is causing code that can't ultimately be linked to be pulled in. It looks like udivmod for a uint64_t type is what cannot find a home? Can uint64_t types and/or modulos not be used, since they don't map directly to instructions and have to pull in a math function from libc? That…

  • Does the Ozone trace facility support the Micro Trace Buffer in M0+ cores? If so, will it work with an ST-Link onboard converted to J-Link STLink V21 ?

  • Zip file is attached. Notably, if I modify the plain template with only the change to use uint64_t or, as just an example, a sqrtf() in one of the OFL functions (like EraseSector), then I will get the same link error when building in the Release config, but not the Debug config.

  • @SEGGER - Nino , @SEGGER - Erik I am still stuck on this linking step.

  • @SEGGER - Erik ah, thanks. I am inching closer to this working ... but unfortunately, the "Release" build does not work in Segger Studio. I am not that familiar with the Segger IDE, so maybe I am missing something obvious. When I build the Release build, I get the error: Output/Release/Exe/flash_loader.elf section `.text.libc.__int64_udivmod' will not fit in region `UNPLACED_SECTIONS' Looking at the generated linker script, it is reporting that the length of the UNPLACED_SECTIONS is zero: UNPLAC…

  • The FAQ section there makes reference to a Comapre() function, although there is no function stub for that in the OpenFlashLoader template ...

  • @SEGGER - Nino , I have some further questions about this. Does the OpenFlashLoader template generate RAMCodes that are supposed to work with JFlash, to be specified with the "Use custom RAMCode" option? Looking at the documentation and some of the details, it seems like maybe it is not? For example, the template is provided with instructions to generate an ELF, but then the "Use custom RAMCode" only allows for hex, srec, bin, etc. And I don't see any way that the DLL could call into a binary or…

  • Our target device is an STM32F412. For the setup I am looking at, I don't believe J-Flash SPI will apply: we only have an SWD connection to the micro available, and for a variety of reasons, adding another station/jig that would do J-Link->SPI port directly to our current design & process isn't an option. But I would like to zero in on a good solution here, since this will likely become the standard for how I do manufacturing in the future! My understanding was that to use J-Flash in a JLink->mi…

  • I am adding support for GD25Q128CSIG and MX25L12835F chips. A fair number of other parts should fall under the same command set, too, which appears to be common for these 8-pin serial flash parts. So, it looks like I misunderstood what that structure was really defining? Per your description, it sounds like it is describing the types of geometry in the flash, rather than an enumeration of each sector present. The chips do have a uniform geometry of 4KB "sectors" (minimum erase quanta), but then …

  • I am attempting to implement the OpenFlashLoader for a 128MBit SPI serial NOR flash. This is a common architecture that I use in my design, so being able to read a full image and then program a full image via JFlash would be *great*. I presently have to "ferry" data into the flash chip ~512Kbyte at a time via the main micro flash and the serial flash image converted into C arrays. And since many of the 8-pin serial NOR flash chips have a common set of basic read/write commands, this should cover…

  • Yes, the ultimate goal is to avoid very long reflash times of the physical on-chip flash. Now that I think about it, it would be equivalent to just using a remapped flash address block, too. I only thought of it as "RAM emulation" just because that trick sometimes works for smaller programs and happens to exist in the makefile in the SDK that I am using, where they can be built to locate entirely in the RAM section. As far as I understand it, I think this is how how "ICE" tools used to work way …