STM32Duino core does not do well with Maple bootloader

[Phono]

I am porting several sketches from Roger's core to Arduino IDE + STM32Duino core.
I am using an Olimexino STM32 board, which includes a physical USB interface directly to the USB pins of the STM32F103RBT6, and the original Maple bootloader. I compile using the option "USB CDC generic serial".
This bootloader is the first to start when the chip is reset. If within a few seconds it did not receive a signal (produced by a button ad hoc), it jumps to the application.
On the other hand, when the IDE downloads a binary file to the Flash memory of the chip, it triggers a reset using the DTR signal on the COM port, that restarts the chip and puts the bootstrap loader in program mode.
As soon as the the programming is finished, the bootloader restarts the chip. Then, since no event takes place, after a few seconds, the bootloader jumps to the application (the sketch).
It is this last operation that fails too often. The chip restarts after flashing the memory, but the sketch code is not executed, and the virtual COM port does not initialize (it does not show in the device manager of Windows). This is also the case if I press the reset button of the board.
On the contrary, if I disconnect the USB cable which at the same time powers the board, and I reconnect it, the boot sequence is correct and the sketch starts excuting.
This problem is new. I have used Roger's core for years, and never had this problem.
I just have no idea of what goes wrong. What is the difference between pressing the reset button and disconnecting the USB cable, except that the power goes down and up? Are there floating variables or registers that have a wrong value after triggering a reset, and a good value after a power shortage?

[fpiSTM]

It seems in some case Bootloader drive the USB DP to low before leaving and then the enum does not works properly.
It was already discuss in other topics but I have no workaround for this.
The new release will change a little the re-enum management maybe this will fix this issue but in any case the bootloader should not drive the DP pin for the application.

Ref: viewtopic.php?p=2283#p2283

[Phono]

The discussion you mention with your link relates to the bootloader 2.0.
I this relates to the bootloader code stored in flash, It is not my case since the boards are delivered since the beginning with the original maple bootloader.
Which new version did you mention? When will it be available?

[fpiSTM]

This is the same or which bootloader you talk?

[stevestrong]

I think it is related to the GPIO toggling as startup before USB init, as done here:
https://github.com/rogerclarkmelbourne/ ... #L103-L107.
If this is missing than the port will be enumerated maybe 5 seconds or so after jumping to user code.
But the issue can also depend on the bootloader, if it does not leave the USB in a clean state before jumping to user code.
I do not know the old Maple loader, it may have such problems.
Why don't you use the Rogers bootloader 2.0?

[stas2z]

The discussion you mention with your link relates to the bootloader 2.0.
I this relates to the bootloader code stored in flash, It is not my case since the boards are delivered since the beginning with the original maple bootloader.
Which new version did you mention? When will it be available?

maple bootloader stored in the flash same as "bootloader 2.0", 2.0 initially based on original maple bootloader, but it much more compact, so it allows to waste only 8kb of your flash instead of 20kb for maple bootloader

[Phono]

At the time of flashing the code, the log says:

Code: Select all

maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...

Found it!

Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="DFU Program FLASH 0x08005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1291
Starting download: [##################################################] finished!
error resetting after download: usb_reset: could not reset device, win error: Un p�riph�rique qui n�existe pas a �t� sp�cifi�.

state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present

Done!
Resetting USB to switch back to runtime mode
timeout waiting for COM8 serial

If I were to use the bootloader 2.0, I would have to connect a SWD probe to every board, which requires unmounting the boards from their location since they all have a shield on top.
Since I never had any problem with the previous environments I used (Maple IDE then Arduino+Roger's core), i think there might be a problem in the STM32Duino core at initialisation time, before the Setup() function is called.
Also, I found in the forum here that I had to force the enumeration before initialising the CDC COM port by toggling the DISC signal (which drives a pullup to the USBDP pin, using the following code:

Code: Select all

  pinMode(DISC, OUTPUT);    // DISC
  // Open serial communications
  digitalWrite(DISC, HIGH) ;    // Enumeration request
  delay(100) ;
  digitalWrite(DISC, LOW) ;
  delay(1000);
  Serial.begin(115200);

In both Maple and Roger's core, I did not have to do this. It must be done silently in the core.

[stevestrong]

Toggling DISC pin is difficult because it may differ from board to board.
Why not toggling the USB_DP pin directly as I indicated above?

[fpiSTM]

This done in the core.
DP or disc pin dependings of the board.

[stevestrong]

I think USB DP depends on the MCU type, not on the board, right?
So far I only met STM32 MCUs having USB pins on PA11/PA12.