Download and Erase don't work in Keil

[taraskorzh]

Posted on September 26, 2010 at 20:13

In Keil, if I go to Flash->Download, it says ''loaded ... DISCOVER.axf'', the red COM LED blinks couple of times, and then stays red. The whole thing seems to be hanging. When I power-cycle the device, the old firmware still runs.

Same thing about Flash->Erase. The COM LED turns on, and nothing happens. Then, after power-cycle, the old firmware is still there and works. But if I go to Debug->Start/Stop Debug Session, and then press F5, the new firmware gets uploaded fine and works OK under debugging. How do I fix it so that the Download and Erase work too? #bug

[qili]

Posted on September 29, 2010 at 00:08

I have always used the ''debug'' mode to download. and that kind of behavior isn't unique to Keil: IAR does that with all of its IDEs (that I have used, for STM8, AVR to STM32).

[qili]

Posted on September 29, 2010 at 00:20

''

I wouldn't agree that the ARM needs to be that more complex than an AVR.''

I don't think ARM needs to be more complex. it is just that it IS more complex. ''Turning LEDs on and off in ARM is only slightly more complicated than in AVR if you hit the metal directly (you've got to turn the clock on). '' it will depend on your perspective on that. I think it is proper that the code that initializes the mcu consistently, has the right handlers for all the interrupts, and error handling (clock fall back at a minimum). from that point of view, my ''minimum'' project configuration for those chips will necessarily involve CMSIS, and x_it.c / x_it.h and x_conf.h files. but I do agree with you that if all you ever wanted is to turn on / off the led, you can simply boot up the chip, clock the port (and potentially set the pin in the right mode) and you are ready to go. ''Surely these boards are aimed at the hobbyist ?'' I don't think those boards make much sense for the OEMs. One of the biggest cost items for software developers is the maintenance of a code base over multiple platforms. the primary appeal of those CMx chips is that they offer a price point to the end user where an up-market developer (whose focus is on truly 32-bit systems) can go down market easily and cost-competitively with those CMx chips by adapting his existing code-base with minimum changes. adapting a 8-bit code base to those CMx chips will almost surely mean heavy investment so I think it is unlikely the OEMs will have much new business by marketing those chips to 8-bit developers. and the hobbyist market is simply too small to justify the investment. ''Any professional development company is not going to be bothered about the difference between $10 and $250 for a development board ?'' for me, I am not going to think much unless the dev boards are over $25K. ''It's for tinkerers like me, and people who want to learn - or possibly for colleges.'' the tinker market is simply too small. but the college angle is a valid one. ''If these are aimed at pros, then why not charge them at cost ?'' agree. those cheap boards don't make much sense to me.

[Tesla DeLorean]

Posted on September 29, 2010 at 02:02

Well I'm pretty sure ST doesn't have the technical staff available to support droves of hobbyists (capable coder/constructor), and amateurs (can't code in C/ASM, let alone embedded) , so unless you have a 10K volume project your access to FAE's is going to be fairly minimal.

Personally I can see these board being used to mash-up a few dozen proof of concepts. Or plugging into a cheap to fabricate 2 layer PCB. At $10 they are pretty much throw-away, getting them by the dozen or gross is easy justify. The ST library can be used to quickly get code up and running, sure you can still code at a register level if you insist on using it like an 8051 and be significantly less productive, and less portable between devices within the family.

[infoinfo968]

Posted on October 02, 2010 at 05:28

Perhaps it's 'Keeping up with the Jones'' ? There's several other similar products about that must be produced fairly close to cost at best - the Microchip Microstick (the 16 bit MCUs) and the TI Launchpad spring to mind.

The latter is seemingly very popular, despite being almost comically underpowered compared to the ST8 let alone the ST32 bit range - just 2k of Flash and 128 bytes of RAM and a couple of timers in a 16 pin DIL package but it's cheap - $4.30. This even includes free shipping to the UK where I live - bizarrely - and it includes the USB cable and pins to solder into the board so you can easily prototype with it.

[Tesla DeLorean]

Posted on October 03, 2010 at 14:38

I'm seeing some other issues with the ST-LINK and Keil.

If you try to view memory, or save the content to a file (save file.hex start,end), the data comes back for the first 0x50 bytes, then a bunch of zeros (0xC0), then another 0x40/0xC0 bytes of data/zeros through memory. If you try save too much memory (ie more than 128K of flash 0-0x20000) , the ST-LINK throws up a pop up message with an error, followed by another. Then instead of failing and stopping, it keeps going in 16-byte increments with the same pair of pop-up messages over-and-over. There is only an OK button on the pop-up, so you can't cancel it, and you end up having to kill the application.  Try ''SAVE  MEM.HEX 0x00000,0x7FFFF'' in the debug dialog window.

[allenc28]

Posted on October 04, 2010 at 10:12

I am seeing the same problem with the STM32VL discovery board and MDK-ARM 4.12 on Windows XP 32 bit.  To reiterate:

• Flash->Download and Flash->Erase functions both hang with the red COM LED lit.

• Power cycle and the board will have the same image; flash is not changed.

• Flashing from Debug works.

ST has published UM0986 which precisely documents the use of Flash->Download with this hardware so this is not a license issue. As for the thread hijacking regarding ST et. al. rational for low cost evaluation boards; please take it to another thread.  This thread is about a specific technical issue observed by multiple users. Thanks.

[qratman]

Posted on October 28, 2010 at 18:05

I have got excactly the same poblem with Windows 7 and Keil uVision 4.10 (wanted to install uVision 4.12 but after uninstalling 4.10 and installing 4.12, I still got 4.10).

According to the PDF file linked by someone above which talks about ARM-MDK and the eval kit, this is indeed not a license issue but a bug. Where can we report about it? Does anyone know a workaround meanwhile? It is *very* time consuming to enter the debug mode (and tolerate the nag window) and hit run after every flashing.

[Tesla DeLorean]

Posted on October 28, 2010 at 22:11

Where can we report about it?

Keil Sales/Support?Does anyone know a workaround meanwhile? It is *very* time consuming to enter the debug mode (and tolerate the nag window) and hit run after every flashing. Buy a license so it doesn't waste your time nagging? Write more code between flashing/debug sessions. Walk through your code so there is a better chance of it working the first time around. Add more diagnostic code so you can test more than one thing at a time. Least you don't have to wait 15-30 minutes for the UV to erase the EPROM.

[mhunsberger1]

Posted on November 25, 2010 at 01:27

Yes The launchpad is quite comical, but I just ordered 3 from the ti e-store.  I was just looking around at the ST value solution, the Stm32vlDiscovery, and I think I will steer clear of it.  I am a college student in the DeVry University Electronics Engineering and Technology bs program, and this is a product that seems fantastic, but very poorly supported.  Usually, I look to see what St offers when designing, but I must admit, I never have looked at their microcontrollers.  I also skip the arduino because it is limited to basic hobbyist projects, just like the picaxe.  I bought the launchpad, which also has extremely low functionality, because it was cheap, it seems well supported, and I already have a c2000 evaluation board with a xds510pp jtag emulator.  I have also had great success with Microchip PIC microcontrollers, but even though I do not have an evalution borad from them I think their free limited software is the nicest available, at least there are no code restrictions for their C compiler.  I have incorporated Microchip PIC's into a couple of projects, and right now I am designing a closed loop servo control using a PIC18F2431.  Microchip and Ti  also seem to have really nice training for their products, with LOTS of application notes.