2016-07-06 02:19 PM
I have been programming an STM32f103, to get used to ARM (Olimexino board - don't laugh).
I was advancing pretty well, had the GPIO working, SysTick interrupting and a basic time-banding system working.Then for some reason I was presented with the page (on the bootloader demonstrator) asking me to bulk erase memory. Not sure how I got there, (Pressed buttons too fast?? Not sure).
So with no other option (resetting, unplugging etc. didn't help) I bulk erased. Reset the board and proceeded to download my program.
Downloaded fine. I even uploaded to make sure it was actually writing and the code seems fine. But....
The program doesn't work now...
I am developing on linux with arm-embedded toolchain.
As I said, everything worked great for several weeks. Dozens if not hundreds of reloads, so I know the bootloader and my startup code and program had run normally.Would the option bytes have gotten erased by the buld erase?Any ideas?
2016-07-06 04:02 PM
Their page mentions there is a bootloader (theirs not STs)
https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/
If your code is not built to reside at 0x08000000 then assume there is other code on the chip. Make sure you pull BOOT0 Low so it runs your code, and not that of the ROM based System Loader. Use a debugger, and step the code to understand what is and isn't executing. Try some older, simpler software.2016-07-06 10:45 PM
More exactly, the Olimex website states (sic):
Espruino IDE is an alternative to Maple IDE. It has a free version and supports natively OLIMEXINO-STM32. Please visit the wiki article on
https://www.olimex.com/wiki/How_to_use_OLIMEXINO-STM32_with_Espruino_IDE
You can also use Arudino IDE and stm32duino.
2016-07-07 04:42 AM
I've been loading programs with the STM bootloader without problems for about a month.
From what I understand, the Olimexino bootloader is a separate ROM based bootloader while the STM production booloader is ''indestructable''.The STM bootloader demonstrator is a bit limited in its options however....In any case I don't think its a booloader issue. Last night I did some debugging (using the onboard LED, still don't have the JTAG debugger up and running) and it seems that the code is ''partially'' running. Last night I tested an hour or so without event, but this morning I started more testing and got several screens inviting me to bulk erase.I have a feeling my latest program is stomping on something, Still have to find out what.}Maybe I'm receiving a strange interrupt that isn't being caught (they should all be stubbed) or... Need to try to understand why the ST demonstrator requires that I bulk erase. The only thing that I can think of is that it's trying to enable ''read enable'', (which isn't even required).... ??2016-07-07 05:36 AM
> From what I understand, the Olimexino bootloader is a separate ROM based bootloader...
No. It is just a Flash-based application, designed to communicate with certain software on the PC, to function as ''program loader''. It is the first application to startup after reset, and either wait for downloads from the PC, or starts already downloaded ''applications''. Arduino, mbed, and MikroE board use to come with those bootloaders. I have mbed and MikroE boards - erasing this ''bootloader'' was the very first thing I did. Subsequently, you need JTAG/SWD access, of course.> ...while the STM production booloader is ''indestructable''.
That is correct.
2016-07-07 06:55 AM
Olimex's loader definitely not in ROM
I have mbed and MikroE boards - erasing this ''bootloader'' was the very first thing I did.Subsequently, you need JTAG/SWD access, of course.The NetMF junk on the
https://www.google.com/search?q=GHI+FEZ
boards was the first thing I nuked, the BOOT0 pin is either on a button, or test point, so DFU is viable.2016-07-07 11:28 AM
I have quite a hard time getting in to the forum.... even when logged in...
Anyways. Yes of course in Flash...It seems the problem I'm having is related to my program. Something in the program causes the booloader to respond on a subsequent programing attempt, to ''force a bulk erase''.On pressing ''next'' from the first port configuration page, it requires me to ''remove protection'', which also requires a bulk erase.I do the bulk erase and the next time I can progress to the pages to burn an image. If I don't burn the image, I can reset and go into bootloader mode and alls fine. When I finally load an image, it runs, but if I try to load another program, it forces the bulk erase again.I've looked everywhere on internet, but there are no reports of this that I have found.What could be going on??2016-07-07 11:51 AM
Suggest you sign-in to forum rather than hit reply if your session has expired. The forum has been broken for months now..
Yeah I don't know what you are doing in your code, haven't seen it, if you are setting read-out protection or setting option bytes this might require it to mass-erase the device to get that cleaned out. Most people use JTAG/SWD pods to program and debug devices, far fewer use USART/USB methods.2016-07-07 12:29 PM
Yeah, guess I'll have to go that route. I've got the HW. Just have to get around to setting up the whole environment. I have the USB TINY combo for the 0,05'' 10 pin SWD.
As far as what might be happening, I'm not intentionally setting or clearing read protection, and that shouldn't happen ''casually''. So who knows. at least with the JTAG I can debug.I've been producing *.bin, a guess I'll have to change that to *.elf2016-07-07 02:02 PM
I reloaded the STM bootloader Demonstrator and guess what?
It doesn't read protect my chipe every time it programs it.So problem solved.... I hope.