Hi,
being new to ARM I succesfully builded and downloaded the Blinky project into the STM32F103ZE uC on the MCBSTM32E board. It did run, but somehow it does not anymore. The IDE says "Application running" but it does not. Pressing the Reset switch has no effect. Disconnecting/reconnecting the USB ULINK-ME interface makes the application run again.
Where do I go wrong?
Thanks
Henk
I will reply myself.
This problem is solved if I use a different USB port. I think somehow this previous USB port driver overrules the manual Reset signal. If somebody could explain me how to solve this USB bug I would be glad.
Thanks,
Another reply to myself...
Also the new USB-port shows the same error behaviour.
If the example program Blinky is running then pressing the RESET key will stop de Blinky program but it will not RESTART the Blinky program.
I think it somehow happens after downloading some simple (malfuncting) application and then downloading the Blinky program.
Any idea's?
Regards,
Do your board supports separate powering? Your PC isn't required to supply any 500mA on the USB connector unless the board have negotiated for that current consumption. This is why mobile phones have special charger chips that can take over the USB signals and perform negotiation even when the battery is so low that it isn't possible to boot the processor.
Some PC have intelligent chips supplying the USB power. Some PC just feed 5V directly to the USB connectors - possibly with a Picofuse or similard to handle a shorted connector.
Sorry to sidetrack, but can you name any such chips?
One of the fundamental problems with all the "battery charger from USB" chips that I've seen is that they don't do any negotiation - they just assume that 500mA (at least!) will be available...
The only chips I have been able to locate myself have been chips with programmable charge current, so they may start at 100mA and later step up to 500mA - all the time measuring the current draw and either have the battery supply the remaining current or getting charged. But this still means that the processor may never boot in case the battery is empty and boot peak current of the processor is higher than the current limiter setting - a problem a lot of phones are suffering from.
I might possibly be thinking about some advance documentation I have received. I regularly get info about chips that hasn't been released yet, since there is quite long lead times from design start until actual production.
One-step-down on the scale - chips that doesn't negotiate but does control the current are chips like:
TI BQ24150A focus.ti.com/.../bq24150a.html and sibblings or LTC3455 etc. But they draw 100 or 500mA without caring about D+/D- and requires external hardware.
The latest USB standards have also complicated everyting a bit more. Besides USB 3.0 that supprts more current, there are also USB charger ports, allowing more current than 500mA and recognized by having D+ and D- shorted with no reference to ground.
I downloaded some USB analyser telling me that my USB ports are 100mA types. I dont much about USB ports but probably that's a reason?
The development board is powered through the ULINK adapter. I also tested using the normal USB cable directly connected to the mainboard but then still the same behaviour occurred. (pressing the Reset key then program stops but does not restart)
Another thing is when I select "erase all" in stead of "erase sector" with the flash options then it seems to work fine. (For at least up to now).
Most non-hubbed connectors _allows_ 500mA+ of current draw without negotiation. But having a USB host that allows it isn't the same as having a USB device that follows the standard.
Without negotiation, a device are not allowed to try to draw these 500mA. An unpowered USB hub may have multiple devices connected, but all these devices have to share the 500mA the hub may have negotiated with the PC.
The unpowered hub may then - by negotiation - agree to supply 100mA each on two connectors and 200mA on one connector and maybe consume 100mA for internal use. Or you may connect external power to the hub in which case the same hub may suddenly allow negotiation for 500mA from many connectors´concurrently.
Small devices - MP3 players etc - normally don't have any problem with just receiving 100mA. They may consume 20mA and have ample extra power for charging the battery. For larger products, you get into troubles since 100mA may not be enough to boot the device. The traditinal way have either been to ignore the USB standard (trying to take 500mA without negotiation) or have the battery add the missing current until the device has booted and been able to negotiate for more current. There are lots of charger chips that can take 100mA from the USB connector and give n mA to the device and 100-n mA to the battery and where the battery either gets charged or discharged depending on if n is less than or more than 100mA.
Anyway, most smaller ARM chips can do very well with less than 100mA.