STM32L Discovery USB

[codium]

Posted on September 06, 2013 at 20:32

Hi,

first of all, I'm writing a new thread because I couldnt reply to [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32LDiscovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32LDiscovery/STM32L%20Discovery%20and%20STM32F10x%20and%20STM32L1xx%20USB-FS-Device%20Library&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000BA7000AD27065745A5C15A65B5BEF01F&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32LDiscovery/AllItems.aspx&currentviews=1333]this  debate (why do I get ''You are not authorised to view this page.'' error if I click ''Reply''??). Anyway, i'm trying to get STM32L on DIscovery board to communicate via USB to a PC. I have been doing this for a long time and it seems a lot of developers are having a hard time. So, to start, i tried to realize the above project from m.e (VirtualCOM), PC detected the unknown device, but nothing further. So i followed m.e's hardware steps soldering SB17. The device is still only detected and it does nothing (drivers do not install), but the big issue is that now no compiler can connect to the device, so i cant even debug or anything. I tried to connect with ST Link utility, but i always get ''Internal command error'' to whatever action. However,  I can upgrade the device firmware with this app. So, what did i do wrong and how can i ''repair'' things? And, BTW, what is the purpose of the MCO pin? Thank you #mco #smtl32l-discovery

[Tesla DeLorean]

Posted on September 06, 2013 at 21:20

In the past their were more sub-forums, the STM32L-Discovery one was merged into a general STM32 Discovery one and the old posts on the old forum were locked.

If you put code on the device that precludes SWD debugger access (ie reprogrammed the GPIO pins, disable SWD/JTAG, sit in a WFI loop, etc), you can connect BOOT0 to VDD and reset, this will bring the device up in the System Loader rather than with broken user code. MCO (PA8), this is a pin on the STM32F103 implementing the ST-LINK function and permits the routing of the HSE (8 MHz) crystal clock from that part into the HSE clock input of the STM32L152. This is done because a) an accurate crystal clock is required for USB operation, and b) it saves populating a second 8 MHz crystal/caps at X3,C21,C22,R30 and the costs to do that.

[codium]

Posted on September 07, 2013 at 17:12

Thanks, but this doesn't help either...(I'm supposed just to SC the two pins while USB cable is plugged in, right?) ST Link Utility is just reacting the same as before. Are you sure this doesn't have anything to do with soldering SB17? I think this occured after I did that.

[Tesla DeLorean]

Posted on September 07, 2013 at 19:45

I don't think bridging SB17 makes any difference to whether you can program the L152 or not.

If you want to use USB on the L152 then you need a stable and accurate clock, you can either get this from the F103's MCO pin via SB17, or you can mount a crystal and support components to the L152. I use micro grippers to short the two pins. You could play games with SB3 if you wanted. You want to reset the board after BOOT0 is high.

[codium]

Posted on September 08, 2013 at 23:48

Thanks, this reset thing solved it. However, it turns out it wasn't the above VCP example (which, btw, doesn't work here, it sets D+ line of L152 low so it's not even registered by the PC) project that spoiled the things for debugger. The problem is the Custom_HID example, which I ported from EVAL to DISC board. This software makes the device ''seen'' by the PC, but still no drivers install (Unknown device attached). I didn't really change much when porting, I just deleted buttons, LEDs and ADC code... Do I miss something here?

[codium]

Posted on September 09, 2013 at 12:08

Correction concerning the VCP example: it does work, I just messed up with external pull-up and forgot to turn it off in SW :)