cancel
Showing results for 
Search instead for 
Did you mean: 

Program doesn't run after Forced Bulk erase

davidmodulartech
Associate III
Posted on July 06, 2016 at 23:19

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?

9 REPLIES 9
Posted on July 07, 2016 at 01:02

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
AvaTar
Lead
Posted on July 07, 2016 at 07:45

More exactly, the Olimex website states (sic):

That suggests the board has a Arduino like (or compatible, or clone) bootloader/program loader. There is even a link to the bootloader binaries.

You can try your IDE7Debugger to flash this bootloader back to the board.

davidmodulartech
Associate III
Posted on July 07, 2016 at 13:42

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).... ??

AvaTar
Lead
Posted on July 07, 2016 at 14:36

> 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.

Posted on July 07, 2016 at 15:55

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
davidmodulartech
Associate III
Posted on July 07, 2016 at 20:28

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??

Posted on July 07, 2016 at 20:51

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
davidmodulartech
Associate III
Posted on July 07, 2016 at 21:29

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 *.elf

 

davidmodulartech
Associate III
Posted on July 07, 2016 at 23:02

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.