Also, baud rate sounds awesome; we'll pick up a Leonardo and play with it.
Thanks, feurig!
A proposal to improve Maple Firmware (Bootloader)
(67 posts) (13 voices)-
mbolivar
LeafLabsfeurig:
I am actually more concerned with the Maple2/F4 part of the centric
I'm OK with this, at least for now. Practicality beats purity on this one. I especially want to avoid standards proliferation.
I think the Right Thing for solving the general problem is to have the comm processor speak the GDB serial debug protocol to the host, and JTAG/SWD to the STM32 for uploads. (This would also make it easy to bring GDB into the IDE, which would freaking rock.) This has been done for a variety of Cortex M3s, and could conceivably be ported to other architectures.
That's outside the scope of the next Maple, though.
Posted 3 years ago # -
gbulmer
ModeratorIt is worth noting, the Leonardo needs a new-ish version of the Arduino IDE. I know I haven't upgraded my Arduino IDE to the most recent one because I was doing some nasty, ugly, hacking, and I have had upgrades break that sort of code.
I'll assume the thanks were also to Mark who noticed and mentioned that Leonardo used baud-setting for out of band signalling.
Posted 3 years ago # -
gbulmer
Moderatormbolivar - I did assume it was just a 'slip of the pen' :-)
Comments on #post-12052
We've gone back and forth about this. One thing we have decided is that the comm processor will be reprogrammable via JTAG/SWD, using the standard ARM 10 pin connector (the same one you can use on the Maple Native beta boards).
I'd be willing to accept a 'standard' ARM 0.05" pitch 10 pin connector if you're pushed for space.
There are also going to be additional shared lines between the comm proc. and the F4, at least some of whose meaning will be left undefined by LeafLabs.
The key question is, will those lines appear on header pins, or pads that I can get at?
An extra button seems like asking for trouble ("How do I read that button on the Maple?" "I keep pressing the button, but nothing happens!").
1. This sort of thing is solved by careful use of silk screen and geography. Put a line across the board to show the comms processor area, and put a button on its side of the board.
2. I am happy if there are some pads I could get at.
2. Is the assumption that the comms processor and the host-reset-handshake will work perfectly always? Will the comms processor NOT have a "the user wants to upload and maybe something isn't work perfectly" button? I admire your confidence. I feel it might be worth considering a fallback. For example shorting a pad, or adding a button might cause the comms processor to go into some cognate of perpetual upload mode.We're leaning against an additional USB socket on grounds of simplicity: if we have USB, then do we break out CAN? Where does it stop? We don't want to be just another kitchen sink board.
I think 'Less is more', so I can understand the dilemma.
The F4 has two CAN and two USB, so you could track one of each.
Is there space to track the relevant signals to a 'comms header' for each, so anyone could easily make a little plug-in PCB?
On board High-speed USB might be very attractive given the raw sampling speed and computer power of an F4, but I can appreciate that technology is more difficult to get working.Is this board intended to permanently have the comms processor attached, or is it like a few of the ST and NXPresso boards where the JTAG part can be removed, and the board be embedded in a project? If the board can be cut in two, then a (different size) USB might be handy just to supply power; USB wall-warts are super-cheap, and convenient to use.
Posted 3 years ago # -
gbulmer
Moderatormbolivar - post-12056
I think the Right Thing for solving the general problem is to have the comm processor speak the GDB serial debug protocol to the host, and JTAG/SWD to the STM32 for uploads.
I strongly agree. I have been using STMxDiscovery boards with JTAG/SWD. Lovely.
That's outside the scope of the next Maple, though.
But, is this comment saying you are not going to make the signals available to the comms processor to upgrade? I realise it is better to do what is testable and safe, and not waste time and effort on something that can't be adequately tested, so 'No' is okay.
That "Black Magic Probe" looks like an excellent piece of work. I'd previously missed that, and I think so has the guy I know at ST, so thank you for pointing it out.
Another Open Source STM32 JTAG project, which you know, but some may have missed is Versaloon
Posted 3 years ago # -
mbolivar
LeafLabsThe key question is, will those lines appear on header pins, or pads that I can get at?
That's not part of the current plan, which is only to have them accessible via software on the F4. This allows for "manual" access by having that software additionally listen to another pin which has already been broken out.
But, is this comment saying you are not going to make the signals available to the comms processor to upgrade?
No. The idea came to us too late in the design to implement. That sort of thing will have to wait for Maple 3 ;).
That "Black Magic Probe" looks like an excellent piece of work.
It is. I've been using them for months, and they work flawlessly. The new editions use the 10-pin JTAG connector, so they'll be perfect for Maple 2. I've corresponded with the developer some as well; he's smart and very responsive.
Posted 3 years ago # -
mbolivar
LeafLabsIs the assumption that the comms processor and the host-reset-handshake will work perfectly always? Will the comms processor NOT have a "the user wants to upload and maybe something isn't work perfectly" button?
If not always, then often enough that the simple expedient of power cycling should solve any remaining problems. Hopefully, that's not too brazen.
Point taken, though. The current design has a "comm reset" that we were going to take out, but some perpetual bootloader style thing is a reasonable idea.
Is this board intended to permanently have the comms processor attached, or is it like a few of the ST and NXPresso boards where the JTAG part can be removed, and the board be embedded in a project?
It's permanently attached. The layout is pretty tight, though, and we don't think the size will disappoint.
Posted 3 years ago # -
Mboliver My larger concern about the f4 is the cost/accessibility. The $5 verses the $15 arm. Also my issue with the DUE. What you are working out sounds cool! As long as you plan to continue libmaple support for the low end processors then my complaint is kind of mute.
Posted 3 years ago # -
Aslo. I am not sure how you would be hurt by implementing a vendor specific control request in addition to whatever you decide to do here.
The joy of this method would be that it would cross usb classes. I have not tested this on lion but you can talk past the drivers directly to the device up through snow-leopard. (sorry about my osx centered viewpoint) This still would require that your device enumerates (though the same code could be used to reset a cdc device or a hid device or ...)
I wouldn't solve problems like the double reset issue being experienced elsewhere in the forum.
Posted 3 years ago # -
mbolivar
LeafLabsAs long as you plan to continue libmaple support for the low end processors
Yes, definitely. libmaple support for F1s isn't going anywhere, and in fact should continue to improve.
The joy of this method would be that it would cross usb classes. I have not tested this on lion but you can talk past the drivers directly to the device up through snow-leopard.
Yeah, but it also requires custom USB driver work, which ... yuck. I guess libusb might help on Windows, but it's just not something we can afford to support.
Posted 3 years ago # -
mbolivar
LeafLabsUpdate: preliminary implementation:
https://github.com/mbolivar/libmaple/commit/df546c1ab0d8d35e7054be3c67ee8973a70b2ce7/
The current strategy is to accept both reset signals (DTR + "1EAF" and closing the connection when baud=1200). We can rip out the old sequence once the new one is widely installed.
Please test this out! It's in the new-reset-signal branch of my libmaple tree. HOWTO test(from within libmaple):
$ git remote add -f mbolivar git://github.com/mbolivar/libmaple.git $ git checkout -b new-reset-signal mbolivar/new-reset-signal $ make clean $ cp examples/blinky.cpp main.cpp $ make clean $ makeNow play away! IMPORTANT: the first time you upload using this new code, your board must be in perpetual bootloader mode. This is because reset.py in this tree no longer sends the old reset signal, so you'll need to "bootstrap" the install process by doing one upload to get the new reset firmware installed before it starts working.
Independent confirmation that this works on various machines would be really nice.
Update: Seems to work pretty reliably (one failure out of 15ish attempts) on OS X 10.6.
Posted 3 years ago # -
I've tested this on a maple mini rev3 on 64bit ArchLinux.
The method seems to work, but not with the python script (no matter if run with python2 or python3).
The new reset.py script runs without errors, but the maple mini board is not reset.
The old reset script/scheme still works as expected, though.
What works for me is connecting to the maple mini with screen with a baud rate of 1200 and then disconnecting.
> screen /dev/ttyACM0 1200
>> C-a C-kThen the maple mini does reset.
Posted 3 years ago #
Reply »
You must log in to post.