I would like to see native CAN support libraries.
Request for feedback: high-priority bugs/features
(41 posts) (14 voices)-
mbolivar
LeafLabsgbulmer,
I'd still prefer a way to for my code to intervene before your 'autoreset-password-checker' and catch the DTR in my code.
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).
supermac -- Thank you for the feedback on CAN.
Posted 4 years ago # -
kiwidude
MemberIt 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.
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.)
Posted 4 years ago # -
LarryP
MemberGreetings all,
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.
Some assertions, please take 'em with a grain of salt:
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
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.
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.
OK, some digression about the bootloader, the USB spec and what the bootloader needs to do.
At core, the bootloader needs to:
* Check the image in flash for integrity. (Optionally check the bootloader itself for integrity, but happens if it fails is less clear.)
* 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.
*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.
----
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 class drivers must be included for USB certification 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.
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.
Interestingly -- and IMHO relevant to the bootloader issue -- another defined-in-the-USB-spec class is the Mass Storage class, 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 -- and will need to continue to do this -- 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.
So here is a rough outline of my bootloader-variation proposal:
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."
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.
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 http://shop.moderndevice.com/products/usb-bub and consider it a good investment for when things go seriously weird.
FTI, here's a table of the various class drivers in the USB spec: http://en.wikipedia.org/wiki/Universal_serial_bus#Device_classes
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.
Posted 4 years ago # -
gbulmer
ModeratorI do not need such a complex bootloader.
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.
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.I have requirements which you have not mentioned.
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.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.
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.
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.
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?
What would it do to a file which allows the OS to keep writing data, maybe even beyond the size of the device?
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.
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.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.
I could imagine some of those OS's rely on timeouts to ensure things work, so that would need to be checked out too.Have you thought how this might work?
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'.
(Full disclosure: I am not a member of LeafLabs staff)
Posted 4 years ago # -
poslathian
LeafLabsI 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.
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.
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.
Posted 4 years ago # -
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:
.long __irq_tim8_brk
.long __irq_tim8_up
.long __irq_tim8_trg_com
.long __irq_tim8_cc
.long __irq_adc3
.long __irq_fsmc
.long __irq_sdio
.long __irq_tim5
.long __irq_spi3
.long __irq_uart4
.long __irq_uart5
.long __irq_tim6
.long __irq_tim7
.long __irq_dma2_channel1
.long __irq_dma2_channel2
.long __irq_dma2_channel3
.long __irq_dma2_channel4_5To fix the bug in support/ld/libcs3_stm32_src/Makefile add
high-density: ASFLAGS := -DSTM32_HIGH_DENSITY
below
high-density: CFLAGS := -DSTM32_HIGH_DENSITYRebuild and check that the resulting libcs3_stm32_high_density.a file is larger than libcs3_stm32_med_density.a. Currently the size is identical.
Posted 3 years ago # -
iainism
Member+1 to CAN support.
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).
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!
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?
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?
Posted 3 years ago # -
dipspb
MemberPull req sent to https://github.com/leaflabs/libmaple/pull/60
Fix for unresolved _exit reference with Summon/Linaro GCC ARM toolchain.regards,
DmitryPosted 3 years ago #
Reply
You must log in to post.