Auto-running program from flash memory after reset vs attached to debugger - not working?

[generic]

Posted on February 26, 2011 at 07:30The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on February 26, 2011 at 13:14

Rather than delve into this too much, I'll point out there is a download problem with the ST-LINK and the toolchains, this might be your issue. Use the debug function to ''Load Application at Startup'', which will write the program to flash before starting it, and will run subsequently when reattached. The other alternative is to the get the ST-LINK utility and use that.

[generic]

Posted on February 26, 2011 at 17:56

Clive:

Thanks for the reply here. I really don't care what tool I use as long as I can get my program up and running in a ''standalone'' fashion. Toolchain+ST-Link issue: Thanks for the heads up about the bug. The funny thing is that when I look under the Debug tab under ''Project Options'', I see that ''Load Application at Startup is already checked.'' When you kick off the debugger, there's a slight lag while it looks like the compiled program if flashed to the board as the debugger pops up. Q: This may be a stupid questions but am I targetting the right device in the compiler? I have things set to STM32F103RB (I believe the closest name to the part number I found on the STM32 value line discovery board datasheet) Well, I went ahead and installed the STM32-Link tool as you suggested but I'm not sure what file to feed it. - The output of my toolchain is an AXF file. - The input to the STM32 link tool is a .BIN Q: How to get feed the STM32 tool ? - overriding the file selection filter and selecting the AXF file yields an error message that the ''file size is bigger than the flash size'' - I'm starting at address 0x08000000 (same as the default memory display.) Under the memory display option, are the memory settings as stated below necessary to declare/correct for this board? Address: 0x08000000 Size: 0x20000 (changed from the STM32LINK default -- I found this in my options) Data Width: 32bit Thanks again for your replies. I wish some of this stuff was better documented but I guess this comes from having such a large ecosystem (it's not exactly straightforward on where to start). Regards, -g

[generic]

Posted on February 26, 2011 at 18:06 Ahh, it looks like there's a command line program to go from AXF to BIN

c:\Keil\arm\bin\fromelf.exe --bin --output filename.bin filename.axf

From 

http://www.keil.com/forum/9891/

I'll try this and see if it works. If so, I'll report back. -g

[generic]

Posted on February 26, 2011 at 18:29

1) The fromelf.exe file is actually in C:\Keil\bin40, not c:\keil\bin. 

2)  I managed to get the STM32link program to flash the converted AXF file (now a bin) without complaining 3) I confirmed that the rev of my code still runs and works just fine in the KEIL debugger (uploads to the board and runs without any issues). 4) When I flash the equivalent (allegedly) BIN file to the board with the STM32 Link program, no error messages pop up. I had it start at address 0x08000000 because that was the default selection. My original goal, of the program auto running if you disconnect power and reconnect it, is not satisfied. Any other ideas? Perhaps one of the option bytes WDG_SW, nRST_STOP, nRST_STDBY has to be checked/unchecked? Thanks in advance for your replies. Perhaps I need to rig up a std out and see if the thing will ''hello world'' to me at the top of this program. That way I can see if it is running at all or just randomly just toggling LEDs (the program as written should light up LED3 when you tilt the board right and LED4 when you tilt it left -- that's what it does in the KEIL debug mode). -g

[generic]

Posted on February 26, 2011 at 18:48

So I had an epiphany. Even without a proper stdout for me to ''printf'' to, I decided to add a line into my ''completed'' program that would flash BOTH LED3 and LED4 if the user button was depressed. This is a state that the tile sensor (by its design) or the program would never generate by itself.

Well, apparently, both the STM32-LINK and the KEIL tool appear to be flashing the board correctly AND the program starts up when you turn it on. Even after pulling the USB plug and re-inserting it, depressing the USER button causes both LED3 and LED4 to come on now. This means that somewhere between when the board losing power and getting reset, something happens so that the STM32 is not picking up the correct information from the tilt sensor (hooked up to PA2 and PA3 as seen above). I've now narrowed down my problem to being SOFTWARE. If the problem was hardware, the only possible issue I could come up with was perhaps the STM32 disco board was NOT delivering 3.3V to the tilt sensor. A quick test with the multimeter proves that the tilt sensor IS getting 3.3V from the USB port. Since the problem is SOFTWARE, it must lie somewhere in the initialization of the input ports (maybe it's trying to initialize the ports tool early?). I'm only guessing here. What i do know:  * that the code is obviously running (program counter is moving) because i know it's going through the while loop in my main() function. When I depress the USER button, both lights come on (one of the if statements I just added). If I let go of the USER button, the program counter makes it to the end of the while loop where it turns off the LEDs. * The output initialization seems to work. Otherwise, the LEDs wouldn't turn on when I call the STM32vldiscovery_LEDOn(LEDn) function. If someone who knows the quirks of this board can take a gander at my code, I'd

really

appreciate it. I believe i'm quite close to getting all the quirks out of rev 1 of this project (a variable wing spoiler controller). If I get this working, I'll probably get cheeky and try and integrate an accelerometer instead. However, I acknowledge I need to walk before I can run... Regards, -g PS. Keep in mind that this program works perfectly as expected in the KEIL debugger -- I just can't get it to run standalone.

[generic]

Posted on February 26, 2011 at 23:13

Ahh, I figured out the solution to my problem once I nailed down the root cause.

In this section of code, I mistakenly declared the inputs from the Tilt sensor as Mode_IPD vs. Mode_IPU. It doesn't make 100% sense to me b/c the output of the tilt sensor should be a ''1'' or 3.3V when it goes in one direction but the net result is that the code work as needed AND most importantly, it works with just USB power. For some reason, the pins won't be read correctly in standalone vs. attached-to-the-debugger mode if I set them up as pull up (Mode_IPU) inputs. I wonder if this is a ''bug'' or just a feature I don't properly understand. Regards, -g   /* Init Tilt Sensor Inputs */   RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE);   GPIO_InitStructureInput.GPIO_Pin = INPUT_PIN1 | INPUT_PIN2;   GPIO_InitStructureInput.GPIO_Mode = GPIO_Mode_IPD; // Works in both debug and standalone mode now with Mode_IPD   GPIO_Init(GPIOB, &GPIO_InitStructureInput); // Send structure

[Tesla DeLorean]

Posted on February 27, 2011 at 00:32

Q: This may be a stupid questions but am I targeting the right device in the compiler? I have things set to STM32F103RB (I believe the closest name to the part number I found on the STM32 value line discovery board datasheet)

Keil 4.12 should have the STM32F100VB part. This is used by the VL Discovery Projects. To get the printf() working, you need to add in some ''semi hosting'' code to talk to the serial port. #include <stdio.h> #include <rt_misc.h> #pragma import(__use_no_semihosting_swi) extern int ser_putchar (int c); extern int ser_getchar (void); struct __FILE { int handle; /* Add whatever you need here */ }; FILE __stdout; FILE __stdin; int fputc (int ch, FILE *f) { return (ser_putchar(ch)); } int fgetc (FILE *f)         { return (ser_getchar()); } int ferror(FILE *f) {   /* Your implementation of ferror */   return EOF; } void _ttywrch(int ch)       { ser_putchar(ch); } void _sys_exit(int return_code) { label:  goto label;  /* endless loop */ }