Hi
You should be able to do basic debugging in RIDE7.
If you don't have a full version it is probably limited to small code size - in this case first remove options (like serial interface, Ethernet, etc.) to make a small enough test program and try with that. (These can be commented out in
config.h and added again later).
Once this test program starts correctly a larger program will also start correctly and you may be able to work with just the uTasker simulator as debugger. But first the project needs to be basically functional and it is worth investing a bit of time to understand the details since this knowledge will be useful for solving difficulties in the future.
Here is a check list of what needs to be correct for the project to start. I will then give more details of practical methods to achieve each step with the available tools.
1) The FLASH is the STR91XF must be configured to either boot from bank 0 or bank 1 as required
2) The project needs to be linked to match the FLASH configuration
3) The initialisation code must also match the FLASH configuration and set the FLASH registers accordingly
4) The file system and parameter system must also be correctly configured to respect the FLASH memory layout
As seen from the list it is quite easy for something to not match and this usually results in the board not being able to start. To achieve the correct configuration requires a bit of knowledge of the chip and the compiler tools. It also requires the correct HW tools and programs, whereby not all available programs seem capable of everything.
This means that the chip is certainly not the simplest to use, which is possibly a reason why it has not been very popular.
I also haven't used it for some time due to this fact and will need to do some refreshing on the steps, but I can start with more details to point 1) and you can also do some reading on the FLASH capabilities in the device. Note that the full details are not contained in the STR91XF user's manual but instead in a second ST document dedicated to the FLASH module. If you don't have this yet I recommend downloading it from the ST Micro web site and reading through it.
PART 1) The FLASH is the STR91XF must be configured to either boot from bank 0 or bank 1 as requiredFirst of all, the general details of the FLASH. The STR91XF can be ordered with various sizes of internal FLASH (and SRAM). What allows the chips to have such large FLASH values (I believe up to maybe 1 or 2 MByte is offered today) is because the FLASH is a second module in the chip - the FLASH does not share the processor's silicon die.
As reference, lets take the STR912F which has 512k + 32k FLASH and 96k SRAM.
The FLASH is divided into two banks. Bank 0 and Bank 1.
- Bank 0 is a 512k block of FLASH which is made up of 8 x64k sectors. The sector size is the smallest size that can be deleted.
- Bank 1 is a 32k block of FLASH which is made up of 4 x 8k sectors.
The chip has a configuration option which allows it to either boot from bank 0 or from bank 1. This configuration option is programmed in a special, dedicated FLASH area which can only be programmed via JTAG. This means that it can only be programmed by connecting a JTAG interface (debugger) which can perform the programming using a suitable program on the PC).
The bank that is configured as boot bank is always situated at address 0x00000000. The second bank is initially deactivated. The size of the banks and the activation of the second bank is performed in initialisation code before they can be fully used.
The simplest case is to leave the configuration with bank 0 as boot bank since the chips are delivered like this (assuming this can be relied on and no one else has changed it in the meantime). This configuration is however not very good when working with a boot loader. The reason is that the boot loader (which is usually quite small) needs to occupy a complete 64k FLASH sector at the start of bank 0. When a boot loader is used it makes sense to boot from bank 1 instead, where it occupies just a small block (usually 8k).
The 64k FLASH granularity is is a little difficult to work with and the STR91XF project is usually configured to use the large-granularity mode (see
http://www.utasker.com/docs/STR91XF/FileSystemSTR91X.PDF for full details).
Whichever configuration is chosen, it usually makes sense to have the uParameterSystem in bank 1 (the one with 4 x 8k sectors). This is because 64k blocks for parameters is mostly overkill and wastes program space. 8k blocks are usually much more suitable.
Finally note that the FLASH sectors are protected by default. Before they can be used they need to be unprotected. The uTasker project includes automatic un-protection and protection of the sectors on a per-use basis so that the FLASH is in the protected state when the code is not presently writing or deleting something.
What this boils down to is that we need to know how to configure a project for bank 0 booting and for bank 1 booting compatibility. We need to know how to configure the chip to match this too. These are the points 2), 3) and 4).
But point 1) is not completed until we know how to check how the chip is presently configured and how to change it if necessary. I will do some verifications (I didn't do this for some time now) since I suggest using
RFlasher7 for this (you should have it alongside RIDE7). CAPs does it well but CAPs doesn't run on Vista and higher so it looks as though this method needs to effectively be dropped. I don't think that it is possible with IAR, Rowley etc. but please tell me if anyone knows better...;-)
More follows later.
Regards
Mark
