Home arrow Support arrow Forums

Luminary Micro Forums

<< Start < Prev 1 2 Next > End >>

rallison

Expert Boarder
Click here to see the profile of this user

2008/04/07 10:50

Sandstorm vs Fury and Device Recovery

I have two questions:
1. Which parts are Standstorm and which are Fury?

For the second question I need to give some background. I have repeatedly gotten a LM3S2965 (Fury) to "lock-up" then I use the Debug Port unlock feature of the LM Flash Programmer while holding the reset line low. This erases the part and I am in business again. The lock-up has been from different aspects such as wrong oscillator configuration or incorrect configuration of peripherals, none of these were from reconfiguring the JTAG port.

I have also "locked-up" multiple LM3S317 (Sandstorm) parts and I can't seem to recover them. I'm trying to evaluate the usefulness of these parts and I can't seem to proceed after a lock-up.

2. Is it possible to have an unrecoverable Sandstorm part?

login or register to reply

LMI Eric

Moderator
Click here to see the profile of this user

2008/04/07 11:19

Re:Sandstorm vs Fury and Device Recovery

The Sandstorm class devices are the 28- and 48-pin devices, and the Fury class are the 100- and 108-pin devices.

One thing you might want to try with your lock-up problem on Fury class devices is raising the LDO voltage to 2.75V to compensate for the PLL errata. This errata can cause your device to act strangely.

Unfortunately the Sandstorm class devices don't have the recovery mechanism like the Fury devices do. The recovery mechanism relies on timing, so if the offending clock configuration, JTAG pin switch, or whatever else happens before the debugger can break in, you're out of luck. You also need to use an evaluation board in debug out mode to unlock a Sandstorm class device since the eval boards have control over the RSTn signal through the FTDI chip. The timing sequence relies on precisely timed reset and JTAG sequences. The RSTn signal on the JTAG header of the eval board should be attached to the RSTn signal of the target board.

Post edited by: LMI Eric, at: 2008/04/07 11:20

login or register to reply

rallison

Expert Boarder
Click here to see the profile of this user

2008/04/07 16:53

Re:Sandstorm vs Fury and Device Recovery

Are there any plans to fix the Sandstorm devices recovery? This could cause major problems a production run of boards using a Sandstorm class part that is mis-programmed and can't be reprogrammed. Many products they would have to be scrapped if they couldn't be reprogrammed.

login or register to reply

cb1

Platinum Boarder
Click here to see the profile of this user

2008/04/14 07:56

Re:Sandstorm vs Fury and Device Recovery

Hi-

Have designed in > 100 48 pin S611 & S308 & have NOT encountered this unfortunate problem.

We do "steal" several JTAG pins - but carefully followed LMI's "JTAG/GPIO"
Test/Switch guidelines. This JTAG as GPIO use does limit our IAR debug ability to some extent - but appears to have enabled us to avoid the dreaded JTAG "lock-out!" (I suppose that we may have been just lucky - uh-oh!)

Have you inserted the small JTAG/GPIO "switch" code EARLY in your program -strictly as a "defense mechanism?" We have lost JTAG use when we "stole" those pins and did not employ LMI's suggested technique.

Just noted that you have NOT altered ANY
JTAG pins - PB7 is the most likely culprit and is tempting to gain "8 bit bus." Some of our clients HAVE altered just ONE of the JTAG pins - even inadvertently - and "then" have "lost" the chip when they did NOT employ Jtag/Gpio test! I hope that our "fix" is REAL - and NOT just luck...

I can imagine how frustrated you are - do hope this writing helps/leads to comfort for ALL Sandstorm 48/28 pin device users.
(We NEED the savings these parts provide)

Would much appreciate a comment from Eric/staff Re: "Does use of JTAG/GPIO switch test code - as suggested by LMI - provide a "DEFENSE MECHANISM" - EVEN AGAINST incorrect Oscillator or Peripheral Configurations - NOT simply "stolen" JTAG pin use as GPIO???

Thanks much for your guidance/comments.

Post edited by: cb1, at: 2008/04/14 08:05

Post edited by: cb1, at: 2008/04/14 08:29

login or register to reply

rallison

Expert Boarder
Click here to see the profile of this user

2008/04/14 22:52

Re:Sandstorm vs Fury and Device Recovery

Thank you for the response. It is always possible that I am doing something wrong. I do a lot of stuff at the register level and it concerns me if setting the wrong bit causes the part to be unusable. Usually there is some overriding method to recover a part. I thought that was the point of Flash. Here is the offending code if you care to try it....


Code:

  // basic.c for the LM3S317 //Declare functions int main(void); void nmi_handler(void); void hardfault_handler(void); //Define the vector table __attribute__ ((section("vectors")))     int const VectorStackTop 0x20000800; __attribute__ ((section("vectors")))     int (* const VectorMain) (void) = main; __attribute__ ((section("vectors")))     void (* const VectorNMI) (void) = nmi_handler; __attribute__ ((section("vectors")))     void (* const VectorHardFault) (void) = hardfault_handler; //Dummy Handlers void nmi_handler(void) {     return; } void hardfault_handler(void) {     return; } //***************************************************************************** // Declarations //***************************************************************************** #define  RCGC2            0x400FE108 #define  RCGC2_GPIOB        1<<1 #define  GPIO_PORTB        0x40005000 #define  GPIODATA          0x0000 #define  GPIODIR          0x0400 #define  GPIODEN          0x051C #define  PB3              1<<3 #define  GPIO_MASK          PB3<<2 #define SYSCTL_RCGC2_P    (*((volatile unsigned long *)(RCGC2))) #define PBDIR    (*((volatile unsigned long *)(GPIO_PORTB+GPIODIR))) #define PBDEN    (*((volatile unsigned long *)(GPIO_PORTB+GPIODEN))) #define PBDATA    (*((volatile unsigned long *)(GPIO_PORTB+(GPIO_MASK)))) //***************************************************************************** // Initialize LED //***************************************************************************** void initLED (void) {     SYSCTL_RCGC2_P=RCGC2_GPIOB;     //Enable Port B clocking     PBDIR=PB3;                //Port B pin 3 output     PBDEN=PB3;                //Port B pin 3 digital enable } //***************************************************************************** // LED on //***************************************************************************** void LEDon (void) {     PBDATA=PB3;     } //***************************************************************************** // LED off //***************************************************************************** void LEDoff (void) {     PBDATA=0x00;     } //***************************************************************************** // Main //***************************************************************************** int main(void) {      volatile unsigned long ulLoop;     initLED();            //Set up LED port         while(1)     {         for(ulLoop 0ulLoop 0x10000ulLoop++)         {         }         LEDon();         for(ulLoop 0ulLoop 0x10000ulLoop++)         {         }         LEDoff();     } }




Here is my linker file:


Code:

  /* Simple Linker simple.ld                        */ /* MEMORY command : Define allowed memory regions    */ /* This part defines various memory regions that the        */ /* linker is allowed to put data into. This is an            */ /* optional feature, but useful because the linker can        */ /* warn you when your program is too big to fit.        */ MEMORY     {     /* ROM is a readable (r), executable region (x)        */     rom (rx)    : ORIGIN 0LENGTH 16K          /* RAM is a readable (r), writable (w) and        */     /* executable region (x)                    */     ram (rwx)    : ORIGIN 0x20000000LENGTH 4K     }      /* SECTION command : Defines mapping of input sections    */ /* into output sections.                        */ SECTIONS     {     . = 0;        /* From 0x00000000     */      .text :    {                 *(vectors)    /* Vector table        */                 *(.text)    /* Program code        */                 *(rodata)    /* Read only data    */             }     . = 0x20000000;    /* From 0x20000000    */     .data :    {                 *(.data)    /* Data Memory        */             }     .bss :    {                 *(.bss)    /* Zero-filled run time    */                         /* allocate data mem    */             }     }



Here are the commands to gcc:

arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb basic.c -nostartfiles -T simple.ld -o basic.o

arm-none-eabi-ld -T simple.ld -o basic.out basic.o

arm-none-eabi-objcopy basic.out basic.bin -O binary

login or register to reply

cb1

Platinum Boarder
Click here to see the profile of this user

2008/04/15 08:25

Re:Sandstorm vs Fury and Device Recovery

Thank you - again we read your post with interest and are concerned that our "skill" may have been substantially "luck!"

We do fast-turn designs - and have programmed in C using IAR & Keil exclusively.
(years ago we used ASM - but have so far avoided it thanks to modern C compilers)

I'm a bit fearful of your operations on Port B - even though you do NOT deliberately alter PB7. (especially about your reset of Port PB3)

Suggestion 1: (I LIKE this) Do NOT deal
AT ALL with Port B! Instead simply change your code to effect Port A - which contains NO possible JTAG "plague!" At minimum - this will remove inadvertent PB7-JTAG alteration as your "culprit."

Again - on a population of > 100 boards with exclusive Sandstorm parts - we have NEVER encountered this "lockout."

*** Eric & staff field many more issues along these lines - they have the best accumulated data to know if our suggestion of using LMI's "JTAG/GPIO" switch test - early in your code - provides ANY "recovery
path" should subsequent code cause Oscillator, Peripheral or any other chip
violation.

Await LMI comment on this important (and
somewhat frightening)issue. I hate to think
that our "LMI expertise" involves a large portion of fortuitous LUCK!

login or register to reply
<< Start < Prev 1 2 Next > End >>