Thanks for posting this!
Posts by mwb1100
-
-
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:
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.
-
-
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:
- https://learn.microsoft.com/en-us/windows/…n?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).
-
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 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 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:
-
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.
-
-
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
Display MoreC:\temp>jlink -device STM32F103ZG -if swd -speed 4000 -autoconnect 1 SEGGER J-Link Commander V7.66g (Compiled Jul 7 2022 10:37:30) DLL version V7.66g, compiled Jul 7 2022 10:35:46 Connecting to J-Link via USB...O.K. Firmware: J-Link V10 compiled Jul 22 2022 11:40:29 Hardware version: V10.10 S/N: 600105391 License(s): RDI, FlashBP, FlashDL, JFlash, GDB VTref=3.310V Device "STM32F103ZG" selected. Connecting to target via SWD InitTarget() start InitTarget() end Found SW-DP with ID 0x2BA01477 DPIDR: 0x2BA01477 CoreSight SoC-400 or earlier Scanning AP map to find all available APs AP[1]: Stopped AP scan as end of AP map has been reached AP[0]: AHB-AP (IDR: 0x24770011) Iterating through AP map to find AHB-AP to use AP[0]: Core found AP[0]: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x410FC241. Implementer code: 0x41 (ARM) Found Cortex-M4 r0p1, Little endian. Identified core does not match configuration. (Found: Cortex-M4, Configured: Cortex-M3) FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl[0] @ E00FF000 [0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7 [0][1]: E0001000 CID B105E00D PID 003BB002 DWT [0][2]: E0002000 CID B105E00D PID 002BB003 FPB [0][3]: E0000000 CID B105E00D PID 003BB001 ITM [0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU [0][5]: E0041000 CID 00000000 PID 00000000 ??? Cortex-M4 identified. J-Link>mem 08080000 80 08080000 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 08080010 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 08080020 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 08080030 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 08080040 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 08080050 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 08080060 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 08080070 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ J-Link>erase 08080000 08081fff T-bit of XPSR is 0 but should be 1. Changed to 1. Erasing selected range... J-Link: Flash download: Total time needed: 0.288s (Prepare: 0.102s, Compare: 0.000s, Erase: 0.172s, Program: 0.000s, Verify: 0.000s, Restore: 0.014s) J-Link: Flash download: Flash sectors within Range [0x08080000 - 0x08081FFF] deleted. Erasing done. J-Link>mem 08080000 80 08080000 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080010 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080020 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080030 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080040 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080050 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080060 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080070 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ J-Link>exit
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.
Code
Display MoreSEGGER J-Link Commander V7.70e (Compiled Aug 31 2022 17:08:13) DLL version V7.70e, compiled Aug 31 2022 17:06:50 Connecting to J-Link via USB...O.K. Firmware: J-Link V10 compiled Jul 22 2022 11:40:29 Hardware version: V10.10 J-Link uptime (since boot): N/A (Not supported by this model) S/N: 600105391 License(s): RDI, FlashBP, FlashDL, JFlash, GDB VTref=3.315V Device "GD32F303ZK" selected.
-
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
Display MoreC:\devtrees\cpa-ramfunc>jlink -log just-erase.gd32f303zk.jlink.log -device GD32F303ZK -if swd -speed 4000 -autoconnect 1 SEGGER J-Link Commander V7.66g (Compiled Jul 7 2022 10:37:30) DLL version V7.66g, compiled Jul 7 2022 10:35:46 Connecting to J-Link via USB...O.K. Firmware: J-Link V10 compiled Nov 2 2021 12:14:50 Hardware version: V10.10 S/N: 600105391 License(s): RDI, FlashBP, FlashDL, JFlash, GDB VTref=3.315V Device "GD32F303ZK" selected. Connecting to target via SWD Found SW-DP with ID 0x2BA01477 DPIDR: 0x2BA01477 CoreSight SoC-400 or earlier Scanning AP map to find all available APs AP[1]: Stopped AP scan as end of AP map has been reached AP[0]: AHB-AP (IDR: 0x24770011) Iterating through AP map to find AHB-AP to use AP[0]: Core found AP[0]: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x410FC241. Implementer code: 0x41 (ARM) Found Cortex-M4 r0p1, Little endian. FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl[0] @ E00FF000 [0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7 [0][1]: E0001000 CID B105E00D PID 003BB002 DWT [0][2]: E0002000 CID B105E00D PID 002BB003 FPB [0][3]: E0000000 CID B105E00D PID 003BB001 ITM [0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU [0][5]: E0041000 CID 00000000 PID 00000000 ??? Cortex-M4 identified. // dump some memory J-Link>mem 08080000 80 08080000 = 52 46 55 4E FC 1F 16 00 FC 1F 01 20 00 00 01 20 RFUN....... ... 08080010 = 89 02 01 20 8D 02 01 20 A1 02 01 20 9A 02 00 00 ... ... ... .... 08080020 = 00 00 00 00 FC 1F 00 00 40 28 23 29 63 70 61 2D ........@(#)cpa- 08080030 = 66 6C 61 73 68 63 6F 70 69 65 72 20 76 32 30 2D flashcopier v20- 08080040 = 75 6E 6B 6E 6F 77 6E 20 62 75 69 6C 64 3A 30 20 unknown build:0 08080050 = 53 65 70 20 20 31 20 32 30 32 32 20 30 31 3A 31 Sep 1 2022 01:1 08080060 = 36 3A 32 36 00 00 00 00 00 00 00 00 00 00 00 00 6:26............ 08080070 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ // erase a range that includes that memory J-Link>erase 08080000 08081fff Erasing selected range... J-Link: Flash download: Total time needed: 0.194s (Prepare: 0.097s, Compare: 0.000s, Erase: 0.083s, Program: 0.000s, Verify: 0.000s, Restore: 0.013s) J-Link: Flash download: Flash sectors within Range [0x08080000 - 0x08081FFF] deleted. Erasing done. // erase didn't work J-Link>mem 08080000 80 08080000 = 52 46 55 4E FC 1F 16 00 FC 1F 01 20 00 00 01 20 RFUN....... ... 08080010 = 89 02 01 20 8D 02 01 20 A1 02 01 20 9A 02 00 00 ... ... ... .... 08080020 = 00 00 00 00 FC 1F 00 00 40 28 23 29 63 70 61 2D ........@(#)cpa- 08080030 = 66 6C 61 73 68 63 6F 70 69 65 72 20 76 32 30 2D flashcopier v20- 08080040 = 75 6E 6B 6E 6F 77 6E 20 62 75 69 6C 64 3A 30 20 unknown build:0 08080050 = 53 65 70 20 20 31 20 32 30 32 32 20 30 31 3A 31 Sep 1 2022 01:1 08080060 = 36 3A 32 36 00 00 00 00 00 00 00 00 00 00 00 00 6:26............ 08080070 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ // erase the whole chip J-Link>erase Without any given address range, Erase Chip will be executed Erasing device... J-Link: Flash download: Total time needed: 0.608s (Prepare: 0.070s, Compare: 0.000s, Erase: 0.501s, Program: 0.000s, Verify: 0.000s, Restore: 0.037s) J-Link: Flash download: Total time needed: 1.155s (Prepare: 0.055s, Compare: 0.000s, Erase: 1.062s, Program: 0.000s, Verify: 0.000s, Restore: 0.037s) Erasing done. // full chip erase worked J-Link>mem 08080000 80 08080000 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080010 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080020 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080030 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080040 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080050 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080060 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 08080070 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ J-Link>exit
And attached is the log file in case it shows something helpful: just-erase.gd32f303zk.jlink.log -
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: bad.flash-gd32.jlink.commander.log
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: good-with-erase.flash-gd32.jlink.commander.log
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:
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:
Code
Display Morec:\devtrees\test-bin>flash-gd32.py C:\devtrees\test-bin\test-bin.bin,08080000 SEGGER J-Link Commander V7.66g (Compiled Jul 7 2022 10:37:30) DLL version V7.66g, compiled Jul 7 2022 10:35:46 J-Link Command File read successfully. Processing script file... J-Link>ExitOnError 1 J-Link Commander will now exit on Error J-Link>Connect J-Link connection not established yet but required for command. Connecting to J-Link via USB...O.K. Firmware: J-Link V10 compiled Nov 2 2021 12:14:50 Hardware version: V10.10 S/N: 600105391 License(s): RDI, FlashBP, FlashDL, JFlash, GDB VTref=3.310V Device "GD32F303ZK" selected. Connecting to target via SWD Found SW-DP with ID 0x2BA01477 DPIDR: 0x2BA01477 CoreSight SoC-400 or earlier Scanning AP map to find all available APs AP[1]: Stopped AP scan as end of AP map has been reached AP[0]: AHB-AP (IDR: 0x24770011) Iterating through AP map to find AHB-AP to use AP[0]: Core found AP[0]: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x410FC241. Implementer code: 0x41 (ARM) Found Cortex-M4 r0p1, Little endian. FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl[0] @ E00FF000 [0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7 [0][1]: E0001000 CID B105E00D PID 003BB002 DWT [0][2]: E0002000 CID B105E00D PID 002BB003 FPB [0][3]: E0000000 CID B105E00D PID 003BB001 ITM [0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU [0][5]: E0041000 CID 00000000 PID 00000000 ??? Cortex-M4 identified. J-Link>h PC = 08027744, CycleCnt = 2AD8BC18 R0 = 00000000, R1 = CDCDCDCD, R2 = 80000000, R3 = 08031999 R4 = 6802B4D0, R5 = 00000001, R6 = 6802B4D0, R7 = CCCC0007 R8 = CCCC0008, R9 = CCCC0009, R10= CCCC000A, R11= CCCC000B R12= 08031998 SP(R13)= 20003400, MSP= 200033D8, PSP= 20003400, R14(LR) = 21000000 XPSR = 01000000: APSR = nzcvq, EPSR = 01000000, IPSR = 000 (NoException) CFBP = 02000000, CONTROL = 02, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00 FPS0 = 4A71DF44, FPS1 = 20925D1B, FPS2 = 2010E87E, FPS3 = F69BF462 FPS4 = 64DB8277, FPS5 = E3EB6079, FPS6 = 23C78804, FPS7 = D577FD7F FPS8 = DAC9F9F9, FPS9 = 502666CE, FPS10= 5B6F31D3, FPS11= 7A6FC353 FPS12= FE89A50F, FPS13= 842683E1, FPS14= 842FBC66, FPS15= 2F0DAE5F FPS16= 6E59BC16, FPS17= 5E86E6ED, FPS18= ADB0E7B1, FPS19= 934CF140 FPS20= FFF56F97, FPS21= 00EEBE6F, FPS22= CF3423CD, FPS23= B975F6E5 FPS24= 849C7D2F, FPS25= AEED31C8, FPS26= 1ABDC822, FPS27= 9B88E032 FPS28= 4EBE14CF, FPS29= A0EA7FD2, FPS30= B97B02D2, FPS31= 4ADCCC57 FPSCR= 00000000 J-Link>LoadFile C:\devtrees\test-bin\test-bin.bin,08080000 Downloading file [C:\devtrees\test-bin\test-bin.bin]... Error while programming flash: Programming failed. Script processing completed. resetting... Done in 0 min 3.574 sec
And here is the J-Link command file that the script produced for that session: -
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.