Search Results

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 …

While working with large (800K+) images on a Cortex M4, I often find myself waiting a *long* time for the chip to erase and flash. If a small piece of code is changed, it can cause everything to be shifted in the flash address space, and thus require a major erase & reflash, even with the SEGGER option to only reflash the sectors as needed. Is there any ability to emulate a micro's entire RAM via the JLink? There would be a big runtime speed penalty, like flash with a lot of wait states, but it …

Well ... but is it actually implemented now? It doesn't seem to be in 2.56l or 2.57b. I am eagerly awaiting it.

Another follow-up, given the hard limit: Is there ANY solution to get a longer instruction trace out presently? Even a command line logger that you might be able to share? Or something with GDB? I have a situation where a vendor has supplied a closed-source library with a bug that they claim they are working to fix. I have a reproducible fault case here, and I would like to see what execution looks like as it heads into this fault case. Given that, there may be workarounds I can outside the libr…

Ozone is 2.56g OSX platform, version 10.13.4 Target is STM32F412VGT6 Adapter is J-Trace Pro Custom hardware (since NO boards make ETM available) ELF file I can't provide. I'll try and generate a MWE some time soon. It is based on the Cypress WICED SDK. ThreadX is running in the program, and I have previously posted about Ozone not correctly unwinding the context switches, so that may possibly be related. This machine has 16GB RAM, and chronically low HD free, ~10-12 GB, so I am not sure how it g…

OK, great. On the topic of resource management, I usually have to quit Ozone if I leave a program running with Trace on for more than an hour or so. And Activity Monitor reports Ozone using > 100GB memory (only have 16GB physical memory). Screenshot attached.

OK, as a follow-up: I just added a subsection to the #ifdef __TI_ARM__ section that uses the trivial defines from the bottom of the file: p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco} span.s1 {color: #931a68} #define SEGGER_RTT_LOCK() #define SEGGER_RTT_UNLOCK() which does work, tested on actual CC1310 silicon running debug from CCS w/ JLink. This is with the understanding that it will not be thread or multi-stream safe. But it works for stream 0, which is all I needed to exfiltrat…

I am using a J-Trace Pro with a J-Trace Pro, with Ozone. When I look at the timeline view, it looks like the history only goes back to 10M instructions. On a 100MHz cpu, that's not much time! Is this a hard limitation? My understanding was that streaming trace should give me "unlimited" history, or as much as my PC memory/hard drive can store. Then a similar question is whether or not there is a history horizon on what is going into "Code Profile" output, particularly the "Load" column. I am dea…