https://www.embitz.org/forum/ Fri, 24 Apr 2026 08:39:09 +0000 MyBB https://www.embitz.org/forum/thread-166.html Thu, 20 Apr 2023 16:18:01 +0200 jdubois]]> https://www.embitz.org/forum/thread-166.html
I also made a small change to the Cortex-M0 section in the atmel-auto.script so that it wouldn't incorrectly detect non-Atmel chips as Atmel when using the auto.script.

  sam3.zip (Size: 5.17 KB / Downloads: 53) ]]>
I also made a small change to the Cortex-M0 section in the atmel-auto.script so that it wouldn't incorrectly detect non-Atmel chips as Atmel when using the auto.script.

  sam3.zip (Size: 5.17 KB / Downloads: 53) ]]> https://www.embitz.org/forum/thread-162.html Wed, 12 Apr 2023 17:18:31 +0200 jdubois]]> https://www.embitz.org/forum/thread-162.html
  nxpscripts.zip (Size: 13.84 KB / Downloads: 50) ]]>
  nxpscripts.zip (Size: 13.84 KB / Downloads: 50) ]]> https://www.embitz.org/forum/thread-161.html Tue, 11 Apr 2023 14:24:29 +0200 jdubois]]> https://www.embitz.org/forum/thread-161.html https://www.embitz.org/forum/thread-160.html Tue, 11 Apr 2023 14:22:50 +0200 jdubois]]> https://www.embitz.org/forum/thread-160.html
The LPC802 chip has 16K of flash arranged as either 16 sectors of 1K each, or 256 pages of 64 bytes each.  The last two pages (254 & 255) are mapped on the chip to ROM instead of the flash, so you cannot program them.   Using the 1024 byte sector arrangement instead of the 64 byte page arrangement is much faster to erase and program. But using this, the last sector is actually 896 bytes instead of 1024.  There doesn't seem to be any good way to tell EBlink about this uneven sized final sector.

The first approach is to simply use the 64 byte page arrangement.  This works, but is very slow to erase and write 256 individual pages.

The second approach is to use the 1K sector arrangement and just ignore the fact that the last 128 bytes of the last sector aren't written.  This also mostly works, but when EBlink reads the last sector (usually when deciding if it needs to be programmed) it will read back the ROM bytes in those last 128 bytes and so it will never match what is in the file to be flashed (forcing the last sector to always be erased and reprogrammed).

The best approach, I believe, would be to set up two separate flash areas in the EBlink memory map.  The first with 15 1K sectors, and the second with 14 64 byte sectors.  This would give the speed of using the sectors for most of the chip, but the granularity on the last sector to avoid the 128 ROM bytes.  (This approach would also be helpful looking toward the LPC1700 series of chips, as they have two different flash sections with different sector sizes.) However, it appears that EBlink only uses the first flash section in the memory map when erasing/programming the chip.]]>
The LPC802 chip has 16K of flash arranged as either 16 sectors of 1K each, or 256 pages of 64 bytes each.  The last two pages (254 & 255) are mapped on the chip to ROM instead of the flash, so you cannot program them.   Using the 1024 byte sector arrangement instead of the 64 byte page arrangement is much faster to erase and program. But using this, the last sector is actually 896 bytes instead of 1024.  There doesn't seem to be any good way to tell EBlink about this uneven sized final sector.

The first approach is to simply use the 64 byte page arrangement.  This works, but is very slow to erase and write 256 individual pages.

The second approach is to use the 1K sector arrangement and just ignore the fact that the last 128 bytes of the last sector aren't written.  This also mostly works, but when EBlink reads the last sector (usually when deciding if it needs to be programmed) it will read back the ROM bytes in those last 128 bytes and so it will never match what is in the file to be flashed (forcing the last sector to always be erased and reprogrammed).

The best approach, I believe, would be to set up two separate flash areas in the EBlink memory map.  The first with 15 1K sectors, and the second with 14 64 byte sectors.  This would give the speed of using the sectors for most of the chip, but the granularity on the last sector to avoid the 128 ROM bytes.  (This approach would also be helpful looking toward the LPC1700 series of chips, as they have two different flash sections with different sector sizes.) However, it appears that EBlink only uses the first flash section in the memory map when erasing/programming the chip.]]> https://www.embitz.org/forum/thread-131.html Fri, 22 Jul 2022 18:49:15 +0200 Buzzwang]]> https://www.embitz.org/forum/thread-131.html
basicly I'm using a selfmade cmake based buildchain and using EMBitz only for debuging by passing the .elf file to it.
I have bought 2 nucleo boards. Both are not suppoerted, yet. I would like to add the both devices myself, just by copy&paste&replace. But I'm not sure about the different core M33.
I also tried to check EBLink-github for updates, but I cannot reach it.


ST-LINK SN  : 002B004F3331510A33323639
ST-LINK FW  : V3J8M3
Board      : NUCLEO-U575ZI-Q
Voltage    : 3.30V
SWD freq    : 24000 KHz
Connect mode: Normal
Reset mode  : Software reset
Device ID  : 0x482
Revision ID : Rev X
Device name : STM32U575/STM32U585
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M33
BL Version  : 0x92
Debug in Low Power mode enabled

Interface USB# : 002B004F3331510A33323639
Interface type : STlink/V3
STlink connect : Under reset
Target voltage : 3.30V
Interface speed: 24000KHz
Target detected: Cortex-M33 (r0p4) with FPv5_SP
HW breakpoints : 8
HW watchpoints : 4
Fault unwind  : Active break (level 2)

Error unsupported STM32 ID: 0x482

Please report this ID so that we can add it.

-------------------------------------------------------

ST-LINK SN  : 066CFF505352716587121640
ST-LINK FW  : V2J37M26
Board      : NUCLEO-L552ZE-Q
Voltage    : 3.24V
SWD freq    : 4000 KHz
Connect mode: Normal
Reset mode  : Software reset
Device ID  : 0x472
Revision ID : Rev B
Device name : STM32L5xx
Flash size  : 512 KBytes
Device type : MCU
Device CPU  : Cortex-M33
BL Version  : --


Interface USB# : 066CFF505352716587121640
Interface type : STlink/V2.1
STlink connect : Under reset
Target voltage : 3.24V
Interface speed: 4000KHz
Target detected: Cortex-M33 (r0p2) with FPv5_SP
HW breakpoints : 8
HW watchpoints : 4
Fault unwind  : Active break (level 2)


Please report this ID so that we can add it.]]>
basicly I'm using a selfmade cmake based buildchain and using EMBitz only for debuging by passing the .elf file to it.
I have bought 2 nucleo boards. Both are not suppoerted, yet. I would like to add the both devices myself, just by copy&paste&replace. But I'm not sure about the different core M33.
I also tried to check EBLink-github for updates, but I cannot reach it.


ST-LINK SN  : 002B004F3331510A33323639
ST-LINK FW  : V3J8M3
Board      : NUCLEO-U575ZI-Q
Voltage    : 3.30V
SWD freq    : 24000 KHz
Connect mode: Normal
Reset mode  : Software reset
Device ID  : 0x482
Revision ID : Rev X
Device name : STM32U575/STM32U585
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M33
BL Version  : 0x92
Debug in Low Power mode enabled

Interface USB# : 002B004F3331510A33323639
Interface type : STlink/V3
STlink connect : Under reset
Target voltage : 3.30V
Interface speed: 24000KHz
Target detected: Cortex-M33 (r0p4) with FPv5_SP
HW breakpoints : 8
HW watchpoints : 4
Fault unwind  : Active break (level 2)

Error unsupported STM32 ID: 0x482

Please report this ID so that we can add it.

-------------------------------------------------------

ST-LINK SN  : 066CFF505352716587121640
ST-LINK FW  : V2J37M26
Board      : NUCLEO-L552ZE-Q
Voltage    : 3.24V
SWD freq    : 4000 KHz
Connect mode: Normal
Reset mode  : Software reset
Device ID  : 0x472
Revision ID : Rev B
Device name : STM32L5xx
Flash size  : 512 KBytes
Device type : MCU
Device CPU  : Cortex-M33
BL Version  : --


Interface USB# : 066CFF505352716587121640
Interface type : STlink/V2.1
STlink connect : Under reset
Target voltage : 3.24V
Interface speed: 4000KHz
Target detected: Cortex-M33 (r0p2) with FPv5_SP
HW breakpoints : 8
HW watchpoints : 4
Fault unwind  : Active break (level 2)


Please report this ID so that we can add it.]]> https://www.embitz.org/forum/thread-119.html Mon, 28 Mar 2022 18:33:04 +0200 PDonchev]]> https://www.embitz.org/forum/thread-119.html No support for RAM/FLASH ECC. I had to pre-configure the OBs with STM32CubeProgrammer to avoid starting of the system bootloader. BOOT0 pin is shared with SWDCLK. These MCUs are not supported in ST-Link Utility software.

  stm32gx.script (Size: 8.41 KB / Downloads: 113)

  stm32-auto.script (Size: 6.18 KB / Downloads: 97) ]]> No support for RAM/FLASH ECC. I had to pre-configure the OBs with STM32CubeProgrammer to avoid starting of the system bootloader. BOOT0 pin is shared with SWDCLK. These MCUs are not supported in ST-Link Utility software.

  stm32gx.script (Size: 8.41 KB / Downloads: 113)

  stm32-auto.script (Size: 6.18 KB / Downloads: 97) ]]> https://www.embitz.org/forum/thread-8.html Wed, 08 Jul 2020 07:06:31 +0200 Misc01]]> https://www.embitz.org/forum/thread-8.html
Maybe this is related to the fact that the Flash erase function in STs library (HAL_FLASHEx_Erase) requires consideration of the DBANK setting on how to pass the block number to be erased.]]>
Maybe this is related to the fact that the Flash erase function in STs library (HAL_FLASHEx_Erase) requires consideration of the DBANK setting on how to pass the block number to be erased.]]> https://www.embitz.org/forum/thread-3.html Mon, 27 Apr 2020 07:41:25 +0200 embitz]]> https://www.embitz.org/forum/thread-3.html
./EBlink -I stlink -S myUnlock]]>
./EBlink -I stlink -S myUnlock]]>