Ronetix PEEDI notes

On the Ronetix PEEDI, the peedi.stm32e.cfg file, supplied in the platform HAL package's misc directory, should be used to setup and configure the hardware to an appropriate state to load programs. This includes setting up the clocks, GPIO lines, SRAM and flash memory controller.

The peedi.stm32e.cfg file also contains an option to define whether hardware or software breakpoints are used by default, using the CORE0_BREAKMODE directive in the [TARGET] section. The supplied version of the file defaults to software breakpoints. With this default, hardware breakpoints can still be set from GDB using the hbreak command. The default can be changed to hardware breakpoints, and remember to use the reboot command on the PEEDI command line interface, or press the reset button to make the changes take effect.

On the PEEDI, debugging can be performed either via the telnet interface or using arm-eabi-gdb. In the case of the latter, arm-eabi-gdb needs to connect to TCP port 2000 on the PEEDI's IP address. For example:

(gdb) target remote 111.222.333.444:2000

By default when the PEEDI is powered up, the target will always run the initialization section of the peedi.stm32e.cfg file, and halts the target. This behaviour is repeated with the reset command.

If the board is reset with the 'reset' command, or by pressing the reset button and the 'go' command is then given, then the board will boot from ROM as normal. A similar effect can be achieved in GDB by connecting with target remote and immediately typing continue or c.

It is also possible for the target to always run, without initialization, after the reset button has been pressed. This mode is selected with the CORE0_STARTUP_MODE directive in the [TARGET] section of the peedi.stm32e.cfg file. This conveniently allows the target to be connected to the JTAG debugger, and be able to reset it with the reset button, without being required to always type 'go' every time.

Suitably configured RAM applications can be loaded either via GDB, or directly via the telnet CLI. For example:

stm32> memory load tftp://192.168.7.9/test.bin bin 0x68000000
++ info: Loading image file:  tftp://192.168.7.9/test.bin
++ info: At absolute address: 0x68000000
loading at 0x68000000
loading at 0x68004000

Successfully loaded 28KB (29064 bytes) in 0.1s
stm32> go 0x68000000

Consult the PEEDI documentation for information on other formats and loading mechanisms.

Abatron BDI3000 notes

On the Abatron BDI3000, the bdi3000.stm32e.cfg file should be used to setup and configure the hardware to an appropriate state to load programs. This includes setting up the clocks, GPIO lines, SRAM and flash memory controller.

The bdi3000.stm32e.cfg file also contains an option to define whether hardware or software breakpoints are used by default, using the BREAKMODE directive in the [TARGET] section. The supplied version of the file defaults to software breakpoints. With this default, hardware breakpoints can still be set from GDB using the hbreak command. The default can be changed to hardware breakpoints, and remember to use the boot command on the BDI3000 command line interface.

On the BDI3000, debugging can be performed either via the telnet interface or using arm-eabi-gdb. In the case of the latter, arm-eabi-gdb needs to connect to TCP port 2001 on the BDI3000's IP address. For example:

(gdb) target remote 111.222.333.444:2001

By default when the BDI3000 is powered up, the target will always run the initialization section of the bdi3000.stm32e.cfg file, and halts the target. This behaviour is repeated with the reset command.

If the board is reset with the 'reset' command, or by pressing the reset button and the 'go' command is then given, then the board will boot from ROM as normal. A similar effect can be achieved in GDB by connecting with target remote and immediately typing continue or c.

It is also possible for the target to always run, without initialization, after the reset button has been pressed. This mode is selected with the reset run command. This conveniently allows the target to be connected to the JTAG debugger, and be able to reset it with the reset button, without being required to always type 'go' every time. Thereafter, invoking the reset command will repeat the previous reset style. Also in this mode, exceptions will be handled by board software, rather than causing the JTAG debugger to halt the CPU.

Suitably configured RAM applications can be loaded either via GDB, or directly via the telnet CLI. For example:

STM32> load 0x68000000 test.bin bin
Loading /test.bin , please wait ....
Loading program file passed
STM32> go 0x68000000

Consult the BDI3000 documentation for information on other formats and loading mechanisms.

Configuration of JTAG applications

JTAG applications can be loaded directly into RAM without requiring a ROM monitor. This loading can be done directly through the JTAG device, or where supported by the JTAG device, through GDB.

In order to configure the application to support this mode, some configuration settings are required. Firstly CYGSEM_HAL_USE_ROM_MONITOR must be disabled. Secondly the CYGDBG_HAL_DIAG_TO_DEBUG_CHAN option should be enabled in order to prevent HAL diagnostic output being encoded into GDB ($O) packets. Both of these settings are made automatically if the JTAG startup type is selected.