gbulmer
Moderator
I'd like a way to stop the DTR doing anything. I want the DTR to be ignored, so that it doesn't interrupt a running program and start consuming input.
My concern about the DTR+'1EAF' isn't limited to detecting a valid reset trigger, it is it blocking on an initial partial match, which has odds of 1 in in 256.
trevden
Member
dreamcat posted a link to the code that actually does the check:
https://github.com/leaflabs/libmaple/blob/master/libmaple/usb/usb_callbacks.c#L78-85
It won't block on a single byte -- it will actually only work if all four bytes are in the receive buffer at the same time.
gbulmer
Moderator
trevden - I'd like a way to remove that check for 4 bytes completely.
I think this is a rare case, but having the flexibility to ignore DTR+signature seems to be reasonable.
I'd be okay if the code:
char chkBuf[4];
char cmpBuf[4] = {0x31, 0x45, 0x41, 0x46};
//...
int i;
USB_Bool cmpMatch = TRUE;
for (i=0; i<4; i++) {
if (chkBuf[i] != cmpBuf[i]) {
cmpMatch = FALSE;
}
}were wrapped up in a little function:
int checkDTRSignature(char chkBuf[]) {
// ... insert here
return cmpMatch;
}and called via an initialised function pointer:
static int (*cmpDTRSignatureFunction)(char chkBuf[]) = checkDTRSignature;then the existing function vcomDataRxCb changes to:
if (newBytes >= 4) {
unsigned int target = (unsigned int)usbWaitReset | 0x1;
PMAToUserBufferCopy(chkBuf,VCOM_RX_ADDR,4);
if (cmpDTRSignatureFunction && (*cmpDTRSignatureFunction)(chkBuf)) {
asm volatile("mov r0, %[stack_top] \n\t" // Reset the stackThe cmpDTRSignatureFunction could be set via a little wrapper function that I could call.
I think that is all that is required.
I could write a dummy function:
int dummyCheckDTRSignature(char chkBuf[]) { return 0; }or just intialise cmpDTRSignatureFunction to NULL and its done.
I could also do smarter things if I wanted to. I would know this function is only being called when DTR has been received, so I could use that for my own purposes.
99% of users might ignore this completely
0.9% of users might just set the cmpDTRSignatureFunction callback to NULL so that DTR is ignored,
and the other 0.1% might do something more.
I don't think it's urgent unless there are people trying to make dataloggers (in which case I want to catch the DTR anyway) or communication gateways (in which case I don't want anything interpreting *anything* in the byte streams) using Maple.
Of course, I'd prefer to switch off the Mac's auto-DTR 'feature', and use DTR as a valid out-of-band signal.
(full disclosure: I am not a member of LeafLabs staff)
poslathian
LeafLabs
My two cents are thus:
1) We use in band signalling (DTR+ ascii '1eaf') to avoid the need for custom drivers that provide access to an out of band control signal. While on windows you still need to point to the usb serial driver (usbser.sys) via an inf it is a standard driver. On mac/linux nothing extra is needed driver side. DTR is not a viable out of band reset mechanism because as has been pointed out, we cant control it in the way we need (it gets toggled by OSs when opening/closing a channel, and in a different way for different OSs)
2) I agree that the two driver solution (DFU+Usb Serial) is a pain. The current proposal is to maintain the in band reset signaling (DTR + magic string) but switch the bootloader over to operate over virtual com as well. The debate over what protocol this serial bootloader should follow has been hashed out a lot elsewhere in the forums. A prototype exists. We are working to release something eventually.
3) Custom drivers just arnt in the cards for now. A Two-chip solution (like Arduino UNO, and mBed) is very interesting, solves a lot of these problems (since you can have the USB interface 'always on' the second chip, while the user sketch gets bare metal access to the second chip), but makes the board more expensive, and adds a lot of software overhead. Its still a candidate for a future board.
gbulmer
Moderator
poslathian - sorry, maybe I haven't been clear.
AFAIK, DTR is the only out-of-band signal that is available on all three supported platforms. So it doesn't need any custom drivers for out-of-band signalling. As a result, DTR is a very precious signal. Too precious to dedicate to the bootloader alone.
I appreciate that you need to get a reasonably robust way to deal with spurious DTR signals, and hence DTR+magic is a solution. That's fine, part of the time.
My issue is the bootloader works on the basis that the DTR is for it alone.
I want my program to get the DTR. I don't want the bootloader to absorb it. I want DTR to be available to my program because I have uses for it.
I want my program to get every in-band-byte. I don't want the bootloader interpreting any bytes, even when it is accompanied by a DTR.
I want to suppress the bootloaders DTR+magic completly.
A prototype exists. We are working to release something eventually.
When might something appear? It doesn't need to be anywhere near finished, but it does need to be clear what path you are taking; compatible with an existing protocol, or not.
3) Custom drivers just arnt in the cards for now. ...
Good.
Adding a second chip for USB just adds more complexity that I would have to get around.
IMHO, it is an ADVANTAGE to have a simple direct USB connection.
It is a DISADVANTAGE to have extra hardware between my programs and the USB signals.
To me, part of the attraction of a Maple is NOT about being yet another STM32F development board. I can get one of those for peanuts compared to a Maple.
IMHO part of the attraction of Maple is the 'Zen-like' simplicity; it is a low-complexity platform for building USB-enabled "anything". To enable that, it is important for the bootloader to be able to "get out of the way", and for user programs to have control to have it "get back in the way".
As we say in the UK, "Simples [squeak]" :-)
gbulmer
Moderator
Part of the DTR use does relate to the question on http://forums.leaflabs.com/topic.php?id=723#post-4199
We are interested in a 'data logging' style of application.
The Maple will be continuously powered. We want to plug and unplug USB repeatedly without resetting our program. We want our program to be able to repeatedly exchange data with a host program, then get disconnected and carry-on.
In that other thread, jessb said that the USB_P signal (on PC11/P$52) is no longer used.
So, can Maple detect that it has just got connected to USB?
mbolivar
LeafLabs
It's time to revive this thread for the Maple 2.
Here's my understanding of the situation. Please correct me if I'm wrong:
That in-band signaling is nothing but a mess is well-established, I think. That using DTR for reset signalling is an abuse of the line is also true.
Additionally, gbulmer states that he wants a direct connection to the MCU's USB, with the bootloader getting out of the way as necessary. We can certainly appreciate the blessings of software that assumes you're right, but this approach isn't going to work on Maple 2. We're going to go with a second chip that speaks serial to the F4, and USB-serial to the host.
There are many reasons why.
First and foremost, the USB peripherals on the F4 have a different register interface, and libmaple isn't ready to handle them. Keeping the bootloader on the F4 thus means a ton of extra firmware work, which means extended delays. Note also that as the years have passed, significant non-serial USB work with Maple has yet to be performed, at least to my knowledge. Sure, there's lots of demand, but nobody's stepping up and writing the code, which means it'd be up to LeafLabs to get it done, and we don't have the developer resources for that right now.
It's also worth noting that USB interrupts really interfere with time-sensitive applications, and that's been a support headache for us and a positive hindrance to some of our users. Having a second chip means that by default, the only interrupt you'd need to worry about is SysTick (for millis()), and you can still perform uploads normally (without resorting to hacks like perpetual bootloader mode).
We disagree that having a second chip means that Maple 2 will automatically be "yet another STM32F development board".
That still leaves the upload and reset signalling questions open. I'll address those in my next post.
mbolivar
LeafLabs
As described previously, there will be a second chip (we've been calling it the "comm processor" internally, and I'll use that term here) between the host PC's USB and the STM32F4 on Maple 2.
We'd like to use this thread to discuss our current plans for how this will work, and solicit feedback. We've got a prototype Maple II we're trying things out on, but there will be another revision, so now is the time for any feedback, as any changes can still be made before the next run.
Our plan for how this chip will reprogram the F4 is as follows. As many of you know (and as is documented in ST's AN 3155 and 2606), all STM32s have a baked-in bootloader that speaks USART. Thus, to perform an upload, the comm processor only needs to respectively set the F4's BOOT0 and BOOT1 lines high and low while resetting it. It can then allow the host PC to handle the business of uploading the new program merely by shuttling bytes back and forth as if it were an FTDI chip.
Advantages:
- Simplicity.
- Any updates (to the serial upload protocol, e.g.) can be handled with IDE patches, rather than requiring a new bootloader.
- Requires a small number of shared lines (BOOT0, BOOT1, NRST, and USART TX/RX).
- The required host software already exists (in libmaple's support/stm32loader.py). We've recently updated stm32loader.py to support F2 and F4.
- Does away with separate DFU mode. The comm processor stays enumerated as USB-serial all the time. During normal operation, it's still doing serial passthrough, but in support of Wiring's Serial object.
Ok, so that's uploading, but what about reset signalling? Good question.
It seems (at least to me) that the pragmatic choice is to go ahead and abuse DTR. (If anyone has another solution that doesn't require extra Windows drivers, we're all ears.) That leaves the OS X question open. If I understand correctly, the issue is that OS X asserts DTR when when the serial port is opened, and deasserts it on close, and can't be prevented from doing so.
To work around this, I propose we accept gbulmer's earlier suggestion that a specified sequence of timed DTR pulses with no data in between be adopted as the Official Reset Sequence (tm).
This reserves DTR for the bootloader's exclusive use. We understand that's an annoyance, but we believe it's an annoyance that only advanced users will experience. If such a user really needs DTR for something else, they can still buy an FTDI breakout (or whatever) and connect it (including DTR) to another one of the F4's serial ports. Hardware flow control isn't yet part of libmaple, but we imagine it's not too much trouble for an enterprising hacker to add, and in the meantime, you can always use an external interrupt on that pin.
Thoughts? Flames?
gbulmer
Moderator
Here's my understanding of the situation. Please correct me if I'm wrong:
I'll try :-)
In-band reset signalling is verboten.
For specific projects, yes.
DFU makes it painful for schools and other highly restricted computing environments to use Maple; a single USB-serial driver would be best.
Yes. This is probably the biggest problem.
The only out-of-band serial signal we can rely on cross-platform is DTR.
Yes, I believe it works across Windows, Linux, Mac OS X and others (I believe it works on Solaris, for example)
DTR is always asserted on OS X when the serial port is opened.
I don't know so, though I honestly haven't checked the last two OS X releases.
That in-band signaling is nothing but a mess is well-established, I think.
Yes.
That using DTR for reset signalling is an abuse of the line is also true.
1. We are discussing the connection between a host computer and a future Maple. In what way is using DTR for reset an abuse of the line?
2. AFAIK DTR is the only available, cross-platform signal, there is no alternative for out-of-band signalling. So what is the purpose of raising this?
3. AFAIK, none of the RS232/modem signals were designed to reset remote equipment, but IMHO, depending on how you view the host and Maple, DTR is a plausible candidate.
Based on http://en.wikipedia.org/wiki/RS-232
DTR indicates the presence of 'terminal' to a 'modem'. IMHO, this seems a reasonable reset event.
DCD 'modem' is connected to the telephone line.
DSR 'modem' is ready to receive commands or data.
DSR 'modem' has detected an incoming ring signal on the telephone line. Might also be a plausible reset event
RTS 'terminal' requests the 'modem' prepare to receive data. = flow control.
CTS Indicates 'modem' is ready to accept data. = flow control.
I don't see anything there which specifically covers what we might want to piggyback on those signals.
We're going to go with a second chip that speaks serial to the F4, and USB-serial to the host.
Do whatever makes business and technical sense to you.
gbulmer
Moderator
mbolivar - I very strongly agree with aiming to use existing, pre-installed, tried and tested (though I'm told a bit flaky) USB device drivers, and CDC serial is probably the only one that fits the task.
For me, everything else is trivial by comparison.
Is there a RESET button on the board that forces the F4 through the Reset vector (at 0x00000004)?
Will their be any LeafLabs code permanently installed on the F4, or will it pristine, with all memory available?
Is the "comm processor" running your software?
Will the "comm processor" source code be released?
Is there a 'user' button connected to the "comms processor", i.e. a button which software can scan and is open for interpretation?
If there is access to source, and a button available, people who want to do the work could modify the code to whatever they need; for example, they might ignore DTR as a reset.
If there is not a 'user' button, is their space for a pin header (with at least one pin connected to a "comms processor" I/O pin, and the others to Vcc and Ground) that a user might populate with a switch?
It might be worth having a couple of pads, if their is space and "comms processor" I/O available, for future applications. Ideally these would be on a 0.1" pitch.
As the "comm processor" is talking to the F4 over BOOT0, BOOT1, NRST, and USART TX/RX, then can I assume Maple's USB is freely available for other uses?
Is their a USB socket on board connected to the F4's USB interface?
gbulmer
Moderator
feurig - "baud sequences"
Are you saying that messages about baud rate, and baud rate changes, triggered on the host side (presumably using ioctl) to a USB CDC device driver, get through to the USB device on WIndows, Linux and Mac?
If that is the case, that is news to me. WOW!
That seems to have the possibility of being unambiguously out-of-band.
It also provides an enormous interface (i.e. lots of data bits could be sent).
I doff my hat to you sir.
gbulmer
Moderator
Quelle coincidence!
My chum Mark spotted the 'baud rate change' as the remote RESET mechanism for the Arduino Leonardo yesterday, and emailed this morning. See "Automatic (Software) Reset and Bootloader Initiation"
http://arduino.cc/en/Main/ArduinoBoardLeonardo
It says:
Rather than requiring a physical press of the reset button before an upload, the Leonardo is designed in a way that allows it to be reset by software running on a connected computer. The reset is triggered when the Leonardo's virtual (CDC) serial / COM port is opened at 1200 baud and then closed. When this happens, the processor will reset, breaking the USB connection to the computer (meaning that the virtual serial / COM port will disappear). After the processor resets, the bootloader starts, remaining active for about 8 seconds. The bootloader can also be initiated by pressing the reset button on the Leonardo. Note that when the board first powers up, it will jump straight to the user sketch, if present, rather than initiating the bootloader.
I guess this has the potential to become the "standard reset mechanism".
The great thing about this is it can be tested for a few $, and without writing any software, just buy a Leonardo :-)
Host side software might be prototyped and tested using it, or just use the software already written (though I realise that's not "the MIT way").
It satisfies my requirement for out-of-band RESET, and (for some projects) not to reset whenever opening a connection.
I suppose a smart move would be to port it to the Maple, and solve its bootloader issues.
mbolivar
LeafLabs
gbulmer:
Is there a RESET button on the board that forces the F4 through the Reset vector (at 0x00000004)?
Yes.
Will their be any LeafLabs code permanently installed on the F4, or will it pristine, with all memory available?
Pristine. All resources available to the user.
Is the "comm processor" running your software?
Will the "comm processor" source code be released?
Yes to both.
Is there a 'user' button connected to the "comms processor", i.e. a button which software can scan and is open for interpretation?
If there is access to source, and a button available, people who want to do the work could modify the code to whatever they need; for example, they might ignore DTR as a reset.If there is not a 'user' button, is their space for a pin header (with at least one pin connected to a "comms processor" I/O pin, and the others to Vcc and Ground) that a user might populate with a switch?
It might be worth having a couple of pads, if their is space and "comms processor" I/O available, for future applications. Ideally these would be on a 0.1" pitch.
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). 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. We like this mechanism for extending the comm proc.'s functionality mostly because it doesn't involve extra jumpers or pads that might be confusing to beginners. 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!").
If anyone else wants to chime in on what they'd like to see in this regard, your feedback would be very welcome.
As the "comm processor" is talking to the F4 over BOOT0, BOOT1, NRST, and USART TX/RX, then can I assume Maple's USB is freely available for other uses?
Is their a USB socket on board connected to the F4's USB interface?
Yes, it's freely available. 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.
You must log in to post.
