S2E design on LM3S9B90

The most important thing you'll need to do is adjust the GPIO pin configurations.  UART0 will be in the same location on both devices (PA0/1), but UART1 may be moved around.  Other than that, there isn't much else that I can think of that would need to change.

Thanks for your reply. I did this changes:

1. device change:  General\Target\Device\LM3SxBxx
2. debugger setup: Debugger\Setup\TI Stellaris FTDI
3. removing definitions of XVR pins in "config.h"
4. changing UART pins positions (RTS0->PB2, CTS0->PB3, Rx1->PD2,Tx1->PD3, RTS1->PB5, CTS1->PB6)
5. deleting XVR pins setup in "serial.c"
6. adding interrupt handler lines in "startup_ewarm.c"
    IntDefaultHandler,                      // USB0
    IntDefaultHandler,                      // PWM Generator 3
    IntDefaultHandler,                      // uDMA Software Transfer
    IntDefaultHandler,                      // uDMA Error
    IntDefaultHandler,                      // ADC1 Sequence 0
    IntDefaultHandler,                      // ADC1 Sequence 1
    IntDefaultHandler,                      // ADC1 Sequence 2
    IntDefaultHandler,                      // ADC1 Sequence 3
    IntDefaultHandler,                      // I2S0
    IntDefaultHandler,                      // External Bus Interface 0
    IntDefaultHandler                       // GPIO Port J
7. change defines FLASH_PB_START to 0x0003f800 and FLASH_PB_END to 0x00040000 in "config.h"
8. FLASH and SRAM region change in *.icf file
    define region FLASH = mem:[from 0x00001000 to 0x0003f7ff];
    define region SRAM  = mem:[from 0x20000000 to 0x20017fff];
9. and system clock setting in the main
    SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);  //80MHz

When I download the code and push GO, FINDER utility can't find board. When I stop the debug, I don't know where the code
currently is, probably somewhere in the data memory (I am new in ARM design and IAR IDE). Consequential stepping don't affect
position in memory.
   
Ondrej

I just remembered that the flash location is different on the 9B90 as well.  Since that device has the bootloader in ROM, you should load the application to address 0 in flash, not 0x1000.  My guess is that you're in the ROM bootloader when the application appears to be lost.

I changed start address and now it works, thanks. But LED diodes doesn't work (I don't know why, it is on same positions PF2/3 for both boards). After downloading design to the board and pushing GO button, than I can see board in FINDER, and I can send small amont of continuous data to one interface and receive it on another interface.  When I reconnect the board on USB (power cycle), board doesn't work, neither FINDER. Can you please help me with this questions?

1. Why LEDS doesn't work?

2. I can send and receive only small amount of continuous data bytes (thousands of bytes), will adding of handshake capability (RTS, CTS)  solve this problem?

3. Application should be programmed in FLASH memory, why board doesn't work after power cycle? I didn't make changes in *.icf, only size of FLASH and SRAM, as we mentioned above.

4. Web pages is very slow, tens of seconds for loading whole page, why?

Thank very much for your time.

You must update the ICF file... it thinks flash starts at 0x1000.  

The LEDs most likely do not work because of the pin muxing differences between the two devices.  I suggest taking a look at the datasheet to understand the basics of what you're working with.  You will most likely need calls like GPIOPinConfigure(GPIO_PF2_LED1) and GPIOPinConfigure(GPIO_PF3_LED0).  

I don't know why you're seeing performance issues, but you need to concentrate on the basics first.  Once you have the application running reliably from flash (including power cycling), then shift focus to performance.

Hi Eric. My problem after power cycling is probably happenning only when I use PLL, for example:

SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);
or
SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);

With this settings code works OK after downloading and starting with GO. After power cycle code sometimes runs for a while (I add peace of code, it writes push button state to the user LED), finder can see board (sometimes), than code hangs. When I use "debug without downloading" after power cycle, code runs without any problem.

Without PLL:

SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);

code runs, no matter on power cycling. Could you please help me with this problem? I use stellaris ware 7243 and IAR 6.10.

Thanks

I find it a bit strange that the software would be so hit-and-miss when using the debugger.  I can't think of anything that would cause the PLL to make this happen, so I suggest using the debugger to determine what's going on when the code hangs.  Look at the call stack and, if a fault is occurring, examine the exception stack frame to determine the cause.

All of the StellarisWare projects have defines for Tempest class devices (for example, CLASS_IS_TEMPEST and REVISION_IS_B1), so perhaps that's a reason why the behavior is changing.  However, these defines don't impact SysCtlClockSet().  You also should remove the code at the beginning of main() that checks the LDO voltage.  This is not applicable to Tempest.

Yesterday I didn't see any problem when I started program from debugger, after power cycle my program crashed frequently (without debugger I couldn't locate where the program stop working). Today I can se problems with starting code from debugger too, program stops in Fault ISR (see attached figure). Now I have another problem, I couldn't write to my flash memory (too many errors). I find FLASH issue in ERRATA document. I find problem with packet corrupting when auto-clock gating is used (this is used in code which I porting, but I can't try code without this clock gating due to the FLASH is dead now...).

Now I don't know what to do. I can't use RAM-debug, RAM is too small for our project. We need one port serial to ethernet convertor (based on S2E design), and possibility of transfering video frames to ethernet interface (using uDMA and EPI). Flash issue has each chip from 9000 series, but uDMA has only 9000 series. I would like to use stellaris
for our project (I like stellaris ware, TI E2E Community, PHY layer on the chip, etc.), when do you plan fix problem with FLASH memory write cycles?  Any advice?

Thanks

What did you do with the clock gating that made your flash appear dead?  The S2E application really should work with only a few minor changes, so I'm wondering why you started to make changes when the basics weren't working.

You can try to recover your device if you think something has happened to it by using the debug port unlock feature in LM Flash Programmer.  When you get a fault, you can examine the exception stack frame in RAM to see what caused the fault.  My guess is that you're faulting because you modified clock gating settings, and accesses to peripherals that have a bad clocking configuration is generating the fault.

The flash errata is not pretty, but it is what it is.  There is no firm schedule on a fix.

I didn't do any changes with clock gating, not yet. I only noticed bug in errata document "Stellaris LM3S9B90 Rev B1 Errata (Rev. P)" that it can be problem
of packet corrupting when use clock gating (Ethernet receive packet corruption may occur when using optional auto-clock gating). In S2E design, clock gating
is enabled, so I mean that could be problem. Do you mean that S2E design can operate correctly on LM3S9B90 with clock-gating? Until now, I do only changes which
I mentioned in my second post and some tests with clock source (SysCtlClockSet), but code didn't work correctly.

Now I tryed device unlock and it works (flash programming is ok now). I put breakpoint to the Fault ISR and wait for it (clicking in the web pages). When breakpoint was reached, I made screenshot (see figure please). Memory content is:

    SP ->   20 00 27 C8
                 20 00 67 70
                 20 00 67 70
                 00 00 00 00
                 00 00 00 32
                 00 00 FB 0B
                 00 00 00 00
                 00 00 00 3A             next addresses all zeros

previous PC is 0x00000000 or 0x0000003A ? => in disasembly it points to SysTickHandler or to the begin of memory
       

I am sure, that I overreached 100 flash write cycles (I do some lwip throughput measuring an another tests).
I am wondering what happens when I overreach 100 flash write cycles? I can use more chips for product designing, it isn't big problem.
But when we need possibility of storing user parameters for our customers, we cannot use onchip flash memory (same as S2E design), right?
Guarantee of 100 write cycles is very low for this purpose.


my questions is:

1. Clock gating on LM3S9B90 and ethernet packets
2. PC content before my Fault ISR
3. Flash behaviour after 100 flash write cycles, when using it for user parameters same way as S2E


Thank you for your suggestions!

I tried porting the S2E code to the DK-LM3S9B96 today to see if I had any trouble.  I had it up and running in about 10 minutes, so there's still something missing from your code.  Here's what I did:

1. Update linker/scatter file to locate the application at 0x0.  This will prevent the firmware update feature from working, but that's OK for this experiment.

2. Account for pin multiplexing.  For the DK-LM3S9B96 there is a special file called set_pinout.c in the StellarisWare/boards/dk-lm3s9b96/drivers directory.  I admittedly didn't test everything, but the basics work.  You can accomplish the same thing on the '9B90 by using GPIOPinConfigure() calls.

3. A big one that I forgot to mention to you was that the clock setting needs to change.  The S2E board uses a 8MHz crystal and the 9B9x kits use a 16MHz.  Therefore, SysCtlClockSet() needs to be updated accordingly, otherwise the PLL will be out of whack.

With these changes, I was up and running.

Your stack frame seems goofy.  I'm wondering if the clocking (discussed in item 3 above) is the reason this is happening.

I try only changes same as you (1, 2, and 3), yes it is working in few minutes. But situation is same. I can see web pages in my browser and transfer data bytes between interfaces, but when I switching frames in web browser after few minutes code freeze in Fault ISR. After that my stack is:

R13 (SP) => 0x20007B90

memory:   

0x20007B90    e8 22 00 20 00 00 00 00 01 00 00 00 f8 22 00 20
0x20007BA0    00 00 00 80 53 ca 00 00 00 00 00 00 3a 00 00 00
0x20007BB0    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

For this test I use clock setting

SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |  SYSCTL_XTAL_16MHZ);

I do only changes same as you, but situation is very similar to my tests which I did before. My question again, should it be problem with enabled Clock-gating (bug described in Errata document)? If not, where is the problem? I try connect my board directly with notebook, and over net in our office too, results is same. I try my board with "enet_lwip" design writed directly for my board, it runs without any problem.

My guess is that there's a stack problem in your code.  Since it starts off working, but fails after a while, it's likely a stack overflow, pointer corruption, or some other software bug.  It's possible that there's a race condition somewhere.

I seriously doubt that it's a clocking problem since your code works for a while, unless you are changing the setup for the system clock while your code is running.

I agree that the stack could be the problem here.  Your stack frame doesn't appear to have valid data when the fault occurs.  Try increasing the stack size to see if that helps.

I realize that I didn't answer your question about the flash cycles.  The 100 cycle number is the limit of the device in order to retain data for 10 years.  You can have thousands of cycles over a short period of time (development) and not see a problem with the flash.  However, if you go over that 100 cycle number, the device will not guarantee data retention over 10 years.

Thanks Eric for flash write cycles clarification. Thanks slandrum for your suggestion, I fill stack memory area by known values and start program, when it hangs in Fault ISR, almost all known values are rewrited by periodical pattern (for example 00 00 22 22). Rewrited is much more bytes than is stack area (I try 2048 words stack (8kB), but rewrited is almost 64kB). I don't know why this happens, code is nearly same as S2E reference design.