Quick question. Can we enter the dfuse bootloader programatically or do we need to load a different bootloader?
Inofficial libmaple F3-port
(66 posts) (9 voices)-
@crenn, as long as USB_DP is manually pulled up, the host will think it's still the same device, I guess.
@feurig, yes we can, like that:
// jump to system memory, aka DfuSe boot loader
asm volatile (
"\tLDR R0, =0x1FFFD800\n"
"\tLDR SP, [R0, #0]\n"
"\tLDR R0, [R0, #4]\n"
"\tBX R0\n");
But you still have to manually pull up USB_DP, as all registers seem to be reset upon entry to the DfuSe bootloader, so toggling the DISC pin programmatically will be reverted.
Posted 2 years ago # -
Shouldn't it be possible to cause the DISC pin to go high at the start of the initialisation routine and cause the host to think the device has disconnected before initialising the USB Serial?
Thinking of trying to update the current IDE to see if we can't support the new boards and the F3s.
Posted 2 years ago # -
@crenn
correction: In my case it does not work, as I use an additional 1.5k resistor directly from USB-DP to Vcc, toggling the DISC pin will have no effect, as USP-DP is permanently pulled-up.
I've only now had a look at your mod: http://pic.twitter.com/ZLB7G5gD8j
If I get it right, you still have a functional DISC circuitry with the sole difference, that it pulls up USB-DP with a floating DISC pin, whereas the unmodified DISC circuitry does not?
Then you could toggle the DISC pin in the board setup to denumerate the device after flashing, yes.
Doing this in the boards setup should do the trick then?
libmaple/wirish/stm32f3/boards_setup.cpp
-----------------------------
__weak void board_setup_usb(void) {
gpio_set_modef(BOARD_USB_DISC_DEV, BOARD_USB_DISC_BIT, GPIO_MODE_OUTPUT, GPIO_MODEF_TYPE_PP);
gpio_write_bit(BOARD_USB_DISC_DEV, BOARD_USB_DISC_BIT, 1); // release 1.5k pull-up (denumerate)
SerialUSB.begin();
}
Posted 2 years ago # -
That's correct, although now if the microcontroller is not driving the DISC pin, T1 is always on. I should be able to force T1 off by putting a 1 on the pin although this means the pin will be sourcing 15mA, which probably isn't the best thing for the microcontroller.
I had attempted to do that yesterday night, however it didn't make a difference, it is possible it may need to be held low for a time (Or get the USB-DP pin to go low) for windows to recognise that the device has been 'disconnected'. I'll need to do some experiments after work to see if I can get this to work.
Posted 2 years ago # -
The simplest way do have a disconnect is with a 1k5 pullup on DP+ and pulling down the DP+ pin directly before you initialize USB. This way you do not even need a disconnect pin.
I use this method on the evvgc board, which does not have a separate disconnect pin.
You also have to pull DP+ down before you enter the built in boot loader.Posted 2 years ago # -
@ala42, does that theoretically mean that we could ditch the DISC circuitry all together?
@gbulmer, I'm using an Orone Mini S8A and don't foresee building any more orone boards for the time being. I've actually added a 220 Ohm pull down on the DISC signal to force the transistor on without any additional pads. My Orone Mini with the STM32F103CC doesn't have this mod.
Posted 2 years ago # -
Well, I've done some experiments and have successfully gotten the USB to denumerate then renumerate as the USB Serial. I also noted that the bootloader seems to pull USB DP down of it's own accord without any code modification. However the only way I've been able to confirm this behaviour is by forcing it into bootloader mode (Reset and holding BUT) and also holding BUT while trying to upload a sketch in the IDE. Boot 1 is currently tied to ground via a jumper.
Here's the code I'm using in libmaple/wirish/stm32f3/boards_setup.cpp to get it to work:
__weak void board_setup_usb(void) {
gpio_set_modef(BOARD_USB_DISC_DEV, BOARD_USB_DISC_BIT, GPIO_MODE_OUTPUT, GPIO_MODEF_TYPE_PP);
gpio_write_bit(BOARD_USB_DISC_DEV, BOARD_USB_DISC_BIT, 1); // release 1.5k pull-up (denumerate)
delayMicroseconds(25);
SerialUSB.begin();
}I haven't experimented forcing DP low, however shouldn't be any reason why it can't work as far as I can tell. I might experiment with that tomorrow night (sadly only get a limited time to work on these things now) and if all goes well, we might be able to use a similar scheme with the F1s and save a bit off the BoM for the Orone boards.
@ventosus, does the USB Serial code reset into bootloader or just the micro? This will be important when I look at doing a community release of the IDE.
Posted 2 years ago # -
> @ala42, does that theoretically mean that we could ditch the DISC circuitry all together?
Yes. It can get difficult to get control over the pin again after USB was running. For the F1 to start the main program after the USB bootloader has given up or finished flashing I set a flag and perform a software reset. The bootloader checks this flag at startup and directly starts the main program if set.Posted 2 years ago # -
@ventosus, I'll look into putting in the code tonight and testing it out, the only problem I can think of is an accidental trigger into the DFU mode means it won't go back to the main program.
@ala42, At the start up procedures at both the bootloader and the main libmaple initialisation, it should be possible to just put the USB DP in open drain and tie it to ground for a short period. Not sure why that wouldn't work. It's essentially what I'm doing with the F3 boards, but I haven't tried on the F1 board as of yet. Maybe I should try to experiment with that afterwards.
Posted 2 years ago # -
Well, I've gotten using the assembly that ventosus provided, rebooting into the bootloader without any jumpers tying BOOT1 to ground which is good, although it would be nice to have some sort of time out to allow the microcontroller to reset if no firmware is sent, although this could also be considered an advantage as well since it will be easy to get the microcontroller into the bootloader and stay there.
The next step that I'll be working on is trying to modify the Maple IDE (which is going to be a task and a half since I don't know a lot about it) to allow for the new build mechanisms. This might be a slow process, but will have to see what happens for the moment. If I can, I also will see if it's possible to compile the core into a library so it doesn't have to be recompiled each time, but this will be an option and won't be until after the IDE can work with at least the Maples and F3 Orones.
The code I modified is in wirish/usb_serial.cpp:
#define RESET_DELAY 100000
static void wait_reset(void) {
delay_us(RESET_DELAY);
asm volatile (
"\tLDR R0, =0x1FFFD800\n"
"\tLDR SP, [R0, #0]\n"
"\tLDR R0, [R0, #4]\n"
"\tBX R0\n"
);
//nvic_sys_reset();
}Posted 2 years ago # -
gbulmer
Moderatorcrenn which version of the Maple IDE are you going to start with?
IIRC mbolivar has done some work which might be useful.I took a look through the source 2 or 3 years ago. I think I found find the parts which handle the build, and I don't think it felt too big to get comfortable modifying it. You might need help testing it on all three main platforms. I could try on OS X, if that helps.
Posted 2 years ago #
Reply »
You must log in to post.