Using STM32F4 Discovery board on 1.8 Volt? - Page 1
Forum section: electronics / general

author: mrflibble
author_rank: Super Contributor
timestamp: March 26, 2013, 12:53:22 pm
content: Does anyone happen to have any experience with using STM32F4 Discovery board on 1.8 Volt?I need to connect the stm32f4 to some 1.8 Volt logic, and if possible I'd like to do so without using level shifting. I went over the board schematics, and it looks to be possible by:- disconnecting USB- removing jumper JP1- connecting 1.8 Volt to VDD on P2The drawback there being that this way it's no longer possible to conveniently program/debug through the USB connection.... So I was wondering if someone already went the 1.8 Volt route with this board and had some clever solutions?

author: andyturk
author_rank: Frequent Contributor
timestamp: March 26, 2013, 06:01:03 pm
content: I've never tried it, but please report back if/when you get it working! I'm going to be using an STM32L at 1V8 and I'm wondering if the STLINK built into the disco boards will work at that voltage. Presumably, there's not too much difference between that circuitry and the one on the official STLINK-V2 product, which is apparently 1V8 capable.

author: mrflibble
author_rank: Super Contributor
timestamp: March 26, 2013, 08:44:58 pm
content: Heheh, darnit! You were one of the people I had some hopes of actually having an answer to this one.But I will do a followup on any findings.

author: VanitarNordic
author_rank: Frequent Contributor
timestamp: March 31, 2013, 07:41:12 am
content: You want to go to 1.8V because of your specific application?

author: mrflibble
author_rank: Super Contributor
timestamp: March 31, 2013, 08:33:24 am
content: Yes. I want to connect the stm32 to an AD9913, which uses 1.8 Volt logic.Before you mention logic level shifters .. I am doing that solution in parallel as a hedge bet. But it would prefer to use 1.8 Volt straight from the stm32.

author: VanitarNordic
author_rank: Frequent Contributor
timestamp: March 31, 2013, 09:53:35 am
content: Yes, you are right. if there is a possibility to connect directly why you use one intermediary circuit.When they put such possibility to work with 1.8V, definitely it should be a solution to at least to be programmable by JTAG. Do you have the schematic of the board?

author: mrflibble
author_rank: Super Contributor
timestamp: March 31, 2013, 10:47:59 am
content: Quote from: VanitarNordic on March 31, 2013, 09:53:35 amQuote from: mrflibble on March 26, 2013, 12:53:22 pmYes, I have the schematics.So it looks to be possible to program it etc, but with some limitations. The limitation being that without modifications (*) I cannot do any debugging over USB as I am currently doing.*) Well, either modifications ... OR doing something that I haven't thought of / overlooked. I hope I simply overlooked something, which is part of the reason for this thread. I hope someone already did this and found a nice solution.The issue with debug over USB is that the STM32F103 on the board that does the st-link stuff runs on 3.0 Volt (derived from USB 5 Volt). The STM32F407 inputs areprobablytolerant of 3.0 volt when its running on 1.8 Volt. The main thing is that the 1.8 Volt logic high just might not be high enough for the STM32F103 inputs. In fact, I recall I looked over the stm32 datasheet and noticed that this was the case. BUT I see I failed to make a clear note of that (shame on me!) so I'll recheck it for the STM32F103 and will make a clear note of it this time.Update:Just checked the STM32F103 datasheet, see attachment. With a VDD of 3.0 Volt the worst case VIH would be 1.71 Volt, so that just might work with an 1.80 Volt output on the STM32F407 side. Not too much margin though... So maybe run the STM32F407 on 1.9 or 2.0 Volt for a bit more margin during the programming/debugging phase, and then 1.8 Volt when everything is done. The AD9913 should be able to take 2.0 Volt on it's logic inputs, especially since I have some current limiting resistors in there anyways.

author: nctnico
author_rank: Super Contributor
timestamp: March 31, 2013, 02:16:30 pm
content: Using 2V and 1.8V usually is within specs. The minimum forward drop over the protection diodes is about 0.3V. Maybe you can hack the programming interface to run from the 'target' voltage.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 05, 2013, 11:25:12 pm
content: You could also try unsoldering the voltage regulators on the disco board and replacing them with 1.8V equivalents. I think they're LDS3985 at a fixed 3.0V on the board. Try putting in the 1.8V regulators and see what happens.FWIW, I just picked up an actual ST-LINK/V2 programmer dongle and noticed a 74...8T245 level translator inside. So at least for official products, they're not relying on whether the logic levels are "close enough" at 1.8V.

author: mrflibble
author_rank: Super Contributor
timestamp: April 06, 2013, 10:00:22 am
content: I already took a look at precisely that, but there's a snag. It's a 3.3 Volt regulator followed by a schottky (about 0.3 volt drop). That not being the snag. The snag being .... usb. That 3V net is also used for USB, and doesn't usb go *pffffffrrrrrt* below 2.5 Volt? So if I exchange regulators I would expect everything to workexceptfor USB. Unless I'm mistaken, which would be great ... because problem solved.But I think if I use 1.8 Volt there I just lost USB functionality, and the programming/debugging connection with it.And just to be extra sure I rechecked datasheet ... USB on the STM32F103 is full-speed, which AFAIK does have the 2.5 Volt minimum for the voltage differential on the 2 pins. In fact, the USB operating voltage is listed as 3.0 Volt minimum. So there goes that plan.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 06, 2013, 03:26:30 pm
content: Well, the ST-LINK dongle is about $20.BTW, I just started trying to bring up my 1.8V board. It's being fairly cranky when powered up. About half the time it goes into the hard fault handler right out of reset. The other times, it comes up normally. Resetting it in the debugger or via nRST always works.My other STM32 projects have worked cleanly at 3.3V, but those were F103 parts and this is an L151. Probably isn't a voltage issue, but I thought I'd throw it out there in case you have any insight.Oh, and another thing... I'm using openocd to talk to the ST-LINK and it reports the Vdd during programming. However, the numbers are always low:Code:Open On-Chip Debugger 0.7.0-dev-00159-g87668ae (2013-03-30-15:51)Licensed under GNU GPL v2For bug reports, readhttp://openocd.sourceforge.net/doc/doxygen/bugs.htmlsrst_only separate srst_nogate srst_open_drain connect_deassert_srstInfo : This adapter doesn't support configurable speedInfo : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748Info : Target voltage: 1.268549Error: target voltage may be too low for reliable debuggingInfo : stm32lx.cpu: hardware has 6 breakpoints, 4 watchpointstarget state: haltedtarget halted due to debug-request, current mode: ThreadxPSR: 0x01000000 pc: 0x08000170 msp: 0x20000400auto erase enabledInfo : flash size = 128kbytestarget state: haltedtarget halted due to breakpoint, current mode: ThreadxPSR: 0x61000000 pc: 0x20000012 msp: 0x20000400wrote 4096 bytes from file build/ch.elf in 0.422809s (9.461 KiB/s)target state: haltedtarget halted due to debug-request, current mode: ThreadxPSR: 0x01000000 pc: 0x1ff00c54 msp: 0x20000600Not enabling HSIshutdown command invokedSTLINK says the voltage is 1.27V, but my Fluke says it's 1.787V. Not sure what's going on there.

author: mrflibble
author_rank: Super Contributor
timestamp: April 06, 2013, 10:17:32 pm
content: Maybe the PLL is feeling a bit special today and feels 1.8 Volt is below it's standards?As for the ST-LINK dongle, yeah I might just get one of those if all else fails.Up until now I've used st-util, but since you mention it I thought I might as well give openocd I try. I can get it to see the stm32f4discovery, or the Stm32vldiscovery. So the following work and detect the correct mcu:openocd -f board/stm32vldiscovery.cfgopenocd -f board/stm32f4discovery.cfgBut when I try to use the stm32vl as a standalone programmer (remove CN3 jumpers) and connect SWCLK/SWDIO/GND to the stm32f4 CN3 + GND then it's no dice.As for that voltage ... I'd trust the Fluke measurement. Pretty good chances that whoever wrote that particular routine to calculate voltage based on a register readout didn't test it with a low voltage. It's either that or you really do have voltage problems.But as random guess I'd blame the routine in openocd.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 07, 2013, 12:03:24 am
content: Quote from: mrflibble on April 06, 2013, 10:17:32 pmTurns out some dope left BOOT0 floating. The dope was more careful with his F103 boards.Totall fixable though:QuoteYou're connecting VDD too, right? I just tried it here (using all 4 pins on the VL's SWD) and they seem to talk to each other just fine:I didn't bring the combo up in openocd because I think that would take a bit of messing around. The VL uses the older STLINK v1 protocol, where all the newer disco boards use v2. That means you'd need to create your own .cfg (for openocd) that pulls in the STLINK v1 interface plus the chip configuration for your F4. If you try to use the out-of-the-box F4 discovery .cfg, it'll try to use the v2 protocol with the VL disco board, and I'm pretty sure that won't work. st-util will probably be confused also.I did, however, fire up the winblows ST-LINK Utility from ST and it correctly sees the F4 target while using the VL disco as the connection.QuoteI'll put my trust in Fluke too. The board's LDO is putting out a solid 1.8V for sure. Anyway, now that I've got things working, the funky VDD numbers don't worry me so much.

author: mrflibble
author_rank: Super Contributor
timestamp: April 07, 2013, 01:13:46 am
content: Quote from: andyturk on April 07, 2013, 12:03:24 amDamn these dopes! What will they think of next.QuoteActually no I didn't connect VDD on purpose. Maybe that is part of the mistake... But when I checked the schematic on the STM32VL all that was there was a pulldown to GND.And thanks for that photo, that's really helpful!Because I do notice a couple of differences compared to how I had it hooked up.Question though, are you sure it's that the communication is going like this? PC ==> STM32VL ==[STLINK/V1]==> STM32F4board-SWD-connector ==> STM32F407.Because that's probably the intention. But don't the jumpers on CN3 on the STM32F4 Discovery cause a conflict with the incoming SWD signals? Plus if that usb connection for the stm32f4 disco provides an actual usb connection (as opposed to just 5 Volt) then how'd you make sure that you were talking to the stm32vl and not the stm32f4 directly by accident?As for the openocd .cfg ... yeah I noticed the stlink-v1 vs stlink-v2 difference. I made a new config file like so:openocd -f /tmp/whatever.cfg# /tmp/whatever.cfgsource [find interface/stlink-v1.cfg]source [find target/stm32f4x_stlink.cfg]# use hardware reset, connect under resetreset_config srst_only srst_nogateSo basically just the stm32f4discovery.cfg , only with stlink-v1 interface.In any event, thanks again for that pic! I'll try that tomorrow after I double check it on the datasheet, because I thought there would be a conflict the way you have it wired.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 07, 2013, 02:54:08 am
content: Quote from: mrflibble on April 07, 2013, 01:13:46 amI believe the VDD on the SWD connector is an *input* to the STLINK. I.e., it looks at the VDD on the target system and then decides what logic level to use. On the STLINK dongle, there's an 8-wide level translator which is no doubt set up from what is seen on the target's VDD. The disco boards don't have level converters, but they may still want to see a voltage other than zero (which your setup would present on that line). Since you're trying to sneak 1.8V in without being noticed, maybe you should connect the VL disco's SWD VDD to 3.3V so it thinks there's something on the other end.QuoteI'm kinda, sorta, almost sure. Since I have to run Winblows under virtualization (native OS X), I plugged both boards into the mac and told the virtualization layer (Parallels) to send the VL disco's USB connection over to windows. The F4 disco stayed on the mac side. When I ran STLINK under windows with the SWD cable between the two, STLINK saw the F407 and proceeded to read it's memory. Unplugging the SWD cable (but leaving all the USB cables intact) made STLINK complain that the target went away. If STLINK was somehow talking directly to the F4 board, it would still see it even without the SWD cable.QuoteI wondered about that too, but I think the SWD/JTAG stuff stays out of the way unless it's active. In that experiment, nothing was talking to the F4's STLINK side, so maybe it was just hi-Z the whole time.

author: mrflibble
author_rank: Super Contributor
timestamp: April 07, 2013, 01:18:31 pm
content: I hooked it up as per your picture, and that worked! Yay, progress!And then I hooked it up exactly as I hooked it up yesterday, and that also worked! What now? Exactly!I'm glad you posted that pic, because that way I had an example config that I was pretty sure should be working. And if not, I am doing something silly... Well, turns out that the silly bit yesterday was my focus on openocd (new for me in combination with stm32) and neglecting to double check everything with st-util (known to work).So what works?1 - Exactly as you posted. All four SWD pins from STM32VL.CN2 going to pin 1-4 on STM32F4.CN2. Both STM32F4.CN3 jumpers fitted.2 - As (1) but with VDD disconnected because who needs VDD, right? Certainly not with this ST-LINK/V1 thingy.3 - Hooked it up as I had it yesterday. Which is:STM32F4.CN3 jumpers offSTM32VL.CN2.1 = blissfully ignoredSTM32VL.CN2.2 = STM32F4.CN3.2STM32VL.CN2.3 = STM32F4.GND pin of your choosingSTM32VL.CN2.4 = STM32F4.CN3.4Now in retrospect I admit this last one may look a bit convoluted, but at least for that combo I was pretty sure I didn't have to rely on the STM32F103 somehow not interfering. And as it turns out, this convoluted connection does work. But from now on I think I'll go for the simpler option of just using the SWD connection on both boards and leave the CN3 jumpers fitted on the target.As for VDD ... as you say it looks to be an input to the STLINK. But I suspect that for ST-LINK/V1 it doesn't do much. And if you look at the stm32f4 discovery schematics then you'll see it actually DOES do something useful when the stm32f4 board is the programmer. As opposed to being the target as in the current scenario. VDD_TARGET goes through a schottky for about 0.3 Volt drop and then to the ADC input (AIN_1). So I guess they introduced that target voltage detection feature in ST-LINK/V2...And all the above worksonly if I use st-util. As of yet openocd is a nogo for the 2-board combo.I did get single board openocd debugging from eclipse to work though, but not after getting all sorts of curious errors regarding gdb-attach at first. It wouldn't be fun without curious errors after all.Oh and mind you, this entire excursion is still all at default voltages.I wanted to get things to work first. But at least now I have a working st-util based config for the 2-board setup. So all that is needed now is a 3.3 Volt <--> 1.8 Volt level translator for two signals between the STM32VL and the STM32F4. And as bonus I do have openocd working for the single boards, which is nice. I noticed openocd is quite a bit faster than st-util, so I think I'll use more openocd in the future.So on the TODO are:- logic level translator for SWCLK and SWDIO- trying to get openocd to work for the stm32f4 through a stlink-v1.I suspect that for the latter I need to dive into the tcl code, because I have some rough idea of what's going wrong. But obviously no clear idea on how to fix it, or I'd have done that already. Or maybe I should just google more.And thanks again for the help!...Update:Alright, after some more mucking about I noticed that it fails in "stlink_usb.c" withstlink_usb_xfer_rw(): bulk read failed. And thenthis one. I checked that patch against the source I have here, and it looks like it is indeed applied. But seems there just might be more issues with stlink-v1. More issues I am not interested in.Then I remembered hey waitaminute, I have a medium-faulty stm32f4 lying around, maybe the stlink on that is just good enough. And sure enough, that works. So that's all stlink-v2 between two boards. No need to fix strange stlink-v1 issues. So looks like I just need to put some level shifters in there and all set.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 07, 2013, 08:42:52 pm
content: Yeah, STLINK v1 isn't very useful any more. Apparently it was based on a SCSI-derived USB protocol that made Linux boxes think it was a disk drive. The v2 protocol does something more reasonable, and it's used by all the new disco boards. The only use I had for v1 was to talk to a VL disco board that I upgraded/hacked to use an F103 XL chip.Even if you have some level translators lying around on your bench, it's definitely worth the $20 to get the official dongle. It'll do the low voltage stuff you're playing with and it's physically easier to handle than a disco board with scratchy pins and sharp corners.I've discovered it's also handy to have a windows machine (if you don't already) that can run the ST-LINK OEM utility. That's about the only way to unbrick a board if some dope misconfigures the JTAG/SWD pins at startup. The "connect under reset" option gets you back into the chip.

author: mrflibble
author_rank: Super Contributor
timestamp: April 08, 2013, 05:48:23 pm
content: Heh, the scsi derived stuff would explain why I had to slap it every time it tried to register a usb-storage device. Unbinding the usb device did the trick, but it was annoying. And I will probably get the stlink dongle, it depends a bit on how big my next mouser/digikey run will be. I usually use dev kits and boards like this to pad my order to be above the minimum amount for free shipping and below the amount that triggers extra customs BS.And good to know that "connect under reset" unbrick method. Added to the list of possible solutions in case of stupid stuff.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 17, 2013, 08:22:17 pm
content: Pondering 1V8...The main reason I'm using 1V8 in my project is because it uses a Panasonic Bluetooth module with 1V8 I/O. If it wasn't for that, I could run the mcu and the display at ~3V (or whatever the coin cell is capable of putting out). The mcu has to talk to a display (4 I/O lines at 3V) and the bluetooth module (6 I/O lines at 1V8), so I dropped the mcu down to 1V8 and put a 4-line level translator between the 3V display and the mcu.So today I ran into this:Choosing an Appropriate Pull-up/Pull-down Resistor for Open Drain Outputs.Maybe there's a way to dispense with the level translator by running the STM32 at 3V with open drain outputs. Seems like pull-up resistors to 1V8 between the mcu and the bluetooth module just might accomplish the level translation without the need for an extra chip. I'll have to think about that some more ....This isn't directly related to your original question, but it's in the 1V8 ballpark.

author: mrflibble
author_rank: Super Contributor
timestamp: April 17, 2013, 09:56:43 pm
content: If everything on the stm32 side is an output going to a bluetooth module input, then this sounds reasonable. Provided you don't need super fast signals.If there's also some signal going from the bluetooth module to the stm32 then it might be trickier. As in the 1.8 Volt logic output of that module might not be enough to reliably reach the Vih threshold. See post #6 earlier in the thread. It just might work, but you don't have much margin. Or you could do a moderately evil weak pullup to 3V on the (push-pull?) output of the bluetooth module as well to give it that last push. Might not be pretty, but will work as long as it's not expected to go fast.Or just use proper level shifters.Incidentally, what chip were you using between the 1.8V and 3.0 V? I noticed it on your Sharp lcd thread, but couldn't make out the markings in that photo...

author: andyturk
author_rank: Frequent Contributor
timestamp: April 18, 2013, 12:14:12 am
content: Quote from: mrflibble on April 17, 2013, 09:56:43 pmThe bluetooth connection is 4 UART lines (RX/TX/RTS/CTS) plus a reset line and a 32kHz clock signal, so two of those would be 3V inputs. On the other hand, the display lines are all outputs. That suggests maybe the open drain/pullup combo might work better there with 5V-tolerant SPI lines. I.e., if the mcu is running at 1V8 and I hook it up to a 3V SPI display with pull ups, those mcu output pins are going to see voltage higher than VDD because of the pull ups. Normally that'd be bad, but if the pins are 5V tolerant to begin with ...?QuoteIt's aSN74AVCH4T245.

author: mrflibble
author_rank: Super Contributor
timestamp: April 18, 2013, 12:38:09 am
content: Quote from: andyturk on April 18, 2013, 12:14:12 amI did look into that, and as far as I understand the datasheet that's possible. Actually it's also possible for the boring non-FT pins, but for the FT pins you have even more margin.As long as it is either of 2 states ... pull to ground by the drain. Or pullup to 3 Volt through resistor. If you make the pullup resistor large enough you limit the current such that the clamping diodes have no problem, and the voltage at the pad should be well within limits.Also, you may find this interesting:http://www.st.com/st-web-ui/static/active/en/resource/technical/ecad_models_and_symbols/hw_model/stm32ibis.zipSpecifically the clamping diodes.QuoteThanks.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 18, 2013, 12:59:13 am
content: Quote from: mrflibble on April 18, 2013, 12:38:09 amWhat does one do with .ibs files?

author: mrflibble
author_rank: Super Contributor
timestamp: April 18, 2013, 01:18:06 am
content: Quote from: andyturk on April 18, 2013, 12:59:13 amRead them?A quick google around ... this looks to do a reasonable job of explaining things:http://www.actel.com/documents/Ibis_AN.pdfSee page 5 for power clamp I/V curve. That's the relevant data for this kind of problem.Also found another one that explains everything, but it's a bit long winded at 105 pages.

author: mrflibble
author_rank: Super Contributor
timestamp: April 18, 2013, 01:22:16 am
content: Also:http://www.mentor.com/products/pcb-system-design/circuit-simulation/hyperlynx-signal-integrity/visual_ibis_editor/Essentially the idea is to limit size the pullup resistor, such that the current flowing into the input pin is safe. You can check that by looking at the IV curve for the power clamp. Or when lazy, just do something like 4K7. Problem solved .

author: sdim
author_rank: Contributor
timestamp: February 22, 2014, 08:39:15 am
content: Open the stm32f4 datasheet and search for table 15"Table 15. Limitations depending on the operating power supply range"The MCU can work with 1.8V power supply with some limitations :ADC: 1.2MspsfFlashMax = 20MHzmax flash frequency = 160Mhz / 7 wait statesI/O: decreased performance, no I/O compensationclock output on I/O pins frequency: <30MHzflash memory operations: 8bit onlyI guess that if you replace the 3.3V regulators on the discovery board with 1.8V regulators you will have a 1.8V discovery board with some performance limitations.