<![CDATA[EmBitz - Development]]> https://www.embitz.org/forum/ Mon, 06 Jul 2026 21:25:23 +0000 MyBB <![CDATA[Flashing main application overwrites bootloader for STM32F413 (solved elf reader bug)]]> https://www.embitz.org/forum/showthread.php?tid=237 Tue, 23 Jun 2026 13:58:59 +0200 matsb]]> https://www.embitz.org/forum/showthread.php?tid=237
We recently ported from STM32G473 (natively supported by EmBitz/EBlink) to STM32F413 (not natively supported). So I added CPU ID 0x463 and the new 1.5 MByte memory map to EBlink scripts. Attached .zip files for EBlink version 6.21.

The linker scripts memory map looks like this:

Code:
MEMORY
{
  PAGE0            (rx) : ORIGIN = 0x08000000, LENGTH = 16K                  /* FLASH page 0                                */
  BOOTLOADER_START (rx) : ORIGIN = 0x08000000, LENGTH = 16K - 20              /* Bootloader startup code + interrupt vectors  */
  BOOTLOADER_FW_ID (rx) : ORIGIN = 0x08003FEC, LENGTH = 20                    /* Bootloader firmware identification block    */
  PAGE1            (rx) : ORIGIN = 0x08004000, LENGTH = 16K                  /* FLASH page 1 - Misc parameters              */
  PAGE2            (rx) : ORIGIN = 0x08008000, LENGTH = 16K                  /* FLASH page 2 - Misc parameters              */
  MAINAPP_FLASH    (rx) : ORIGIN = 0x0800C000, LENGTH = 16K + 64K + (10 * 128K) /* Main Application FLASH memory 1360 kByte  */
  BOOTLOADER_FLASH (rx) : ORIGIN = 0x08160000, LENGTH = 128K                  /* Bootloader FLASH memory 16 + 128 kByte      */
  OPT_B            (rw) : ORIGIN = 0x1FFFC000, LENGTH = 16                    /* Options bytes single-bank                    */
  RAM            (rwx) : ORIGIN = 0x20000000, LENGTH = 320K                  /* Main RAM memory                              */
}

I.e. Bootloader lives on pages 0 and 15.
Misc. user data is on pages 1...2.
Main application lives on pages 3...14.

When compiling both Bootloader and Main application, the produced .hex files are correct. When flashing the .hex files with STM32CubeProgrammer, it will write to the expected pages and leave the other untouched. This is working correctly.

When writing Bootloader with EmBitz / Flash / Flash target, everything goes fine.
But when writing Main application, also page 0, 1, and 2 are overwritten. When looking more closely at those 3 overwritten pages, they seems to contain the raw content of the main application .elf file. For example the ".ELF" signature is stored at address 0x08000000. Attached picture of the beginning of 0x08000000.

This happens for both EmBitz 2.63 and 2.65 that I have been using.

Any help appreciated!


Here is the EBlink output when writing Bootloader:

EBlink version 6.21-[299] by Gerard Zagema

Interface USB# : 54FF6A066684565547522187
Interface type : STlink/V2
Target voltage : 3.24V
Interface speed: 4000KHz

Target detected: Cortex-M4 (r0p1) with FPv4_SP
HW breakpoints : 6
HW watchpoints : 4
Fault unwind  : Active (level 2)
STmicro family : STM32F413
Detected FLASH : 1536KB
Configured RAM : 320KB
Reset: system
Checking current flash content
Reset: system
Flashing sector  0, address: 0x08000000, length: 0x4000
Flashing sector 15, address: 0x08160000, length: 0x1710C
Flash verify
Flasher starts target
Reset: system



Here is the EBlink output when writing main application:

EBlink version 6.21-[299] by Gerard Zagema

Interface USB# : 54FF6A066684565547522187
Interface type : STlink/V2
Target voltage : 3.24V
Interface speed: 4000KHz

Target detected: Cortex-M4 (r0p1) with FPv4_SP
HW breakpoints : 6
HW watchpoints : 4
Fault unwind  : Active (level 2)
STmicro family : STM32F413
Detected FLASH : 1536KB
Configured RAM : 320KB
Reset: system
Checking current flash content
Reset: system
Flashing sector  0, address: 0x08000000, length: 0x4000
Flashing sector  1, address: 0x08004000, length: 0x4000
Flashing sector  2, address: 0x08008000, length: 0x4000
Flashing sector  3, address: 0x0800C000, length: 0x4000
Flashing sector  4, address: 0x08010000, length: 0x10000
Flashing sector  5, address: 0x08020000, length: 0x20000
Flashing sector  6, address: 0x08040000, length: 0x20000
Flashing sector  7, address: 0x08060000, length: 0x20000
Flashing sector  8, address: 0x08080000, length: 0x20000
Flashing sector  9, address: 0x080A0000, length: 0x3090
Flash verify

.zip   STM32F413_EBlink_6.21_scripts.zip (Size: 3.82 KB / Downloads: 3)

.png   after_application_flashing.png (Size: 59.41 KB / Downloads: 28) ]]>
We recently ported from STM32G473 (natively supported by EmBitz/EBlink) to STM32F413 (not natively supported). So I added CPU ID 0x463 and the new 1.5 MByte memory map to EBlink scripts. Attached .zip files for EBlink version 6.21.

The linker scripts memory map looks like this:

Code:
MEMORY
{
  PAGE0            (rx) : ORIGIN = 0x08000000, LENGTH = 16K                  /* FLASH page 0                                */
  BOOTLOADER_START (rx) : ORIGIN = 0x08000000, LENGTH = 16K - 20              /* Bootloader startup code + interrupt vectors  */
  BOOTLOADER_FW_ID (rx) : ORIGIN = 0x08003FEC, LENGTH = 20                    /* Bootloader firmware identification block    */
  PAGE1            (rx) : ORIGIN = 0x08004000, LENGTH = 16K                  /* FLASH page 1 - Misc parameters              */
  PAGE2            (rx) : ORIGIN = 0x08008000, LENGTH = 16K                  /* FLASH page 2 - Misc parameters              */
  MAINAPP_FLASH    (rx) : ORIGIN = 0x0800C000, LENGTH = 16K + 64K + (10 * 128K) /* Main Application FLASH memory 1360 kByte  */
  BOOTLOADER_FLASH (rx) : ORIGIN = 0x08160000, LENGTH = 128K                  /* Bootloader FLASH memory 16 + 128 kByte      */
  OPT_B            (rw) : ORIGIN = 0x1FFFC000, LENGTH = 16                    /* Options bytes single-bank                    */
  RAM            (rwx) : ORIGIN = 0x20000000, LENGTH = 320K                  /* Main RAM memory                              */
}

I.e. Bootloader lives on pages 0 and 15.
Misc. user data is on pages 1...2.
Main application lives on pages 3...14.

When compiling both Bootloader and Main application, the produced .hex files are correct. When flashing the .hex files with STM32CubeProgrammer, it will write to the expected pages and leave the other untouched. This is working correctly.

When writing Bootloader with EmBitz / Flash / Flash target, everything goes fine.
But when writing Main application, also page 0, 1, and 2 are overwritten. When looking more closely at those 3 overwritten pages, they seems to contain the raw content of the main application .elf file. For example the ".ELF" signature is stored at address 0x08000000. Attached picture of the beginning of 0x08000000.

This happens for both EmBitz 2.63 and 2.65 that I have been using.

Any help appreciated!


Here is the EBlink output when writing Bootloader:

EBlink version 6.21-[299] by Gerard Zagema

Interface USB# : 54FF6A066684565547522187
Interface type : STlink/V2
Target voltage : 3.24V
Interface speed: 4000KHz

Target detected: Cortex-M4 (r0p1) with FPv4_SP
HW breakpoints : 6
HW watchpoints : 4
Fault unwind  : Active (level 2)
STmicro family : STM32F413
Detected FLASH : 1536KB
Configured RAM : 320KB
Reset: system
Checking current flash content
Reset: system
Flashing sector  0, address: 0x08000000, length: 0x4000
Flashing sector 15, address: 0x08160000, length: 0x1710C
Flash verify
Flasher starts target
Reset: system



Here is the EBlink output when writing main application:

EBlink version 6.21-[299] by Gerard Zagema

Interface USB# : 54FF6A066684565547522187
Interface type : STlink/V2
Target voltage : 3.24V
Interface speed: 4000KHz

Target detected: Cortex-M4 (r0p1) with FPv4_SP
HW breakpoints : 6
HW watchpoints : 4
Fault unwind  : Active (level 2)
STmicro family : STM32F413
Detected FLASH : 1536KB
Configured RAM : 320KB
Reset: system
Checking current flash content
Reset: system
Flashing sector  0, address: 0x08000000, length: 0x4000
Flashing sector  1, address: 0x08004000, length: 0x4000
Flashing sector  2, address: 0x08008000, length: 0x4000
Flashing sector  3, address: 0x0800C000, length: 0x4000
Flashing sector  4, address: 0x08010000, length: 0x10000
Flashing sector  5, address: 0x08020000, length: 0x20000
Flashing sector  6, address: 0x08040000, length: 0x20000
Flashing sector  7, address: 0x08060000, length: 0x20000
Flashing sector  8, address: 0x08080000, length: 0x20000
Flashing sector  9, address: 0x080A0000, length: 0x3090
Flash verify

.zip   STM32F413_EBlink_6.21_scripts.zip (Size: 3.82 KB / Downloads: 3)

.png   after_application_flashing.png (Size: 59.41 KB / Downloads: 28) ]]> <![CDATA[Linux Ubuntu 24.04/Mint 22.1 Instalation Problem (solved > 6.21)]]> https://www.embitz.org/forum/showthread.php?tid=236 Thu, 11 Jun 2026 16:30:08 +0200 Plinio Barbosa da Silva]]> https://www.embitz.org/forum/showthread.php?tid=236
I trying to install EBlink on a machine running Linux Mint 22.1 and the dpkg return some errors. Tested on Ubuntu 24.04 and return the same errors.

[Image: 7YHwa7L.png]

Despite the error, Eblink appears to be installed correct and works correctly. After installation, we might encounter some problems trying to use the debugging tools because the udev rules were not installed. I didn't have any problems because I already had the udev rules installed for stlink. I found a workaround to remove the error after a reinstallation by tricking the installer into running the command "touch /usr/share/eblink/80-eblink.rules". After that the reinstallation runs without errors.]]>
I trying to install EBlink on a machine running Linux Mint 22.1 and the dpkg return some errors. Tested on Ubuntu 24.04 and return the same errors.

[Image: 7YHwa7L.png]

Despite the error, Eblink appears to be installed correct and works correctly. After installation, we might encounter some problems trying to use the debugging tools because the udev rules were not installed. I didn't have any problems because I already had the udev rules installed for stlink. I found a workaround to remove the error after a reinstallation by tricking the installer into running the command "touch /usr/share/eblink/80-eblink.rules". After that the reinstallation runs without errors.]]> <![CDATA[Installation without admin rights]]> https://www.embitz.org/forum/showthread.php?tid=233 Tue, 14 Oct 2025 11:49:24 +0200 jack133]]> https://www.embitz.org/forum/showthread.php?tid=233 Is it possible to have an installation process without admin rights on Windows ?
Thank you for your great job !
Stéphane]]> Is it possible to have an installation process without admin rights on Windows ?
Thank you for your great job !
Stéphane]]> <![CDATA[STM32H5xx HighCycle memory flashing from file]]> https://www.embitz.org/forum/showthread.php?tid=217 Fri, 06 Dec 2024 18:04:16 +0100 embitz]]> https://www.embitz.org/forum/showthread.php?tid=217 If you use this data will debugging, it will every time be reflashed at every debug session because it is bypassing the cache manager. The HighCycle data is defined as 'virtual' sectors so that we don't have read errors of unused highCycle memory.

You can find the modified script files on github and from version EBlink 6.00 they will be included into the package.]]> If you use this data will debugging, it will every time be reflashed at every debug session because it is bypassing the cache manager. The HighCycle data is defined as 'virtual' sectors so that we don't have read errors of unused highCycle memory.

You can find the modified script files on github and from version EBlink 6.00 they will be included into the package.]]> <![CDATA[EBlink V5.30 - CubeIDE compatible with Live Variables]]> https://www.embitz.org/forum/showthread.php?tid=212 Wed, 13 Nov 2024 14:50:24 +0100 embitz]]> https://www.embitz.org/forum/showthread.php?tid=212 Just select one of the three available probe types and use EBlink as your GDB server.

- Launch EBlink from context menu (windows) of from CLI (linux or remote)
- Launch CubeIDE
- Select the probe
- Configure CubeMX probe as a remote probe ( localhost or remote IP)

Start using CubeIDE with STlink probe and make use of:
- EBlink  Caching 
- EBlink fault unwind

Have fun!]]> Just select one of the three available probe types and use EBlink as your GDB server.

- Launch EBlink from context menu (windows) of from CLI (linux or remote)
- Launch CubeIDE
- Select the probe
- Configure CubeMX probe as a remote probe ( localhost or remote IP)

Start using CubeIDE with STlink probe and make use of:
- EBlink  Caching 
- EBlink fault unwind

Have fun!]]> <![CDATA[EBlink V5.20 released]]> https://www.embitz.org/forum/showthread.php?tid=211 Mon, 11 Nov 2024 14:34:23 +0100 embitz]]> https://www.embitz.org/forum/showthread.php?tid=211 5.20
  • Modified flow, increased speed and bandwidth by using the cache more consistently 
  • Reset strategy as cube programmer, more robust initialization
  • Semihost repair for EmBitz, now also printing in target window if not standalone
  • Fault unwind is enhanced with an additional setting "fc" to define the fault catch vectors
  • Enhanced cache control (virtual,nocache,read-through etc)
  • Enhanced memory access algorithm, useful for 16 and 32 bit access (high cycle H5 memory etc) 
  • Bugfix: fault unwind at startup
  • Bugfix: Multicore debugging unexpected fault unwind's
  • Bugfix: Target control on linux
  • Bugfix: unhandled exceptions
  • Bugfix: don't trap on nvic_reset
  • And a lot of minor bug fixes

The code is rewritten to make it more robust and the STlink initialization is copied from Cube programmer (except hotplugging)

The fault unwind levels are renamed to 0=off, 1=passive and 2=active. This reflects the real meaning better.]]> 5.20
  • Modified flow, increased speed and bandwidth by using the cache more consistently 
  • Reset strategy as cube programmer, more robust initialization
  • Semihost repair for EmBitz, now also printing in target window if not standalone
  • Fault unwind is enhanced with an additional setting "fc" to define the fault catch vectors
  • Enhanced cache control (virtual,nocache,read-through etc)
  • Enhanced memory access algorithm, useful for 16 and 32 bit access (high cycle H5 memory etc) 
  • Bugfix: fault unwind at startup
  • Bugfix: Multicore debugging unexpected fault unwind's
  • Bugfix: Target control on linux
  • Bugfix: unhandled exceptions
  • Bugfix: don't trap on nvic_reset
  • And a lot of minor bug fixes

The code is rewritten to make it more robust and the STlink initialization is copied from Cube programmer (except hotplugging)

The fault unwind levels are renamed to 0=off, 1=passive and 2=active. This reflects the real meaning better.]]> <![CDATA[EBlink override the default halt on Reset_Handler]]> https://www.embitz.org/forum/showthread.php?tid=209 Wed, 06 Nov 2024 14:41:43 +0100 Mate]]> https://www.embitz.org/forum/showthread.php?tid=209 I have one custom Bootloader project which is performing a runtime software Restart: NVIC_SystemReset(); on STM32 (tried on different families: F1, F4 and F0).
While debuggins session is running EmBitz stops the CPU at Reset_Handler eventough there are no breakpints and inside the debug interface settings all relevant options are unchecked (See images in attachments).
I Would expect that the poper behavior would be that the CPU doesn't stop after executing NVIC_SystemReset(); (like it was on the EmBitz 1.11).

Note: I am using:
- Embitz 2.62 
- EBlink 5.13 (Build 193)
- Win11
- ST Link V2

Best Regards,
Mate

.png   2024-11-06 14_10_56-startup_stm32f401xe.s [Bootloader] - EmBitz 2.62.png (Size: 380.2 KB / Downloads: 8)

.png   2024-11-06 14_31_32-Debug interface options - Bootloader (F4_ReleaseBT).png (Size: 68.45 KB / Downloads: 8)

.png   2024-11-06 14_32_26-Debug interface options - Bootloader (F4_ReleaseBT).png (Size: 93.17 KB / Downloads: 8) ]]> I have one custom Bootloader project which is performing a runtime software Restart: NVIC_SystemReset(); on STM32 (tried on different families: F1, F4 and F0).
While debuggins session is running EmBitz stops the CPU at Reset_Handler eventough there are no breakpints and inside the debug interface settings all relevant options are unchecked (See images in attachments).
I Would expect that the poper behavior would be that the CPU doesn't stop after executing NVIC_SystemReset(); (like it was on the EmBitz 1.11).

Note: I am using:
- Embitz 2.62 
- EBlink 5.13 (Build 193)
- Win11
- ST Link V2

Best Regards,
Mate

.png   2024-11-06 14_10_56-startup_stm32f401xe.s [Bootloader] - EmBitz 2.62.png (Size: 380.2 KB / Downloads: 8)

.png   2024-11-06 14_31_32-Debug interface options - Bootloader (F4_ReleaseBT).png (Size: 68.45 KB / Downloads: 8)

.png   2024-11-06 14_32_26-Debug interface options - Bootloader (F4_ReleaseBT).png (Size: 93.17 KB / Downloads: 8) ]]> <![CDATA[Examine high-cycle flash STM32H573 [solved]]]> https://www.embitz.org/forum/showthread.php?tid=205 Tue, 17 Sep 2024 17:53:16 +0200 dliebler]]> https://www.embitz.org/forum/showthread.php?tid=205 This device also has a high-cycle flash.

The memory region for the high-cycle flash is located from 0x09000000 and can only be accessed by 16-bit or by 32-bit.
8-bit reads to this addresses are not allowed.

Now the problem is, I cant examine this memory via eblink. I tested the exact same configuration with eblink and with stlink-gdbserver.

eblink:
Code:
x/1xb 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xh 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xw 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xg 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000

stlink-gdbserver:
Code:
x/1xb 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xh 0x09000000
0x9000000:    0x1e0f
x/1xw 0x09000000
0x9000000:    0x3c2d1e0f
x/1xg 0x09000000
0x9000000:    0x78695a4b3c2d1e0f

As you can see, stlink-gdbserver is able to examine the memory as long as I dont make it read only one byte.
But eblink is not able to examine it at all. I suspect eblink treats every memory access as byte reads?
Is this the intended behavior?

This is not an important bug to me, I can fall back on stlink-gdbserver, I just stumbled over it.]]> This device also has a high-cycle flash.

The memory region for the high-cycle flash is located from 0x09000000 and can only be accessed by 16-bit or by 32-bit.
8-bit reads to this addresses are not allowed.

Now the problem is, I cant examine this memory via eblink. I tested the exact same configuration with eblink and with stlink-gdbserver.

eblink:
Code:
x/1xb 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xh 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xw 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xg 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000

stlink-gdbserver:
Code:
x/1xb 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xh 0x09000000
0x9000000:    0x1e0f
x/1xw 0x09000000
0x9000000:    0x3c2d1e0f
x/1xg 0x09000000
0x9000000:    0x78695a4b3c2d1e0f

As you can see, stlink-gdbserver is able to examine the memory as long as I dont make it read only one byte.
But eblink is not able to examine it at all. I suspect eblink treats every memory access as byte reads?
Is this the intended behavior?

This is not an important bug to me, I can fall back on stlink-gdbserver, I just stumbled over it.]]> <![CDATA[STM32U0 support [solved]]]> https://www.embitz.org/forum/showthread.php?tid=202 Tue, 27 Aug 2024 01:28:23 +0200 dalbert]]> https://www.embitz.org/forum/showthread.php?tid=202
Is there any chance EBlink might add support for the U0 series soon?

Changes seem to be:
stm32.script:
    Add to the M0+ block:
                ["u0", [ 0x459, 0x489 ]],

Add an stm32u0.script  (see attached - work in progress)
Add a flash/u0.script (still working on this)]]>
Is there any chance EBlink might add support for the U0 series soon?

Changes seem to be:
stm32.script:
    Add to the M0+ block:
                ["u0", [ 0x459, 0x489 ]],

Add an stm32u0.script  (see attached - work in progress)
Add a flash/u0.script (still working on this)]]> <![CDATA[Support for Zbit]]> https://www.embitz.org/forum/showthread.php?tid=204 Tue, 16 Jul 2024 12:59:23 +0200 sp9skp]]> https://www.embitz.org/forum/showthread.php?tid=204 <![CDATA[EBlink digital signed]]> https://www.embitz.org/forum/showthread.php?tid=185 Tue, 23 Jan 2024 19:36:05 +0100 embitz]]> https://www.embitz.org/forum/showthread.php?tid=185 It is signed with an OV certificate so still the windows warnings but it's more a service to the users to check instantly all the windows binaries.


Embitz will follow soon.]]> It is signed with an OV certificate so still the windows warnings but it's more a service to the users to check instantly all the windows binaries.


Embitz will follow soon.]]> <![CDATA[EBlink 5.12 available]]> https://www.embitz.org/forum/showthread.php?tid=183 Mon, 15 Jan 2024 11:18:10 +0100 embitz]]> https://www.embitz.org/forum/showthread.php?tid=183 - Added sector attribute "gdb_nc". With this sector attribute, GDB will read from chip rather than cache. Used e.g. with Renesas data flash (EEProm emulation) so that any data flash modifications are visible in the IDE.

The RV40 flash script will skip dataflash (EEprom) erase on chip erase. This is to retain config data between chip erase cycles. 
If a full chip erase is needed then comment the lines in the rv40 script at the erase function (see code)]]> - Added sector attribute "gdb_nc". With this sector attribute, GDB will read from chip rather than cache. Used e.g. with Renesas data flash (EEProm emulation) so that any data flash modifications are visible in the IDE.

The RV40 flash script will skip dataflash (EEprom) erase on chip erase. This is to retain config data between chip erase cycles. 
If a full chip erase is needed then comment the lines in the rv40 script at the erase function (see code)]]> <![CDATA[Latest EBlink - 6.3]]> https://www.embitz.org/forum/showthread.php?tid=141 Tue, 01 Nov 2022 09:46:46 +0100 embitz]]> https://www.embitz.org/forum/showthread.php?tid=141
Embitz on Github]]>
Embitz on Github]]>