Search Results

Thanks for posting this!

Could you post the assembly file you are using to test? I will try to find the time this weekend to try it myself as this has raised my curiosity for whatever reason (I don't imagine I'll be able to explain anything though). Also, which Embedded Studio version are you using just in case that matters?

I am no ARM assembly expert, but the ARM documentation page for the rrx instruction shows the syntax as: Source Code (1 line)So for variant #4 you should try: rrxseq r1, r0 and see if that works on the Segger toolchain. Of course this wouldn't explain why GNU rejects #3 and accepts #4.

If you make a patch to handle null strings, I suggest doing what gcc, msvc, and clang do: print "(null)" instead of printing nothing.

That file path has 266 characters. You might be running into a limitation that Windows has had for a long time with a maximum of 260 characters for a pathname in many cases. See this Microsoft article for more details and a possible workaround: - learn.microsoft.com/en-us/wind…-limitation?tabs=registry

I am using IAR's toolchain but use Segger tools in general so I lurk on the forum.

I would think that Segger would have some supported way of customizing how the mutex is implemented, so that you could integrate it into an RTOS that is not supported out-of-the-box. But I'm not using Embedded Studio so I'm not sure what that mechanism is (or even if it actually exists - I'm just speculating).

Quote from CheMax: “because even on a single-core controller, interrupts can occur, which means that mutexes are also needed in single-threaded mode ” To implement a mutex that handles interrupts on a single-threaded system all you need to do is have the mutex disable interrupts when a mutex is owned and re-enable them when the mutex is freed. If the mutex must support nesting then a counter or similar must be incorporated so that interrupts are re-enabled only when the last mutex is freed. I do…

Remember that Segger's command line utility options have the unusual requirement that parameters to options must follow the option with no whitespace or punctuation. Try this command line: Source Code (1 line)I can't guess a reason why the utility interprets "-readrange,0x10078000,0x1007FFFF" as a 4 byte read starting from 0x10078000 other than it's confused by that first comma.

I don't know about the message but unexpected code jumps (and other debugger weirdness) is often caused by debugging optimized builds, where the generated code doesn't line up with the source code because of the transformations the optimizer performs. Make sure you are debugging a build that has optimizations turned off.

I don't find a mention of comments for FLASHER.INI in the Flasher User Guide. Experiments show that It seems like pretty much anything that isn't an expected section heading or setting value is ignored (and therefore could be considered a comment). But in order to avoid problems with a future firmware update, I wonder if there is an undocumented support for an actual comment? Ini files usually use a semi-colon to introduce a comments, but sometimes a '#' is used instead. Also sometimes comments …

Post info on the tool chain you are using to create the ELF file. There is usually a way to get the tool chain to also output a binary or hex file that would be a snap for JLink commander/JFlash to flash.

The J-Link v7.80 software fixes the problem. Thanks!

One more clue: Since the GD32F303 is a close clone of the STM32F103 (it's actually more like the STM32F103 than it is the STM32F303), I tried connecting to it as an STM32F103ZG. The F103ZG has 1MB of flash so the flash pages in the range 0x08080000 - 0x08081ffff exist on that chip. Telling jlink.exe that it's connecting to an STM32F103ZG makes the erase operation work: C Source Code (64 lines) However, I don't think that's an effective workaround for me because this project uses flash up to the …

I just tried updating the J-Link software package to v7.70e. This also resulted in the J-Link's firmware being updated. The test performs exactly the same (except that the erase command does a reset now as explained in the release notes). The erase of a memory range still doesn't actually do the erase. Source Code (11 lines)

I should have thought to do this before. Here's an annotated manual jlink session that gets the script out of the picture and just tries to erase a couple sectors of flash: C Source Code (98 lines) And attached is the log file in case it shows something helpful: forum.segger.com/index.php/Attachment/5269/

Keep in mind that there is also JFlashLite which will perform basic flashing of devices on all J-Link units including EDU (I'm pretty sure). Some of the people I work with prefer it because all they want to do is flash a file to a device and JFlashLite does that with a much simpler GUI.

As requested, here is a log of a failing session: forum.segger.com/index.php/Attachment/5264/ And here is a log of a session that works, the difference being that the command file used performs a full chip erase before the loadfile command: forum.segger.com/index.php/Attachment/5265/ Thank you for looking at this

To flash an GD32 device I'm working with, I use a script that writes a temporary J-Link Commander "command" file (or whatever the correct term is) that includes the LoadFile command to flash the .bin or .hex file. An example command file might look like: Source Code (8 lines)The problem is that this fails if there is already data at address 0x08080000. If I erase the flash first it works great, but the script only knows how to erase the entire chip, not just the area of flash that the .bin (or .…

First off: a prototype for a function template is almost never necessary or used because any caller of the function template needs to have the complete definition in order to get the particular function template instantiated. See isocpp.org/wiki/faq/templates#templates-defn-vs-decl So this question is almost certainly not really an SES question but a general C++ question. I suspect that you have the prototype in a header that is being included and the definition of the function template in anoth…