Ronetix PEEDI notes

On the Ronetix PEEDI, the peedi.stm3220g.cfg or peedi.stm3240g.cfg file supplied in the platform HAL package should be used to setup and configure the hardware to an appropriate state to load programs. This includes setting up the clocks, GPIO lines, and FSMC memory controller for off-chip SRAM.

The peedi.stm3220g.cfg and peedi.stm3240g.cfg files also contain 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, or in the eCosPro version of Eclipse by setting the Breakpoint Type - consult the “eCosPro CDT plug-in user's guide” manual for details. 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 relevant peedi.stm3220g.cfg or peedi.stm3240g.cfg file, and halts the target. This behaviour is repeated with the reset command.

If the board is reset either with the 'reset' command, or by pressing the reset button, and then the 'go' command is given, 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 appropriate peedi.stm3220g.cfg or peedi.stm3240g.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. Finally, it is also possible to set a temporary default (unless the PEEDI is reset) by giving an argument to the reset command, for example reset run. Use the command help reset at the PEEDI command prompt for more options.

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

stm3220g> memory load tftp://192.168.7.9/test.bin bin 0x64000000
++ info: Loading image file:  tftp://192.168.7.9/test.bin
++ info: At absolute address: 0x64000000
loading at 0x64000000
loading at 0x64004000

Successfully loaded 28KB (29064 bytes) in 0.1s
stm3220g> go 0x64000000

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

For Eclipse users wishing to debug ROM startup programs resident in Flash, it is worth highlighting that it is possible to use the eCosCentric Eclipse plugin to automatically reprogram Flash as the load sequence. To do so, you will need to install and use a TFTP server so that your application can be accessed from the PEEDI from there. You may then use a GDB command file, as described in more detail in the “eCosPro CDT plug-in user's guide” manual. This file can then contain contents similar to the following example:

define doload
  shell arm-eabi-objcopy -O binary /path/to/eclipse/workspace/projectname/Debug/myapp /path/to/tftp/server/area/myapp.bin
  monitor flash program tftp://10.1.1.1/myapp.bin bin 0x08000000 erase
  set $pc=0x08000000
end

Obviously you will need to adjust the paths and names for your system and TFTP server requirements.

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, it is recommended to use the JTAG startup type which will implicitly cause two important settings to change. 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. These configuration changes could be made by hand, but use of the JTAG startup type will just work.

With these changes, any diagnostic output will appear out of the configured diagnostic channel, usually a serial port. An eCosCentric extension allows diagnostic output to appear in GDB instead. For this to work, you must enable the configuration option CYGSEM_HAL_DIAG_TO_GDBFILEIO_CHAN in the common HAL package.

For details of using hardware debug with the Eclipse IDE see the “eCos Hardware Debugging” section of the “eCosPro CDT plug-in user's guide” manual.