Posts by mwb1100

    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).

    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 don't know what hooks Segger's C++ library has for providing an implementation for the the std::mutex class, but I'd assume the docs have details (or if not someone from Segger could maybe chime in here).

    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:


    Code
    "C:\Program Files\SEGGER\JLink\JFlash.exe" -openprjmytest3.jflash /min /wait -connect -readrange0x10078000,0x1007FFFF

    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 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 need to be on a line by themselves, but some .ini parsers support comments on the same line as a section heading or a setting.

    For example:


    Code
    [FILES]
    DataFile = "Flasher1.dat"    ; would this be a valid comment?
    ConfigFile = "Flasher1.cfg"

    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:


    However, I don't think that's an effective workaround for me because this project uses flash up to the end of the GD32F303ZK's flash address space to store data so I need the tool to be able to write to flash above the 1MB limit that the STM32F103ZG has.

    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.

    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:


    And attached is the log file in case it shows something helpful: just-erase.gd32f303zk.jlink.log

    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:

    Code
    ExitOnError 1
    Connect
    h
    
    
    LoadFile C:\devtrees\test-bin\test-bin.bin,0x08080000
    
    
    r
    exit

    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 .hex) file corresponds to. That means to update a single binary (this project flashes 3 binaries to various parts of the flash) I have to erase the chip then flash all 3 binaries, which is error prone when I have several versions of each binary that can be flashed.

    The `erase` command can be used to erase only a selected range of flash, but the script file would need to figure out what the appropriate range is and it doesn't do that - it only has the capability to erase the entire chip.


    Is there a way to tell `LoadFile` to erase the area of flash that it will be updating? I couldn't see such an option or setting in https://wiki.segger.com/J-Link_Commander

    Here is an example session trying to flash a non-erased chip:


    And here is the J-Link command file that the script produced for that session:

    Code
    ExitOnError 1
    Connect
    h
    
    
    LoadFile C:\devtrees\test-bin\test-bin.bin,08080000
    
    
    r
    exit

    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 https://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 another cpp file. That won't work. Get rid of the prototype and put the definition of the function template in the header.

    If that doesn't solve your problem, then:

    Does this compile and link with gcc/g++ compiler (use mingw if on Windows) targeting the platform you're running it on (ie., not a cross compile) from the command line?

    If so, then it will work in SES.

    If not copy/paste the command line(s) and output (as text, please, not a screenshot). And specify exactly what code is in what file and how the files are #included.