Messages

3226

NXP^TM M522XX, KINETIS and i.MX RT / Re: moving uTasker

« on: July 19, 2007, 10:47:29 PM »

Hi

You seem to be getting the hang of all this!!

Just one comment about why you originally needed more instructions than expected. It was possibly due to the fact that you were calling the code with jsr rather than jmp. Since jsr pushes the return address onto the stack the stack must also exist. This means that the SP will  have to be set set up to point to a location in RAM and also the RAM will have had to be set up using RAMBAR. Trying to push to an non-existent RAM location would result in an exception.

Just putting the start location at 0x0000004 is very much like a jmp to that address and so no further set up is needed for it to function.

Mark

3227

µTasker general / Re: updating parameters via the HTTP

« on: July 19, 2007, 04:32:14 PM »

Ooops

My original example was wrong. I didn't realise that I had added an offset to the string buffer. This was a cut and paste error and when I did the comparison I didn't compare with the incorrect case, but rather with the one I thought I had written.

Therefore my first example was reall over-complicated and indeed incorrect...

Regards

Mark

3228

ATMEL^TM AT91SAM7X and AVR32 / Re: Ethernet speed

« on: July 19, 2007, 03:31:55 PM »

Hi Michael

At the moment it is difficult to make any conclusions since you seem to be measuring the throughput from your test PC via an echo back to the test PC. Therefore the throughput is defined by a number of presently unknown parameters.

1. Best throughput is achieved when using maximum TCP frame size and so it is necessary to know the frame size being used for testing (this is not visible in the code since it echos that back what it receives and so the length is determined by the received data). If the test frames are small, the overhead can greatly reduce efficiency.

2. The throughput is defined by the PC transmission time, the Ethernet reception delay plus transmission delay and then the delay to get back to the test PC. Then the test PC will hanve to handle the echo and probably start the next test. Each of these phases will have to be known to identify where any bottle-necks are.

Take a look at the following document:
http://www.utasker.com/docs/uTasker/uTaskerBenchmarks.PDF

There is an UDP echo test which was measured for the Freescale M5223X (not the SAM7X which you are using) but the results should be quite similar (but see below). TCP is a bit more complicated than UDP and so the SW handling take a little more time. In any case the check sums in the frames are probably limiting values in terms of absolute performance.
A disadvantage of the SAM7X is that it has 128byte rx LAN buffers and so the received frame has to be grouped into a linear rx buffer of max LAN frame size (involving memcpy()).

Can you send me a short sequence of the test from an Ethereal recording so that I can see where the delays are and where I may be able to make a suggestion as how to optimise the test?

Thanks

Mark

3229

NXP^TM M522XX, KINETIS and i.MX RT / Re: moving uTasker

« on: July 18, 2007, 11:48:02 PM »

A normal downloading tool will only do that which is set in the SRec file. It will therefore not set up any reset vectors!!



In fact the line which you have copied is not code. S7 signifies some information which looks to be the start up address of the code (entry point). This is useful for a debugger since it can set the PC to this address and then start up from there.

Here are the first three lines of the Srec which my compiler is generating (CW6.3)
S0030000FC
S32100000800200080000000080846FC2700203C200000000680000000214E7B0C05C0
S3210000081C2E7C20008000203C4000000006800000000123C040000000203C0000CE

The first is S0 and I don't actually know what it is saying - it can be ignored when loading code to FLASH.
S3 is a line of code with a 32bit address (00000800) and total length of 0x21. The last byte (0xc0) is the check sum of the line.
The target data is thus:
0x00000800 = 0x20008000 (the top of SRAM - will be loaded to SP)
0x00000804 = 0x00000808 (the start location of the code - the PC would be loaded with it at reset)
0x00000804 = 46FC2700 which is assembler code        move.w   #0x2700,sr
I can't actually read assembler, but this is the first line in Startup.s!!

Therefore loading this code to FLASH will not result in any thing which can run., There are 2 possible reasons.
1. This is quite obvious (but not the real reason!). 0x00000004 is 0xffffffff and so the reset will load the PC with this value and the processor will immediately crash when trying to access 0xffffffff.
2. The less obvious. The addresses 0x400..0x418 are 0xffffffff. The FLASH controller in the M5223X loads these also at reset to configure the FLASH controller. These values give the CPU no rights to access FLASH. Therefore the CPU will exception when it tries to load 0x00000000!!

Either way it means instant death and so best to be avoided!!

If you load this code PLUS the boot loader the boot loader will supply everthing which is otherwise missing and both can operate as a team...


Cheers

Mark

3230

µTasker general / Re: updating parameters via the HTTP

« on: July 18, 2007, 11:30:59 PM »

Hi

Our codes are in fact equivalent.

uStrcpy (cValue, "Validate");
*usLengthToSend = 8;
is simply a bit riskier.

"Validate" is in fact a pointer to CHAR x[] = "Validate";
and (sizeof(x)-1) is 8.
The risk is that if you were to type in the length incorrectly - eg. 7 it would't be exactly correct and if you once edit the string and forget to change the length correctly it will also fail (slightly). Using the method which I use you can modify the string as you want without any risk of the code being broked.

[note that the insert string handling is performed in a case so there is no risk of chosing something which is already taken - it throws a compiler error and then simply try the next...]

To the sequence of changing and saving; I think that it is all working as I expect it to work after your modifications. I think that there are just some details about when things are changed in the temporary parameter buffer, when they are saved to FLASH in a the swap buffer, when the are validated in FLASH and when the program thinks that they are validated which is not exactly as you are expecting it to be.

I must admit that it is a bit complicated but the demo code is an example of how it could all be handled in a real project (because the demo is in fact also a real project...).
I think the things to be noted are:

1. The state validating is exists after a reset. It is only actually checked when loading the parameters from FLASH after a reset so just be changing (event saving to FLASH) you will never get the validating state which you are expecting - it needs the reset (unless you edit the state flag yourself;-)   ).

2. When parameters are modified they are modified in RAM. There are two copies - a temporary version and a working version. Some modifications are made in the working version and so are immediately valid (eg. changing serial port speed - this is done on the fly). Some are changed in the temporary buffer but are not actually used yet. This is valid for IP address and MAC address etc. These can not normally be used immediately because otherwise your present connection would break down
[remember Windows before XP! After a network change you had to reboot! Even with XP it takes some time since the process is not that simple]. Therefore modifying the IP only prepares it to be saved in FLASH. Saving it saves it to FLASH but still doesn't apply it. Network changes are quite critical and we are back in Windows 3.11 teritory. Make a reset and then it is easy...

3. After the reset, the new settings are finally used, but they have been flagged as temporary settings (the old ones are also still in FLASH as well and so can be returned by simply deleting the temporary set - which happens after 3 minutes with no contact).

If you do want to save them to FLASH and reboot with them already fully operational (old ones have been overwritten!) then simply save them using
fnSaveNewPars(SAVE_NEW_PARAMETERS); rather than
fnSaveNewPars(SAVE_NEW_PARAMETERS_VALIDATE);

It may take a little study to grasp the complete concept but you should realise then why your project is responding as it is and then you can modify things as you wish them to be. (there are also some details in http://www.utasker.com/docs/uTasker/uTaskerFileSystem.PDF from 9/14)

Last point.

In fact it is no problem to change IP on the fly if you really want to. Here's an example of how it can be done.

Code: [Select]

                unsigned char newIPAddress[] = {192, 168, 1, 75};
                temp_pars->temp_network.ucOurIP[0] = newIPAddress[0];
                temp_pars->temp_network.ucOurIP[1] = newIPAddress[1];
                temp_pars->temp_network.ucOurIP[2] = newIPAddress[2];
                temp_pars->temp_network.ucOurIP[3] = newIPAddress[3];
                fnSaveNewPars(SAVE_NEW_PARAMETERS);
                uMemcpy(&network, &temp_pars->temp_network, sizeof(NETWORK_PARAMETERS));
                fnDeleteArp();
This sets the new IP to the temporary structure.
It then saves the temporary structure to FLASH (this is valid also after next reset).
Then it copies from the temporary structure to the working structure (from this point IP, TCP etc. use it!!)
It is resommended to delete the ARP table since it will otherwise have entries which are possibly invalid for a new subnet.

The only thing which will cause troubles here is if it is change in an active connection (like via HTTP) since the connection will subsequently fail (the web server will probably show a blank page after a short time since it will time out).
This can also simply be avoided by not making the copy from temp_network to network immediately but rather starting a timer (say 2s). After the timer fires (the web page will have been served with the new details in the meantime) the copy can be effected. The browser has already closed the TCP connection in the meantime so no more error messages. But it will be necessary to connect the next time using the new address since the old one is no longer valid.

As you see, there should be no restrictions. However I still stick to the method with validation and timeouts since it ensures that no device is left stranded with invalid or unknown settings. Normally IP setup is not used a lot and so I prefer to play safe. Don't forget that you can use DHCP and there are various other network tricks allowing IP to be set
using ARP sequences and.... but that is another story!!

Cheers

Mark

3231

NXP^TM M522XX, KINETIS and i.MX RT / Re: moving uTasker

« on: July 18, 2007, 09:54:56 PM »

Hi

If you link a complete project to start at a higher address (but still within FLASH) it will load to the FLASH but will only be started if code handling the reset is ALSO available. This code can simply jump to the start address of the shifted project - as long as it knows where this is;-).
Have you also loaded something to sort this out or is the reset location blank? If it is blank, no code will be able to start.

Moving to the "Bare Minimum" project. This is linked to 0x800 start address.
This is the addres which is called by the Bare-Minimum Boot Loader, which has to be loaded into FLASH at address 0x00000000 (actually it gets the start address of the application from 0x804 and then jumps to it. This makes it compatible with any software which is normally linked to 0x00000000 but simply shifted to 0x800 since the address 0x804 then contains what normally would be the reset vector). In addition, to be totally clean, it also loads the Stack pointer with the value at 0x800:

Code: [Select]

    /* If the uTaskerBoot return (without interrupt) the normal code can run */
    /* we load its SP and the PC and let it continue... */
    move.l  #0x00000800,a0
    move.l  (a0),sp
    move.l  #0x00000804,a0
    move.l  (a0),a0
    jmp (a0)

Check that you have indeed loaded BOTH of the programs to FLASH as the board can only start up when both are present. How to do this with CodeWarrior is explained in the document:
http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF

It is interesting because you can then either debug the boot loader or the application (but not both in C). Set a break at the lines above in the boot loader project and then ensure that the jump from boot to application is working correctly. The boot loader is used by quite a lot of people and so should be fully operational as delivered.

If you would like your application to reside elsewhere simply modify the lines above to correspond to the link address of your code. Note however that your code may not have fixed interrupts in FLASH since these will not be used - it must use a vector table of its own positioned at the start of SRAM - the uTasker demo project works this way and so can be used together with the boot loader. Based on the start address which you specify (0x36000) it is correct to modify the ORIGIN value for flash1 in the linker script file - your code can however not be greater than 40k in size to fit within the 256k FLASH memory. You will not actually need the section flashconfig but maybe set it to 0x36400 to avoid any linker issues, and flash2 can be set to 0x36420 with LENGTH = 0x0009BE0 (total 40k left at end of FLASH)

Good luck

regards

Mark

3232

ATMEL^TM AT91SAM7X and AVR32 / Re: porting uTasker to the winarmgcc

« on: July 18, 2007, 09:03:57 PM »

Hi Emerson

No the simulator can not be used when porting to a different compiler environment. The simulator assumes that the code starts up correctly and the TICK is operating - it can neither check the start up assembler, the way the compiler cross compiles (and any possible errors it makes) nor the memory map on the target.

Therefore the only real tool is the debugger. I haven't used the tools which you are using so can't make any suggestions there. But this is the way that I expect the code to start. If you step through it you can hopefully also see the source during this phase. Either you can use the WinArm start up or try with the "startup_gnu.s" which should be in your hardware directory (in this case you must inform the linker not to use the libray start up files using "-nostartfiles").

Usually the first step after a reset is to set the stack pointers. There are various stack pointers (undefined, abort, IRQ, FIQ, supervisor and system). The following shows setting up one of these in assember:

Code: [Select]

    mrs r0, cpsr                                                         /* Read the status register */
    bic r0, r0, #0x1f                                                    /* Mask out the mode bits */
    orr r1, r0, #0x1b                                                    /* prepare undefined mode */
    msr     cpsr_cxsf, r1                                                /* set mode */
    ldr     sp, = __stack_und_end__                                      /* set undefined stack pointer */
__stack_und_end__ is defined in the linker script file.
See the linker script uTaskerV1.3_FLASH.ld in \Applications\uTaskerV1.3\GNU_SAM7X. Also don't forget that the actually used linker script depends on whether the code will be loaded to FLASH or to RAM (debug version).

In my start up I then call AT91F_LowLevelInit()

Code: [Select]

    ldr     r0,= AT91F_LowLevelInit                                      /* call C code to initialise variables */
    mov     lr, pc
    bx     r0
This contains code to set up interrupts, the speed of the PLL, FLASH wait states and other details, and to copy bss (variables with zero value at initialisation) and initialised variables (a copy from initial values from FLASH to RAM) plus text (if not defined to stay in FLASH).

This is for example how the variables are initialised:

Code: [Select]

    unsigned char *ptrData = &__data_start__;
    const unsigned char *ptrFlash = &__data_load_start__;
    unsigned long ulInitDataLength = (&__data_end__ - &__data_start__);
    while (ulInitDataLength--) {                                         // initialise data
        *ptrData++ = *ptrFlash++;
    }
This requires also that the sections are declared correctly in the linker script file. Since you have no linker errors they seem all to be available.


After returning from this low level initialisation routine the code simply jumps to main() in sam7x.

Code: [Select]

    ldr r0,=main                                                         /* jump to main */
    bx r0

If you get to main, take a look at the stack pointer set up. You should be in System/supervisor mode. The stack pointer should be almost at the top of SRAM (around 0x0020FF00 for SAM7X256 - check that you don't have a smaller chip since this needs the RAM setting in the linker script to be set to 0x00008000 instead!!).

The code should call fnInitHW() and fnUserHWInit(). These should not be able to fail.

The next important call is fnInitialiseHeap(ctOurHeap, HEAP_START_ADDRESS);
This dynamically defines the heap to be used by uMalloc. This is possitioned from the last variable space in RAM and has the size OUR_HEAP_SIZE as defined in config.h. All remoaining SRAM will beb filled with a pattern (default is 0x55).
For thsi to work correctly the top of variables in RAM - supplied by the linker - must be known and correct.
I use     #define HEAP_START_ADDRESS &__heap_end__. If your compiler supplies something else you can put it here but again it seems as though all is available as you can link.

After the heap has been set up, you can check that the variables pucTopOfHeap and pucBottomOfHeap make sense and that the free memory has the expected pattern.

Here is a quick memory map of what is to be expected in RAM.

TOP (0x20ffff) (some stacks may be zero in size)
- Undefine stack
- Abort stack
- IRQ stack
- FIQ stack
- Supervisor stack <-- present stack pointer
...0x55 0x55 0x55...
...
Top of heap (pucTopOfHeap)
..heap memory of size OUR_HEAP_SIZE
Bottom of heap (pucBottomOfHeap )
initialised variables
(possibly initialised text)
bss (zero initialised variables)
BOTTOM (0x200000)

Once you are sure all is correct to here the next step is to verify that the interrupt handling is correct (interrupts enabled, handling correct, ...). After which not a lot more can go wrong.


However it is best to ensure that the memory is all correct before starting with the IRQ verification.


It is unfortunately true that setting up a compiler (even a different GCC version) can cause some heart-ache. Although we write using ANSI C which will enable portability between compiler and processors there is nothing which defines the compiler start up rules. Each time it is an adventure which can either work quickly or can eat up lots of work or free time. Nothing replaces deep understanding of the chips needs, the memory map and the interrupt operation.
I hope that you can make some progress soon and start with your real work.

Good luck

Regards

Mark

3233

µTasker general / Re: updating parameters via the HTTP

« on: July 18, 2007, 08:21:47 PM »

Hi

Yes it does work more or less like that - but the step c is already not necessary. The ideas is to ensure that the user doesn't set something incorrectly and leave a device (possibly on the other side of the world) in a state where it can no longer communicate. Therefore the settings are only permenantly saved after the new settings have been validated, through real use. Since the new settings are loaded after the reset, it is only necessary to perform step b to accept and save them. c is not necessary.

However step a is actually composed of 2 actions. First modify the value (which is displayed as modified) or modify several values. All changes can be reversed by clicking on "Reset changes". When saving them, the reset is initiated (after a short delay to allows the page to be first refreshed).

It is possible of course to change and immediately save to FLASH (parameter system) or save one of the steps but I think that the present solution is not a bad general one.


It is very easy to change the text on a button or change its meaning (although the code can usually easily interpret a single command based on its present state without actually changing the command a button sends).

The present LAN setting HTTP file contains the following:

Code: [Select]

<input type=submit value="Modify / validate settings" name=em>
The button is always displayed as Modify / validate settings

If you change this to

Code: [Select]

<input type=submit value="£vM1 settings" name=em>(example. £v = insert value / string, Modify type 1 - I am assuming that M is not already used)

Your fnInsertString() routine in webInterface.c can handle the case 'M' (and '1' if there are more than one such query) and insert either "Modify" or "Validate" depending on whether it is waiting for validation or not.

You will find a call fnAreWeValidating() which will decide which to do.

Therefore this code will do the trick:

Code: [Select]

static const CHAR cValidate[]  = "Validate";
static const CHAR cModify[]  = "Modify";

case 'M':
if (fnAreWeValidating() != 0) {
/* uStrcpy(&cValue[(sizeof(cValidate) - 1)], cValidate);
   *usLengthToSend = (sizeof(cValidate) - 1) + (sizeof(cValidate) - 1); corrected 21.7.2007!! */
    uStrcpy(cValue, cValidate);
   *usLengthToSend = (sizeof(cValidate) - 1);
}
else {
/*  uStrcpy(&cValue[(sizeof(cModify) - 1)], cModify);
   *usLengthToSend = (sizeof(cModify) - 1) + (sizeof(cModify) - 1); corrected 21.7.2007!! */
    uStrcpy(cValue, cModify);
   *usLengthToSend = (sizeof(cModify) - 1);
}
break;

This technique is very simple but can be used for quite interesting effects. It can for example change colours (see the I/O page where the state of outputs is displyed by setting an appropriate colour).
Or different graphics (jpg etc.) links can be loaded depending on certain states.
Or by modifying a meta tag, the page can be caused to refresh it self at a user definable interval (or disabled), or other links can be jumped to after a small delay depending on variables and states, etc.
State depending java scripts could be loaded...
...In fact the list of examples could go on and on...

Therefore once you have learned how to use this you should find that you have the flexibility to do most things that you need without much complication.

Good luck

Regards

Mark

3234

ATMEL^TM AT91SAM7X and AVR32 / Re: porting uTasker to the winarmgcc

« on: July 18, 2007, 04:15:08 PM »

Emerson

Only remove the thumb flag in the single winARM C-file.
This should only increase the complete code by a very small amount. The present increase is surprisingly large and doesn't sound right.

With the debugger try to work your way through the following porting list. It is probably not complete but it will serve as a starting point to see at about which point the code is failing.

1. The start up code must set up the memory correctly. The link file that I sent should be used as a reference and the start up code must also use the defines there for setting up the various stack pointers.

2. The start up code must initialise PLL, default interrupt handlers and variables – it is best to call AT91F_LowLevelInit() in sam7x.c

3. Then the code must jump to main() in SAM7x.c

4. It has to be checked that the heap initialisation is correct. __heap_end__ is used as start address for the heap (__heap_end__ is taken from the linker script file)

5. The uTasker tasks will then be configured and the timer interrupt (TICK) configured. The interrupts will also be enabled.

6. The interrupt TICK will be called if the low level interrupt handler is working correctly.

Note that I have created a file called startup_gnu.s which is use as a start up file in the project and it contains all that is needed. It is also compatible with the linker script file. Verify that you are using this rather than one supplied with the GNU compiler. Then try to step through the code to see what is working correctly and where it goes wrong.

Once the TICK is operating correctly, the watchdog will be retriggered every 200ms and an output or LED will be blinking (see which one is defined in app_hw_sam7X.h and modify to suit the board in question if needed).
As long as it gets this far the basis is ready and any additional problems will be very specific (compiler specialities like packing, but this should be solved for GCC).

Good luck

Regards

Mark

3235

ATMEL^TM AT91SAM7X and AVR32 / Re: porting uTasker to the winarmgcc

« on: July 18, 2007, 08:06:30 AM »

Hi Emerson

Try compiling this file from WinArm without the -mthumb flag. I have a feeling that the assembler instructions which are throwing errors are ARM mode instructions and so will not assemble in Thumb mode. Since the project is using -mthumb-interwork it is possible to mix ARM and Thumb compiled programs - the compiler sorts out the mode switching.

Good luck

Mark

3236

µTasker general / Re: External EEPROM alternative to M95xxx

« on: July 15, 2007, 04:34:18 PM »

Hi Dean

I am presently going for the ATMEL 45DB041 (512kByte). I am based in Europe and a search has shown that I can get these fairly easily here (I have just ordered 4 in SO-8 and have one on an ATMEL EVB in a leadless package). I didn't find a local supply of the M25PExx types to order a couple for development work and ST doesn't seem to sample them - although they could be ordered through bigger distributors.

I don't have any results just yet but I have been experimenting with windowing on HTTP transmissions. I will still need to test various error cases to ensure that they are all really handled correctly but the increased speed is certainly very useful. My (smaller) web pages are built up (in LAN tests) very quickly and the impression is already much sleeker. The amount of additional RAM is mimimum (I think I have about 3 bytes more per HTTP session at the moment) and the code is not as complicated as I envisaged. As I wrote, it requires more work and tests to be sure but it will certainly be a worthwhile improvement.

Regards

Mark

3237

µTasker general / Re: errors when POSTing

« on: July 13, 2007, 11:42:35 PM »

Hi

I have taken a look at this and simulated a few possible solutions. However what you are trying to do opens up a "can of worms" at both TCP and HTTP levels. I will try to explain all below. But first the more simple answer:

BTW: what's the last if() doing in the above code (i.e. the one with the usPortLen)?

Code: [Select]

    if ((usPortLen) && (HTTP_session->ptrFileStart == HTTP_session->ptrFile)) {
        HTTP_session->ptrFileStart += FILE_HEADER;
    }
This is simply checking for the very first data frame of the post sequence. There must be data (usPortLen != 0), since it is possible to have the very first frame of the post sequence without actually data content, and the file pointer is still at the first position of the file.
The line with += FILE_HEADER is moving the pointer which will be used to save data in a file to the first location after a short header. For more info about how the file system and this header work you can look at the document: http://www.utasker.com/docs/uTasker/uTaskerFileSystem.PDF


Now back to the more tricky stuff...

The best way to see exactly what is happening is to look at the network data using Ethereal.
The browser starts posting data and somewhere during the post sequence you return a web page informing that the post has failed during the transfer. This is OK. The page is served correctly but browsers don't display what has been sent while they are still in the process of posting (although the page is actually waiting to be displayed once the post has terminated).

What you want to do is to inform as fast as possible that the post has failed, even before the post has terminated, but the browser is against us here. What needs to be done is to stop the Browser posting so that it can finally display the error message.

When the HTTP server has served the error page it requests a close of the TCP connection (the HTTP server is working in HTTP1.0 mode and this is normal). And now we get into TCP teratory because you will see that a FIN is sent and the TCP state TCP_STATE_FIN_WAIT_1 is entered. However since the browser is busy posting data, the TCP connection will not close - this is allowed, so the Browser side will acknowledge the FIN but not send its own just yet. This puts TCP in the TCP_STATE_FIN_WAIT_2 state, waiting for the other side to finally finish what is is doing and terminate the connection.

Now we come to the question as to what do we actually do with the data which we are receiving although we don't want it. If we just ignore it (which is in fact what is happening in your test case) the Browser will get stubourn and repeat until it finally realises that the connection is in fact dead. This is the reason why it is taking a very long time.

It would be possible to immediately reset the connection so that the post really terminates immediately but the result is that the Browser displays its own error message rather than the nice side which you have just served. This is therefore also not a solution.

So you finally realise that the only way to display the error message is in fact to receive all of the data (dumping it on the way if you like). At the end, either the page which was served will finally be displayed by the browser or else you can serve it in response to the status of the download (which is how the uTasker demo does it).

My conclusion is that I can't find a way to stop the browser posting and display the message served without letting the post terminate normally. I wonder whether anyone else knows of a possibility!!

What I have done is modified the TCP file slightly so that it automatically acks all received data when in the FIN_WAIT_1 and FIN_WAIT_2 states - find the file at www.uTasker.com/software/test/tcp.zip (always use the project password). See the test define "MJB_13_7_2007". This will allow your code to work without the long delay, but it still won't actually be noticably faster than serving the page at the end of the complete sequence.

I am sorry that I can't suggest an alternative at the moment but I hope that what is seen is now understood.

Regards

Mark

3238

ST^TM STM32 and STR91XF / Re: STR91XF Pre-release

« on: July 13, 2007, 12:53:01 PM »

Update 2: http://www.uTasker.com/software/STR91XF/STR91XF_Update_2_RIDE.zip

Hi STR91 Users


This upgrade adds a Raisonance RIDE project which builds with the GNU compiler.

The Raisonance kit is useful since it includes the low cost RLink JTAG debugger (works very well with ST CAPs program) and several STR daughter boards to insert into the REva development board. It includes the RIDE IDE which allows building complete GNU projects but has limited debugging (16k in RAM). When I bought mine it was on special offer from EBV at €99.

Raisonance has a very good forum where questions are answered very quickly - http://www.raisonance.com/Forum/punbb/viewforum.php?id=6

 
This upgrade updates the str91xf.c hardware file with a small modification for GNU. It also includes a start up file for GNU which I have modified from the original delivered by Raisonance due to errors and missing initialisations that it originally had. This should be placed in hardware/str91xf.

The RIDE project directory (RIDE_STR91XF) should be placed in application\uTaskerV1.3\ It contains the project and linker script to suit the project as well as downloadable code which I generated. To open the project simply open utaskerv1.3.prj in the RIDE IDE (drag and drop to the IDE works as well).

I am hoping that it was possible to make the project completely ‘relative’ so that it will work without having to set any paths. Please tell me if it necessary to modify anything to get it to work on another machine.

Here are my notes and some issues that I have had with RIDE 06.10.22, Build number BN745-ST7-ARM-80C51 (there is a new patch available but I haven’t tried to see which of the problems are solved by it)

1. Whenever I build (Make) all files are recompiled. I can't find the make file being used and don't know what the problem is.
2. Each time starting debug mode the project is rebuilt (all files as in 1) and I don't find a method of setting the debugger not to rebuild each time (which is possible in most IDEs).
3. The download time is very long (including the problem 1) - about 1 minute each time. [Comparing with other IDEs which I also use, this is about 10x slower, even when the others program to FLASH rather than to SRAM].
4. Stepping through code is also very slow - other IDEs are also about 10x faster.
5. The internal peripheral register view seems to be restricted to a few like SCU and GPIO - the many others are not there and can only be looked at by viewing their memory addresses.
6. The object and list files created when compiling each file are being put into the same directory as the file. Thsi means that the project base (shared by various processors and compilers) gets full of many files which then have to be removed manually. Is there a set up possibility to compile to a central directory (as possible with most other IDEs - eg. to debug or release or object directory etc.)
7. It doesn't seem to be possible to add header files to the project - when these are added the compiler tries to compile them and the build fails. This means that configuration files have to be searched for and opened in order to change them which is not very nice.
8. I haven't found a method in the IDE to set the generation of a PSA files (objdump).

 
Note that this is a list that I compiled quiet a time back. Raisonance answered my question and some of them may have been solved in the meantime. The original post is here: http://www.raisonance.com/Forum/punbb/viewtopic.php?id=2068


A new problem which I found is that my IDE doesn’t correctly set the thumb mode and inter-working GCC flags. Therefore I have modified the project options to do the same thing ‘manually’. I have reported this to Raisonance [http://www.raisonance.com/Forum/punbb/viewtopic.php?id=2247]. In the project I simply added –mthumb and -mthumb-interwork to the GCC C options under ‘more’ and -mthumb-interwork to the asm options. Raisonance has in the meantime answered this and it is thus possible in the IDE.

My tests of the code running on my board were successful with one exception. A GIF image on the start side of the web server doesn’t load. It sends an empty TCP frame where the start of the GIF is expected. The same project runs correctly when compiled with the IAR compiler and an equivalent build with GNU for Coldfire also runs correctly so this must be a local compiler issue. I haven’t attempted to debug it yet– it  since I also only have the Light version of RIDE (I debugged the port with my IAR debugger from FLASH in assembler mode which was not so difficult, but this could be rather more complicated in assembler mode…).

For those with the REva and RIDE I would be grateful for feedback on whether all works for you – possibly someone can also take a look at the known problem with the GIF.

My next step will be to make a stand-alone build for GNU (using CodeSourcery package) – theoretically this should not be too difficult since RIDE is also GNU based and I hopefully solved the main difficulties (mainly in the LD and the start-up code). It may then be possible to debug with Eclipse (see James Lynch’s later article for the SAM7X – I am hoping that it will also be possible with the STR91: http://www.megaupload.com/de/?d=U1MBMEIU ).

Good luck

Regards

Mark

3239

ST^TM STM32 and STR91XF / Re: STR91XF Pre-release

« on: July 13, 2007, 12:44:03 PM »

Update 1: http://www.uTasker.com/software/STR91XF/STR91XF_Update_1.zip

Hi all STR91 users / testers


1. CPU Speed.
To set the PLL speed there are the following defines in app_hw_str91xf.h.

Code: [Select]

#define CRYSTAL_FREQ    25000000                                         // crystal or clock input frequency (4 to 25MHz)

#define OSC_DIVIDE      25                                               // 1..255

#define PLL_MUL         192                                              // 1..255

#define POST_DIVIDE_EXP 3                                                // 0..5 (3 for 48MHz, 2 for 96MHz)
 

You no doubt know that the STR91 can operate at up to 96MHz. This setting is however for 48MHz operation. The various register settings can be modified to generate various speeds and there is a checking routine which will cause a compile error to be generate if the user tries to set anything with an illegal value (eg. the PLL intermediate frequency must be between within 200 and 622MHz ). See the users’ manual for detail – section 2.4.

To work with 96MHz clock POST_DIVIDE must simply be set to 2 instead of 3.

Note also that when the uTasker simulator is running it displays the exact PLL frequency that the CPU would be running at.

Running at 48MHz is no problem. However to achieve fastest operation there are a number of settings which have to be correct. I have used the ST application note http://www.st.com/stonline/products/literature/an/13563.pdf as reference.

The project does however adapt itself according to the PLL. For example, the PCLK should not be faster than 48MHz and so dividers must be set when the PLL is greater. Then the FLASH wait states has to be increased when operating at over 66MHz. See fnSetFMI() in str91xf.c – here I have had to make a correction so that it operates correctly from bank 0 and bank 1 at all selected speeds.

Then there are some new errata. It is best to collect these from the ST web site. One important point to note is that the original chips (rev. B and D for example) have a problem at 96MHz which means that a reset is only effective when it is a power up reset – this means that debuggers can not really work at 96MHz- check the chips you have on your boards to see whether you have this limitation!! If you do (which is unfortunately very likely), stick to 48MHz for the moment.

There are also some errors (also in the last silicon) to do with clock dividers. In fact I got caught out and I still believe that there is another bug which means that it is in fact necessary to set PCLK to RCLK/8 to get it to divide by 2!! See the following forum discussion for full details about the state of development: http://mcu.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=5460&forum=21

 
2. PHY. I tested the PHY and found that although it is responding correctly I am not getting the expected interrupt on link up/down. I also found out that the ST PHY doesn’t correspond to the typical PHY register set so I have had to change the defines for it in the header file. This is an open point – see the following forum posting for more details: http://mcu.st.com/mcu/modules.php?mop=modload&name=Splatt_Forums&file=viewtopic&topic=5489&forum=21

 
However this doesn’t actually affect normal operation – there is just no link up/down events of they were needed.

3. I have added low power support (define SUPPORT_LOW_POWER in config.h) but haven’t actually verified it yet… This uses the IDLE mode of the chip to stop the CPU clock when there is no processing to be performed. As soon as a peripheral interrupt arrives it should continue operation. I have used this successfully with the Coldfire and the SAM7X so I am hoping that it also works well on this chip.


Plan of attack:
- I still have to test the boot loader. The project compiles and I have already successfully used the boot loader with the chip (although not yet over Ethernet).
Since the boot loader occupies only 2k of an 8k FLASH block in Bank 1 I think that it will be useful to add also loading via UART.
- Then I plan to configure a RIDE GNU project (I have successfully used RIDE with the STR91 but it is some time ago and needs main and boot builds).
- Once the RIDE project is good there will be a GNU build but I would then like to use a stand-along GNU build and probably an Eclipse project with it.


If you have any remarks or results from your own tests please let me know.


Thanks for your help.


Best regards


Mark

3240

ST^TM STM32 and STR91XF / STR91XF Pre-release

« on: July 13, 2007, 11:51:09 AM »

Hi All

Please note that the state of the STR91XF project is pre-release but any one who would like to use it and/or help to complete final tests and fine tunings is welcome. Simply fill out the standard application form to get a link and password to it.

Please use this thread for feedback and I will be using it to inform of patches and other details during the last phase.
Note that a couple of updates are included from the past to ensure than anyone watching is up to date.

Regards

Mark