cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 Question

ev64bug
Associate II
Posted on April 16, 2008 at 10:37

STM32 Question

16 REPLIES 16
ev64bug
Associate II
Posted on May 17, 2011 at 12:29

I'm asking this question because I am a little gun shy from the Luminary Micro Cortex-M3.

This is the situation, the Sandstorm Class (28 and 48 pin parts) lack a recovery method of holding the part in reset and then sending a debug unlock sequence to mass erase the part. The Fury class (100 pin parts) solved this problem. I have turned many of the Sandstorm parts into unusable parts because of this problem and the only solution is to replace the part. In my opinion this is a serious problem that should be fixed.

Do all the STM32 parts have a mass erase recovery method? I'd like to find out before investing time in these parts.

16-32micros
Associate III
Posted on May 17, 2011 at 12:29

Dear ev64bug,

Could you please detail a little bit what to you mean ? and waht is your application expectation from this ''mass erase recovery method''. If possible a design real case.

By the way you can refer to STM32 Flash programming Manual for full details about flash programming sequences and also AN2606 for bootloader, this would be interesting for you.

Cheers,

STOne-32.

lanchon
Associate III
Posted on May 17, 2011 at 12:29

pardon my ignorance, are you talking about recovering a part having a firmware that configures the JTAG pins for GPIO out of reset, and then you can't erase it?

the stm32 has the BOOT0/1 pins that can bypass the flash out of reset. so if this happens you can reset and boot into the bootloader and then JTAG. is this what you're looking for? (I don't know if using the BOOT pins is necessary; I don't know what happens when you disable JTAG, never done it.)

ev64bug
Associate II
Posted on May 17, 2011 at 12:29

ev64bug
Associate II
Posted on May 17, 2011 at 12:29

Thank you for the response.

This problem is a little difficult to identify because it has happened on a simple LED blink program that doesn't have any relation to the JTAG pins. It does the following:

1. Set up a simple vector table

2. Enable an I/O

3. Toggle the I/O with a delay

The code downloaded and runs because I can see the LED blink, but the JTAG doesn't respond any more. I took this identical program and ran it on the Sandstorm version and it had the same problem with the JTAG port, but the recovery process allowed me to regain control of the JTAG port.

I was just reading about the boot option and this may prevent the problem I have seen in the Luminary parts.

Here is the 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<

#define GPIO_PORTB 0x40005000

#define GPIODATA 0x0000

#define GPIODIR 0x0400

#define GPIODEN 0x051C

#define PB3 1<

#define GPIO_MASK PB3<

#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 = 0; ulLoop < 0x10000; ulLoop++)

{

}

LEDon();

for(ulLoop = 0; ulLoop < 0x10000; ulLoop++)

{

}

LEDoff();

}

}

lanchon
Associate III
Posted on May 17, 2011 at 12:29

the stm32 has a separate reset pin for JTAG (use is optional). I heard this can be used to halt into debug mode before the first instruction is executed.

lanchon
Associate III
Posted on May 17, 2011 at 12:29

could you post a link to the description of this problem of the Stellaris or to the recovery method?

ev64bug
Associate II
Posted on May 17, 2011 at 12:29

Here is the link to the question I posted on the Luminary Forum:

http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,92/func,view/id,1667/catid,5/

The topic is: Sandstorm vs Fury and Device Recovery

I also found this guy had a similar problem and the only solution was to buy a new kit, this seemed a little disturbing to me:

http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,/func,view/catid,5/id,1241/#1241

The topic is: Big Woops

The real puzzle to me is why the JTAG port seems to be unresponsive. My understanding is that the core and the JTAG TAP are independent. I've also never delt with a Flash part that is unrecoverable. The implications of this are serious in a production environment.

I don't mean to get this off of the topic of STM32 parts. I think if this is not a problem for ST then this is a real selling point over Luminary.

lanchon
Associate III
Posted on May 17, 2011 at 12:29

thanks. it's baffling that your code locks the chip since you're not messing with the core clock or the JTAG pins (so you say). maybe ''SYSCTL_RCGC2_P=RCGC2_GPIOB; //Enable Port B clocking'' disables the clock to some important peripheral (JTAG, flash, etc) or ''PBDEN=PB3; //Port B pin 3 digital enable'' disables some JTAG pin, or something like that.

anyway there's a simple workaround: ''my code will first wait for the push button to be in the released state before I do anything else. That way when I screw up again all I have to do is hold the button down and all will be well.''