<![CDATA[EmBitz - Development]]> https://www.embitz.org/forum/ Tue, 19 May 2026 06:38:27 +0000 MyBB <![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: 7)

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

.png   2024-11-06 14_32_26-Debug interface options - Bootloader (F4_ReleaseBT).png (Size: 93.17 KB / Downloads: 7) ]]> 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: 7)

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

.png   2024-11-06 14_32_26-Debug interface options - Bootloader (F4_ReleaseBT).png (Size: 93.17 KB / Downloads: 7) ]]> <![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.0]]> 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]]>