Service Pack 3 including SPI FLASH based boot loader and GCC builds

[mark]

Hi All

Please note that service pack 3 has been made available on the SP page: http://www.utasker.com/software/softwareV1.3.html

The following is an overview of the additional support and a quick guide to using it with the new GCC boot loader support.

Regards

Mark




Beta - Service Pack 3

This intermediate version is planned as final Beta service pack before the official Luminary project release, which will contain additional USB CDC support.
As well as updating the project to the present development state, with various LM3Sxxxx improvements, it specifically adds SPI FLASH based boot loader support (for ATMEL, ST and SST parts) with integrated builds for GCC (tested with CodeSourcery - Sourcery G++ Lite 2008q1-126 V4.2.3).

1. Install the LM3Sxxxx SP3 on top of SP2 (which needs to be installed on top of SP1...)

2. Delete the file resource.h from the directory \Applications\uTaskerV1.3\Simulator

3. Rebuild with VS target:
- "LM3SXXXX" for pure simulator build

- "LM3SXXXX plus GNU" for simulator build plus GNU build (check that the bat file \Applications\uTaskerV1.3\GNU_LM3SXXXX\Build_LM3SXXXX.bat has path for local compile. This generates uTaskerV1.3.bin which is a stand-along application (without boot loader)

- "LM3SXXXX BM plus GNU" for simulator build plus GNU 'bare-minimum' boot loader build (check that the bat file \Applications\uTaskerV1.3\GNU_LM3SXXXX\Build_BM_LM3SXXXX.bat has path for local compile. This needs the boot loader project to be already compiled and then links it with the application code as uTaskerBM.bin for simple download (eg with LM Flash Programmer). This also generates z_Upload.bin which can be loaded via Ethernet to the board.

4. The boot loader project can be build using \Applications\uTaskerBoot\GNU_LM3SXXXX\Build_LM3SXXXX_BOOT.bat

5. The file \Applications\uTaskerV1.3\config_sp3.h is supplied as reference to the latest configuration. To build the project as tested for the SP3 release simply rename it to config.h
The settings were used to test firmware uploads using an SST SPI FLASH.

6. For full details concerning changes in each file review the header information.

7. Rowley users: please see the following for information about debugging the project in Crossworks (thanks Martin):
http://www.utasker.com/forum/index.php?topic=520.msg2305#msg2305

[robo]

Hi Mark!

I think that i found some bugs in SP3 (i was testing on LM3S6965 board):
- in simulator doesn't work dhcp resolving (but on real target works)
- status led doesen't blink

Regards,
robo

[mark]

Hi Robo

I the SP3 reference config.h the define USE_MAINTENANCE is deactivated. This may stop the status LED blinking since it won't set it as an output. However in app_hw_lm3sxxxx.h there is a new define which allows the status LED to operate even when the USE_MAINTENANCE (basically the menu driven command line interface) is removed:

    #ifdef USE_MAINTENANCE
        #define ENABLE_LED_PORT()      RCGC2 |= CGC2_GPIOF; SRCR2 &= ~CGC2_GPIOF; // clock port and ensure not in reset
    #else
        #define ENABLE_LED_PORT()      RCGC2 |= CGC2_GPIOF; SRCR2 &= ~CGC2_GPIOF; DEMO_DIGITAL_ENABLE = BLINK_LED; DEMO_LED_DDR = BLINK_LED; // clock port and ensure not in reset
    #endif

This is however only there for the EK_LM3S8962, EK_LM3S3748, EK_LM3S3768, EK_LM3S5732 and _LM3S2110 boards. It has not been added for the EK_LM3S6965.

This means that you can either activate USE_MAINTENANCE or modify the following in the EK_LM3S6965 block in app_hw_lm3sxxxx.h

    #define ENABLE_LED_PORT()          RCGC2 |= CGC2_GPIOF; SRCR2 &= ~CGC2_GPIOF; // clock port and ensure not in reset

to

    #ifdef USE_MAINTENANCE
        #define ENABLE_LED_PORT()      RCGC2 |= CGC2_GPIOF; SRCR2 &= ~CGC2_GPIOF; // clock port and ensure not in reset
    #else
        #define ENABLE_LED_PORT()      RCGC2 |= CGC2_GPIOF; SRCR2 &= ~CGC2_GPIOF; DEMO_DIGITAL_ENABLE = BLINK_LED; DEMO_LED_DDR = BLINK_LED; // clock port and ensure not in reset
    #endif

This has also to be moved down below the DEMO_LED_PORT define.


The DHCP problem may occur if you use the default MAC address 00-00-00-00-00-00 in the simulator. Some DHCP servers don't like this and won't give IP settings to it (others don't care and do...). Try setting a 'normal' MAC address to the simulated device to see if it helps.

Regards

Mark

[robo]

Hi Mark,

Thanks for answer. With LED is clear but there is still problem with DHCP (only in simulator) even with MAC ohter than 00-00-00-00-00-00

Regards,
robo

[mark]

Hi Robo

There were no changes to DHCP and this should be purely a SW layer, so not device specific.
Since DHCP uses UDP it may be that there is a problem with UDP offloading in your NIC. Check the following:

http://www.utasker.com/forum/index.php?topic=180.0

I did find that NetBIOS stopped working when simulating and this was due to Vista using UDP offloading (this also started quite suddenly so it may be due to a Vista SW update setting being changed (?)). After disabling this setting NetBIOS was OK again when simulating - this would however also stop DHCP working but wouldn't be noticed with TCP protocols and ping.

Regards

Mark

[robo]

Mi Mark,

I have new problem in SP3:
in option with SPI_FILE_SYSTEM and SPI_FLASH_ST when i try to send files via ftp it doesn't work (system is reseting)

regards,
robo

[mark]

Hi Robo

I tested with SST on the LM3S8962 (FTP and SW uploading).

I will repeat with LM3S6965 and ST FLASH and report back. In the mean time, can you tell me whether results are the same in simulator and on target? Have you also checked that the settings all match your SPI chip?

Regards

Mark

[robo]

Hi Mark,

I was tested only with real target and STM25P80 flash chip.

It was working with SP2...

regards,
robo

[mark]

Hi Robo

Are you using program flash or data flash?

#define SPI_DATA_FLASH for data flash (more suited to file system use).

I have just made a clean install of SP3 and tested
SPI_FLASH_ST + SPI_FLASH_STM25P80 (with and without SPI_DATA_FLASH) first in the simulator. This hasn't show any problems yet. (Neither on simulated LM3S6965 or LM3S8962).

The build with GCC was OK. There was one warning:
../../../Hardware/LM3SXXXX/spi_flash_lm3s_stmicro.h:220: warning: unused variable 'ulDummy'
which is OK.

Are you compiling with GCC?

Now I will move to a board, but I don't have any STM25P80 at the moment. I will have to build a circuit with STM25P64 (8Meg) - but I expect the result to be equivalent.

By the way, can you do a FTP DIR successfully? Is the file system empty or corrupted? What happens when you try to brows to the board with a web browser?

Regards

Mark

[robo]

Hi Mark,

Yes I compile with GCC, and project builds witout problem...
When I  try to browse the board with web browser there is no problem, but when I try co copy file to ftp it doesn't work. (When I open ftp i file system is empty)

regards,
robo

[mark]

Robo

Which file do you try to copy?

Regards

Mark

[mark]

Hi Robo

I tested on the target and found that I could load pages via FTP but the pages were not in SPI FLASH afterwards (but no crash).
So I searched for the reason why they were not being saved correctly to FLASH and found an unexpected change in the file spi_flash_lm3s_stmicro.h. This file has a newer date but the content should not have changed - the error seems to be a mistake made when using this file as a reference for creating the SST version. While copying a block of code its content must have been deleted by mistake!

To correct this, either the version from SP1 can be used or the following block corrected:

At the end of fnSPI_command():

    if (ucCommand != READ_DATA_BYTES) {                                  // commands that have only written wait here for transmission to complete
    }
(which is empty!!!!!!!)

to

    if (ucCommand != READ_DATA_BYTES) {                                  // commands that have only written wait here for transmission to complete
        while (SSISR_0 & (SSI_BSY | SSI_RNE)) {                          // wait for transfer to complete and clear rx buffer
            volatile unsigned long ulDummy = SSIDR_0;
#ifdef _WINDOWS
            SSISR_0 &= ~(SSI_RNE | SSI_BSY);
#endif
        } 
    }

When writing some commands the CS line was being deasserted before the command had been completely sent. This meant that the WRITE_ENABLE command was not being accepted and so FLASH was not allowed to be changed.

During the investigation I also noticed that after reads the status register was unnecessarily being checked. This can be removed by commenting out the following line of code, which is unnecessary in this driver. This is a useful optimization and not a correction to an error case.

    case READ_DATA_BYTES:                                                // read data from the chip
        SSIDR_0 = (unsigned char)(ulPageNumberOffset >> 16);
      #ifdef _WINDOWS
        fnSimSTM25Pxxx(STM25PXXX_WRITE, (unsigned char)SSIDR_0);         // simulate the SPI FLASH device
      #endif
        SSIDR_0 = (unsigned char)(ulPageNumberOffset >> 8 );
      #ifdef _WINDOWS
        fnSimSTM25Pxxx(STM25PXXX_WRITE, (unsigned char)SSIDR_0);         // simulate the SPI FLASH device
      #endif
        SSIDR_0 = (unsigned char)(ulPageNumberOffset);
      #ifdef _WINDOWS
        fnSimSTM25Pxxx(STM25PXXX_WRITE, (unsigned char)SSIDR_0);         // simulate the SPI FLASH device
        SSISR_0 &= ~SSI_BSY;                                             // clear flag for simulator
      #endif
        ucTxCount = 3;
      //SPI_FLASH_Danger[iChipSelect] = 1;                               // {1} in this case this marks that no 0xff have been set to tx when reading (it will be cleared before exiting)
        break;


I didn't have a crash but I may have been testing differently to you (also the FLASH was new and completely empty), but this error is certainly in the SP3 version.
I hope that the change proves successful for you!

Regards

Mark

[robo]

Hi Mark,

You have right! Now it's working good.
Thanks for help!

Regards,
robo

[mhoneywill]

Hi Mark,

These are my experiences of getting the simulator working with SP3

My experience loading uTasker SP3 on an LM3S6965 demo board.
 
I'm using Rowley Crossworks V1.7 build 16 as my arm compiler
and Visual Studio 2008 SP1 as my windows compiler.
 
This is the sequence I followed.
 
1. I did a clean install of the uTasker LM3Sxxxx beta software
 
2. I then applied SP1, SP2 and SP3 in order
 
3. I made the changes detailed in the forum relating to SP3
 
4. I renamed config_sp3.h to config.h
 
5. I undefined SPI_FILE_SYSTEM in config.h (I was not using that)
 
6. I selected EK_LM3S6965 as the target device
 
7. I opened uTaskerV1-3.dsp is VS2008 wheich converted the project into a VS2008 project
 
8. Next I tried to compile the simulator, It failed to compile with the following error
   Error   1   error RC2104 : undefined keyword or key name: ID_WIRESHARK_REPLAYLASTFILE   
   The only way I could get it to compile was to make the following changes to the uTasker.rc file

    POPUP "&Wireshark"
    BEGIN
//        MENUITEM "&Replay last file",           ID_WIRESHARK_REPLAYLASTFILE
        MENUITEM "&Load Wireshark/Ethereal file to play back", ID_ETHEREAL
    END
    POPUP "&LAN"
    BEGIN
        MENUITEM "Select working &NIC",         ID_LAN_NIC
    END
    POPUP "US&B"
    BEGIN
        MENUITEM "&Enumeration",                ID_TEST_ENUMERATION
//        MENUITEM "&Disconnect",                 ID_USB_DISCONNECT
//        MENUITEM "Attach &low speed device",    ID_USB_CONNECTLOWSPEEDDEVICE
//        MENUITEM "Attach &full speed device",   ID_USB_CONNECTFULLSPEEDDEVICE

    END
    POPUP "&Port Sim"
    BEGIN
//        MENUITEM "&Repeat last script",         ID_PORTSIM_REPEATLASTSCRIPT
        MENUITEM "&Open Script",                ID_PORTSIMULATOR_OPENSCRIPT
    END

10. The project is now working in the simulator

Any ideas why I had to change the uTasker.rc file

Cheers

Martin

[mark]

Hi Martin

You missed step 2:  Delete the file resource.h from the directory \Applications\uTaskerV1.3

This would have forced VS to use the correct header and then you (probably) wouldn't have needed to edit the resource file.

It is a bit of a shame that VS regenerates this resource.h when it gets a new resource file (due to new menu items) because it then uses this (which doesn't match properly) in preference to the one in the WinSim directory. I tried adding the new resource.h to both the central directory (so that it is not project specific) and the application directory but it still overwrites it...

Since this sometimes causes problems (especially when new users start with a fresh base pack and have to install SPs on top - and make a mistake somewhere, causing some unnecessary problems) I will be consistently releasing a service pack (for experienced users who would like to cautiously add features to existing development projects) plus a full SP build as well. The idea of the full build is to ensure that it always works 'out-of-the-box' rather than starting off with a fight to get the project compiled... For some people a file missing from a project is no big deal and they immediate realize that it 'simply' has to be added to the project. But experience has show that this is not always the case - there are a lot of people starting out with a lot of new stuff and even quite a (seemingly) minor hitch can result in confusion and unnecessary frustration. The idea of the project is to help development efficiency and to allow people to reduce project times - therefore an improvement of the SP procedure is an important step in the chain!

regards

Mark