2008-04-16 01:37 AM
STM32 Question
2011-05-17 03:29 AM
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.2011-05-17 03:29 AM
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.2011-05-17 03:29 AM
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.)2011-05-17 03:29 AM
2011-05-17 03:29 AM
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(); } }2011-05-17 03:29 AM
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.
2011-05-17 03:29 AM
could you post a link to the description of this problem of the Stellaris or to the recovery method?
2011-05-17 03:29 AM
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.2011-05-17 03:29 AM
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.''