http://forums.leaflabs.com/topic.php?id=861 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:04:53 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=861&page=3#post-21863 Sat, 05 Jan 2013 13:14:26 +0000 dipspb 21863@http://forums.leaflabs.com/ <p>Pull req sent to <a href="https://github.com/leaflabs/libmaple/pull/60" rel="nofollow">https://github.com/leaflabs/libmaple/pull/60</a><br /> Fix for unresolved _exit reference with Summon/Linaro GCC ARM toolchain.</p> <p>regards,<br /> Dmitry </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-10082 Wed, 04 Apr 2012 16:29:38 +0000 iainism 10082@http://forums.leaflabs.com/ <p>+1 to CAN support.</p> <p>I have access to Vector CANoe through my work (along with other neat toys, such as a Tektronix MSO 5054 with the AUTO and COMP modules installed) if testing is required, and I will shortly have an Olimexino-STM32 (ordered today). </p> <p>I should also mention that with regard to the above offer of testing assistance, my coding experience is usually a few levels higher up the OSI stack than working on hardware drivers, and recently my experience has mostly been in MATLAB. I'm happy to do things, but I may ask a few 'stupid' questions along the way!</p> <blockquote><p>I do not know how each operating system (Windows XP, Vista, 7, Linux, Mac OS X) would treat a 'file' on the USB-mass-storage-device which keeps returning data. Is its length as big as it can be (e.g. 4GB), or does it constantly change?</p></blockquote> <p>My thought on reading the above is that this isn't so different to how various files in /var/log behave in a *nix system; so for output from the device, as long as the 'file' is always correctly closed after an update something similar to tail should keep track - shouldn't it? </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-10070 Mon, 02 Apr 2012 18:23:26 +0000 ala42 10070@http://forums.leaflabs.com/ <p>The Makefile in the support/ld/libcs3_stm32_src directory is buggy. The high-density devices get the same vector table as the medium-density devices as a define for the assembler based vector table is missing. Currently these vectors are not defined for high-density devices:<br /> .long __irq_tim8_brk<br /> .long __irq_tim8_up<br /> .long __irq_tim8_trg_com<br /> .long __irq_tim8_cc<br /> .long __irq_adc3<br /> .long __irq_fsmc<br /> .long __irq_sdio<br /> .long __irq_tim5<br /> .long __irq_spi3<br /> .long __irq_uart4<br /> .long __irq_uart5<br /> .long __irq_tim6<br /> .long __irq_tim7<br /> .long __irq_dma2_channel1<br /> .long __irq_dma2_channel2<br /> .long __irq_dma2_channel3<br /> .long __irq_dma2_channel4_5</p> <p>To fix the bug in support/ld/libcs3_stm32_src/Makefile add<br /> high-density: ASFLAGS := -DSTM32_HIGH_DENSITY<br /> below<br /> high-density: CFLAGS := -DSTM32_HIGH_DENSITY</p> <p>Rebuild and check that the resulting libcs3_stm32_high_density.a file is larger than libcs3_stm32_med_density.a. Currently the size is identical. </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-7736 Tue, 17 Jan 2012 16:55:04 +0000 poslathian 7736@http://forums.leaflabs.com/ <p>I do like the mass storage device, and it would solve the driver signing issue. However, the bigger problem is that the USB interface is being provided by the same device you are reprogramming, so when you reprogram you tear down the USB interface with it. </p> <p>We experimented early on with having a dual USB configuration, DFU and Serial at the same time. It could just as easily have been Mass Storage and Serial at the same time. The problem was that Mac and Windows handled compound USB configurations in a mutually exclusive way, requiring us to write a custom windows driver to get that to work. We obviously did not go that direction. </p> <p>The plan for future products is to bite the bullet and drop in a second MCU to provide an always on serial interface which is used for both communication and for bootloading. Similar to what arduino UNO does. However, we strongly encourage people to keep playing with the bootloader scheme on the current products. We would love to see a mass storage setup working and would definitely be interested in seeing the community start to fool around with the USB configuration in general. All sorts of fun possibilities there. </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-7701 Mon, 16 Jan 2012 21:31:22 +0000 gbulmer 7701@http://forums.leaflabs.com/ <p>I do not need such a complex bootloader.<br /> I'll need to take about two bootloaders, let's call the thing you are describing the 'add-on' bootloader, and the one manufactures into the chip, the STM32 bootloader.<br /> I would be satisfied with a reliable way to upload an ordinary program, and then fallback to the STM32's bootloader for loading/changing the add-on bootloader.</p> <p>I have requirements which you have not mentioned.<br /> I need an easy to use API (on the board) to be able to print messages or send binary data streams from the board, and exchange binary data streams with it, while it is running my programs.</p> <p>One of the areas of the current bootloader which has often caused problems is that it dynamically changes the type of USB device that it enumerates to the host PC. Windows, at least, gets upset. So it seems desirable to remain the same type of USB device. Hence an interest in widely used serial devices like CDC. Also, I believe some boards work over USB CDC already, for example SUN's sunspot, so there is some evidence that it can be done.</p> <p>Anyway, because of my other needs, I am interested in how a USB-mass-storage-device would satisfy my requirements to exchange binary data streams with the board while my program is running. To avoid repeating the problems caused be dynamically changing the type of USB device, I will assume it will always look like a USB-mass-storage-device.</p> <p>I can imagine a scheme where some other file name on the USB-mass-storage-device represents the output stream from the board, and another an input stream to the board. But I don't have much confidence that it would work.</p> <p>I do not know how each operating system (Windows XP, Vista, 7, Linux, Mac OS X) would treat a 'file' on the USB-mass-storage-device which keeps returning data. Is its length as big as it can be (e.g. 4GB), or does it constantly change?<br /> What would it do to a file which allows the OS to keep writing data, maybe even beyond the size of the device?<br /> I also don't know what would happen if the USB-mass-storage-device blocks and doesn't return any data for a long period of time.<br /> I also don't know if all of the platforms would support exchanging bytes with the USB-mass-storage-device to support the sort of simple, byte orientated data exchange protocols that beginners use. </p> <p>I do believe that OS's treat a USB-mass-storage-device as a block device, expecting to read or write entire blocks, so that might need to be investigated.<br /> I could imagine some of those OS's rely on timeouts to ensure things work, so that would need to be checked out too.</p> <p>Have you thought how this might work?</p> <p>Edit: Is the idea to dynamically change between two different USB devices, one being the USB-mass-storage-device, and the other a USB device which satisfies my other requirements for binary data streams? My impression is OS's might be even more sensitive to a block device like a USB-mass-storage-device disconnecting. I get messages from my Mac, and from Windows if I pull a USB-mass-storage-device out without 'closing it'.</p> <p>(Full disclosure: I am not a member of LeafLabs staff) </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-7691 Mon, 16 Jan 2012 17:30:52 +0000 LarryP 7691@http://forums.leaflabs.com/ <p>Greetings all,</p> <p>I'd like to toss out yet another blue-skyish idea for making the leafLab's bootloader work more reliably, need fewer (ideally no) custom drivers, and be more nearly unbrickable. This may be somewhat of a ramble, setting up the context; so please either ignore me or bear with me. </p> <p>Some assertions, please take 'em with a grain of salt: </p> <p>A.1: Although the OpenMoko software used in leafLab's bootloader is open and reasonably clean, it doesn't appear (to me, at least) to be well (read consistently) implemented across Windows (esp. Win7 and future), iOS, and Linux (to say nothing of upcoming Android) host operating systems. Driver and signing issues (for the different O/Ss that leafLabs would like to support)continue to be a hassle for users and a distraction for leafLabs' developers</p> <p>A.2 The situation described in A.1 isn't likely to change soon, and leafLabs and their customers have little prospect of fomenting significant amounts of such change. Thus, the leafLabs' bootloader needs to change, because the rest of the ecosystem won't do so any time soon.</p> <p>A.3 Complete backward compatibility would be nice, but IMHO may have to be sacrificed in order to truly put a stake through the heart of the driver issue. However, keeping as much backward compatibility as possible is desirable, and it may be possible to make the host-side software auto-detect the bootloader version on the target, and then react correctly and automatically.</p> <p>OK, some digression about the bootloader, the USB spec and what the bootloader needs to do. </p> <p>At core, the bootloader needs to: </p> <p>* Check the image in flash for integrity. (Optionally check the bootloader itself for integrity, but happens if it fails is less clear.)</p> <p>* If the onboard flash image is OK and there's no indication from the host that a new image is ready for download, jump to the image already in flash.</p> <p>*If the host indicates there's a download image available from the host (or the user has forced perpetual bootloader mode), wait patiently for the host to send an image to load into memory. Accept the input, verify it (checksum); write it into either flash or RAM, and jump to the corresponding entry point.</p> <p>----</p> <p>In the USB spec (at least Rev 2.0 and up), there are a number of pre-defined generic/class drivers. The inclusion of these class drivers together with the mandate (if I recall correctly) that <em>class drivers must be included for USB certification </em> suggests that making use of USB class drivers, in lieu of a custom driver on the host side (that must be distributed, signed {or hacked around}, installed, documented and maintained, would be a good thing. It sounds like the scheme leafLabs is working on may make use of the CDC class driver. However, we may be able to do better by making use of another class driver, as well; please see below.</p> <p>Side note: The presence of (the HID) class driver is one key reason why many getting-started-with USB projects use the HID class driver, that comes with virtually every O/S I've seen with USB host support. </p> <p>Interestingly -- and IMHO relevant to the bootloader issue -- another defined-in-the-USB-spec class is <em>the Mass Storage class,</em> and I believe all the O/Ss of interest support this fully, correctly and without needing any mucking with custom drivers. More importantly, all those host O/Ss need to do this -- <em>and will need to continue to do this</em> -- in order to read from/write to the many, many different USB thumb drives, MP3-players, and digital cameras people want to use with their PCs. For instance, my camera presents to my PC as a flash-drive (that somehow fills itself up with directories of .jpg files) -- without ever asking me about drivers, signing, or any such hassle.</p> <p>So here is a rough outline of my bootloader-variation proposal: </p> <p>Either replace the perpetual bootloader mode (on the target side) with code that makes the Maple device present its flash memory (except for the bootloader itself {??})temporarily as a USB mass storage device, or (better for backward compatibility) add some new means (button press at the right time, once in perpetual bootloader mode?) to transition the on-maple bootloader into "Mass Storage" mode. On the host side, either the Maple GUI or the O/S itself can now see the Maple's flash memory as a newly-installed small flash drive. Thus, the Maple's flash memory can be backed up and/or re-written by copying a suitable image file (with the right size and checksum) to/from the "Maple flash drive." </p> <p>One of the other Cortex M3 suppliers (NXP, in their one of their LPC13xx versions), implements this functionality in an extra chunk of non-erasable, on-chip memory. I haven't seen info on any STMicro Arm/Cortex variant that has such a USB-mass-storage-firmware-in-ROM, as does the one NXP model, so complete un-brickability is probably not possible without some external hardware. However, if this revised bootloader, when placed into Mass-storage mode, were designed to accept only two file names, e.g. userImage.whatever and bootLoader.whatever (and the latter only with sufficient extra steps to try to ensure atomic update, absent a power failure during the update.) Then we'd have a general-purpose way to both get new images into a maple's Flash memory or copy an existing flash image back out of a maple (e.g. to help debug the really hard bugs) in the vast majority of cases. Doing so would also provides a means (albeit slightly risky) of updating the bootloader itself in the field. </p> <p>From what I can tell, completely restoring a firmware-bricked but otherwise unharmed STM32xxx requires connecting up one of the serial ports (namely access to the right Maple pins) to something that can send it a flash-image update compatible with STM's built-in bootloader protocol/format and baud rate. One PC-based tool for this is the "STM32 ST-LINK Utility." For most PCs, that now lack a serial port, doing this requires a USB-to-serial (at the correct signal levels) converter. FTDI.com makes these, and there are a number of clones or work-alikes available, including (if I recall correctly) Arduino sketches that server as USB-to-serial converters. FYI, I've had good luck with the "USB BUB1" from <a href="http://shop.moderndevice.com/products/usb-bub" rel="nofollow">http://shop.moderndevice.com/products/usb-bub</a> and consider it a good investment for when things go seriously weird. </p> <p>FTI, here's a table of the various class drivers in the USB spec: <a href="http://en.wikipedia.org/wiki/Universal_serial_bus#Device_classes" rel="nofollow">http://en.wikipedia.org/wiki/Universal_serial_bus#Device_classes</a></p> <p>For those of you who've read this far, thanks for your time and attention! I welcome your comments and criticisms, but please keep it professional and as cordial as possible. </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-7652 Sun, 15 Jan 2012 03:23:53 +0000 bubulindo 7652@http://forums.leaflabs.com/ <p>Or the 32kHz crystal for the onboard real time clock. :) </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-7651 Sun, 15 Jan 2012 03:07:12 +0000 kiwidude 7651@http://forums.leaflabs.com/ <p>It would be really cool to be able to port working sketches from AVR Arduino to leafmaple. Unfortunately nothing much compiles. The PROGMEM things I can take care of, but the basic libraries like SPI, Wire and Ethernet are non-negotiable. ;-) They have to work 100% the same. Improve - yes, change - no.</p> <p>Given that the capabilities of an STM ARM are so much bigger than those of a 328P AVR why don't you just slam a 50 cent EEPROM on the boards? (Chipkit made that mistake too.) </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-6233 Thu, 08 Sep 2011 20:40:15 +0000 gbulmer 6233@http://forums.leaflabs.com/ <p>mbolivar</p> <blockquote><p>We definitely agree that this is an important feature. It's easily implementable in my proposed scheme. I'll make sure to add it in such a way that it's easy to override from user code (i.e., without modifying the libmaple source). </p></blockquote> <p>Thank you. </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-6217 Wed, 07 Sep 2011 17:16:33 +0000 mbolivar 6217@http://forums.leaflabs.com/ <p>gbulmer,</p> <blockquote><p> I'd still prefer a way to for my code to intervene before your 'autoreset-password-checker' and catch the DTR in my code. </p></blockquote> <p>We definitely agree that this is an important feature. It's easily implementable in my proposed scheme. I'll make sure to add it in such a way that it's easy to override from user code (i.e., without modifying the libmaple source).</p> <p>supermac -- Thank you for the feedback on CAN. </p> http://forums.leaflabs.com/topic.php?id=861&page=3#post-6192 Sat, 03 Sep 2011 21:30:53 +0000 supermac 6192@http://forums.leaflabs.com/ <p>I would like to see native CAN support libraries. </p> http://forums.leaflabs.com/topic.php?id=861&page=2#post-6177 Thu, 01 Sep 2011 17:17:15 +0000 gbulmer 6177@http://forums.leaflabs.com/ <p>I'd still prefer a way to for my code to intervene before your 'autoreset-password-checker' and catch the DTR in my code.</p> <p>Rather than you guys come up with some ingenious way to make it highly unlikely that a false DTR-driven-reset happens, I'd like to get the DTR and decide for myself what to do.</p> <p>I think we agree, DTR is the only cross-platform out-of-band signal USB serial signal.<br /> IMHO, that makes it far to useful to waste by tying it irrevocably into the USB reset mechanism. </p> http://forums.leaflabs.com/topic.php?id=861&page=2#post-6014 Fri, 19 Aug 2011 16:46:06 +0000 mbolivar 6014@http://forums.leaflabs.com/ <p>hey all,</p> <p>just a bump to let you know we haven't forgotten about this; i've been chipping away at this periodically, and here's the status.</p> <p>usb-touchups now has a pair of files, usb_cdcacm.h/usb_cdcacm.c which control all the VCOM functionality; usb.h and usb.c are now just pretty thin skins on top of ST's usb_lib/.</p> <p>for the near future, i've decided against replicating all the code in usb_lib/; there's too many other things on my plate to make this worthwhile at the moment. i managed to get rid of the things i hated most (the biggest win was replacing usb_regs.h with a new usb_reg_map.h), so i'm satisfied for now. </p> <p>anyway, in terms of user-visible changes, i was thinking about the autoreset scheme, and wanted to try a new way to go about it. the basic idea is to interpret DTR/RTS changes as a sequence of bits. at compile time, we decide a particular sequence to use as a "password". to reset the board, just "send" this password over DTR/RTS.</p> <p>the idea is still preliminary, and i'd like to take this time to solicit some feedback from any interested parties. more details on my idea and its current implementation are available in this commit:</p> <p><a href="https://github.com/mbolivar/libmaple/commit/6c5bc6eb40868f997d67ca3aadd707dc3844b6c0" rel="nofollow">https://github.com/mbolivar/libmaple/commit/6c5bc6eb40868f997d67ca3aadd707dc3844b6c0</a></p> <p>edit: the reason why i want to do it this way is because it seems likely that it will be very reliable, and also for the improved separation of concerns between autoreset and data transmission. this should let us avoid certain classes of bugs entirely, e.g. the current (libmaple 0.0.11) situation, where you can't autoreset the board if SerialUSB has any unread bytes, since the RX endpoint will just NAK attempts to send the '0x1eaf' sequence.</p> <p>as long as the DTR/RTS password is long enough and implausible enough, it should be unlikely to occur in common use, and besides which, we can always revise the docs to make it clear that libmaple claims DTR and RTS for its own purposes. </p> http://forums.leaflabs.com/topic.php?id=861&page=2#post-5386 Thu, 23 Jun 2011 10:43:03 +0000 gbulmer 5386@http://forums.leaflabs.com/ <p>mbolivar - Thank you. I think you've given is a helpful explanation because I think I understand your view a bit better. </p> http://forums.leaflabs.com/topic.php?id=861&page=2#post-5379 Thu, 23 Jun 2011 01:32:25 +0000 mbolivar 5379@http://forums.leaflabs.com/ <p>regarding (1), i agree that it's not a show-stopper. i also agree that (2) is the most relevant in terms of easing user pain. however, i think you're underestimating the value of (3) as a prerequisite for fixing the problems in (2).</p> <p>i don't know if you've had a look at the contents of libmaple/usb/usb_lib/. frankly, it's a mess. many important things are accomplished by side-effecting global variables that are scattered about the source code. the documentation looks like it was written in order to fulfill a requirement, rather than educate the users about how things work.</p> <p>as you might imagine, using such a thing correctly is not the easiest thing in the world.</p> <p>it will be easier, and get results faster, to rip out all of that extra complexity before proceeding further. the fact that doing so is a good investment in the future of the library is just a secondary benefit.</p> <p>to be perfectly clear: i am explicitly not trying to make an end-all-be-all USB library. i _am_ trying to do the stupidest thing that could possibly work. saying "not general enough" in my previous post was a mistake on my part. i meant that the public usb.h interface wasn't too general; ST's code is of course general-purpose, but using it has all the problems described above.</p> <p>as you know, we really want a serial-only bootloader. i truly believe that it will be faster to first put together a better USB interface, then write such a bootloader on top of that, rather than try to put something together using the code we have now.</p> <p>when i talk about moving over to libmaple's conventions, i'm not trying to start a bikeshed argument. we write libmaple because it makes it easier to develop for the STM32, not out of NIH or tabs vs. spaces.</p> <p>we're an open source company; of course we are happy to build upon work shared by others. we'd be happy to use LUFA or whatever other open source library, if it gets the job done. however, porting LUFA would take way more time than the path we're taking now. </p>