RIDE7

[mark]

Hi

I have tested a working version of a stripped down V1.3 project compiled with RIDE7 and downloaded wither with the RIDE7 debugger or else with RFlasher7. This uses the simplest configuration with the device booting from bank0 and all code there.

These are the changes that I made:
1) In config.h disable ETH_INTERFACE. This removes everything to do with Ethernet (including TCP/IP stack and services) so that the code is small. RIDE7 does not allow debugging code larger than 32k in size if it is not licensed. There is however no restriction to compiling larger codes and downloading them with RFlasher7.

2) I needed to make a change in the STR91XF driver since the GCC variable initialisation was missing :-/. This is here: http://www.uTasker.com/software/V1.3/STR91XF.zip

3) In the linker script file uTaskerV1.4_FLASH.ld (in \Applications\uTaskerV1.3\RIDE_STR91XF) the FLASH memory map needs to be set to
FLASH_START = 0x0000000;
FLASH_SIZE  = 0x40000;

MEMORY
{
    SRAM (wx)  : ORIGIN = 0x04000000, LENGTH = 0x00010000
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000
}

This locates the code starting at address 0x00000000 where it needs to be in the simple case (it was at 0x80000).

4) In the Ride7 project "Flash bank selection" is set to bank0 @ 0x0 (see previous post)
and the script file is set to
\Applications\uTaskerV1.3\RIDE_STR91XF\uTaskerV1.4_FLASH.ld (rather than the "Bare Minimum " loader version.

After making these changes it should be possible to load the code from the debugger - just command "Debug | Start" or click on the corresponding symbol. You need to be quite patient since it takes 20s or more, after which you can then step in the code or let it run. The debugger is not very fast but does seem usable (better than the Ride4 version that was didn't do much useful at the time...)

If not debugging, loading form RFlasher is faster .

I compiled my test version for the Raisonance REva hardware. The code doesn't do much but is seen to operate due to the linking LED D0.
To test on other boards the corresponding board can be selected in config.h or else the watchdog LED needs to be configured to a different location to suit. In any case a blinking LED (heart-beat) is always good to start with.

Good luck

Mark


P.S. Exercise to test the configuration once the simple test code is running:
- try modifying the configuration to boot from bank 1. This will stop the board from running since bank 1 is empty
- then try modifying the configuration back to booting from bank 0. The board will then run again without the need to re-program the code.

[Sacha_D]

Hello

I have RLink in STD version. Have you an upgrade serial number to Pro version? I don't see reason to buy it for 700 euro for single controller without using it in future. With 32K limitation i can't debug 260K .elf file.
If you have it, please, send me by e-mail.

With hope,

Sacha_D

[mark]

Hi

I don't have a professional version and so can't help here. I believe that the keys are locked to the RLink and so exchanging keys is not possible (and is also probably not really legal).

The ELF file is large since it contains a lot of additional information for the debugger. As long as the binary is less that 32k you can debug. By removing the Ethernet support it is easily below 32k in size. Therefore don't look at the size of the ELF since it is not important.

You can still compile and load larger files but debugging with Ride7 is not possible. Debugging can still be done with the uTasker simulator (should be adequate and faster in 95% of cases) and, if necessary, by working with debug messages on the target. This means that there is no absolute need to have a source level target debugger - it does make some work easier but one can live without it (as long as some additional time is taken into account in case some problems need to be solved where the debugger would have helped - professionals will generally always use a good tool since it is important, and much cheaper in the long-term, to be able to work efficiently - students and hobby users may have different priorities).

Regards

Mark

[mark]

Hi

I would now like to take a look at point 2) The project needs to be linked to match the FLASH configuration

This is in fact quite easy to explain since the goal is to simply link the code to the correct FLASH bank depending on how the banks are configured. There are two cases for an application program: Note that the application can be either a 'stand-alone' application or an application that works together with a boot loader. When there is a boot loader present it is always linked to the boot bank.

Case 1 - stand-alone application.
In most cases the FLASH will be configured so that bank 0 is used as boot bank. This is the larger FLASH bank where the application will start at the beginning (the reset vector) and occupy a certain amount of space, depending on its size. The following sectors are then free for use by the file system, for example.

The location of the code is controlled by the linker scrip used. The script uTaskerV1.4_FLASH.ld can be used in this instance and has the following definitions for the memory space:

RAM_START   = 0x04000000;
RAM_SIZE    = 96*1024;
FLASH_START = 0x0000000;
FLASH_SIZE  = 0x40000;


MEMORY
{
    SRAM (wx)  : ORIGIN = 0x04000000, LENGTH = 0x00018000
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000
}


This will cause the code to be linked starting at the address 0x00000000, which is all that is required to generate a suitable binary for this case.


Case 2 - application for operation with a boot loader
In this case it is assumed that the FLASH is configured to boot from bank 1 (the smaller bank) and this smaller bank contains a boot loader. The boot loader may allow the application to be loaded (via UART, USB etc.) and copies the application into the larger FLASH bank. For our discussion the larger FLASH bank (bank 0) is assumed to be located at 0x80000 since this is in fact programmable at run time.

The location of the code is controlled by the linker scrip used. The script uTaskerV1.4_FLASH_BM.ld can be used in this instance and has the following definitions for the memory space:

RAM_START   = 0x04000000;
RAM_SIZE    = 96*1024;
FLASH_START = 0x0080000;
FLASH_SIZE  = 0x40000;

MEMORY
{
    SRAM (wx)  : ORIGIN = 0x04000000, LENGTH = 0x00018000
    FLASH (rx) : ORIGIN = 0x00080000, LENGTH = 0x00040000
}



This will cause the code to be linked starting at the address 0x00080000, which will generate a suitable binary for this case.

To summarise: this is in fact quite a simple detail and basically involves choosing the correct linker script to be used by the project. The result is simply that the code is linked to operate at either 0x00000000 or 0x00080000. It is possible to check that the code is linked to the correct place by checking in the map file that the compiler generates or also inspecting a hex file that it generates.

However it is important to understand that this change also requires the FLASH to be correctly configured (as discussed in a previous post) and requires a boot loader to be able to work in the second case. Furthermore the non-boot bank is not enabled by default and its exact location in memory is not defined, so it requires a little initialisation code to go with it. This will be the subject of the next post...

Regards

Mark

[Sacha_D]

Hello

Today I get self-soldered(or sweated, or brazed - I don't know English well) connector from RLink device to Flash-link pins on board. In RIDE7 with RLink I can program it and erase, but can't debug, or, simply, pause execution of program. I always get message from OPI Driver: "Core does not acknowledge."

How to debug it?