DFU integration

[xJurgen]

Hi! I'm currently trying to integrate serial monster into the Maple DFU bootloader (https://github.com/rogerclarkmelbourne/STM32duino-bootloader). Is it planned into future releases or are there some hidden problems? I think it can be really useful feature.

Thanks!

[r2axz]

Hi,

I currently don't have such plans. However, I believe everything should be pretty straightforward and there should be no hidden issues with that.

Right now, serial monster uses STM32F103XB_FLASH.ld, which defines FLASH ORIGIN to 0x08000000. I believe Maple DFU requires this to be changed to 0x8002000 or 0x8005000 depending on the bootloader settings. I think this is the only change that is needed.

If would be great if we can find a way to override FLASH ORIGIN in STM32F103XB_FLASH.ld without modifying the original linker script with a Makefile option or something like that. STM32F103XB_FLASH.ld has somewhat a restrictive license, which forbids distribution of unmodified or modified versions of the file. That's why I don't really want to include it into the source tree.

Alternatively, we can create our own version of the linker script, which does everything we need.

[xJurgen]

I tried to change the address in FLASH_BASE (i suppose that's it because I haven't found FLASH ORIGIN) from 0x0800000 to 0x08002000 (even tried 0x08005000) and it doesn't work. I think it won't be simple as just changing one value.

When I try to list currently connected DFU devices using dfu-util (after loading user code - in this case serial monster), I get only "Unknown" values.

[r2axz]

How exactly did you change FLASH_BASE? I am asking because FLASH_BASE is a C macro defined in stm32f103xb.h and it has nothing to do with the linking phase.

I was talking about Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc/linker/STM32F103XB_FLASH.ld, specifically this part:

/* Specify the memory areas */
MEMORY
{
FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 128K
RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 20K
}

I think you should change FLASH ORIGIN here and see if that helps.

[xJurgen]

Yes! That's it! Now it works PERFECTLY!

My IDE didn't show me the linker subfolder so I thought you meant FLASH_BASE macro and I just directly assigned a value to it.

Thanks!

[r2axz]

Sounds great, thank you for confirming it works.

[xJurgen]

After some testing I've discovered, when you unplug the Bluepill or press reset button, everything goes back to the "Unknown" state as mentioned before.

[r2axz]

What exactly do you mean by unplugging? Is you bluepill USB-powered or it receives power via an external PSU? In other words, does unplugging also mean power off?

Is everything OK when there are no external PSUs connected to bluepill and the board is plugged in to USB?

As for pressing the reset button, currently serial monster does not force USB re-enumeration on power-on, which probably the reason for this behavior. The board is reset, but the host does not know about it.

[xJurgen]

I meant USB cable, not an external PSU, so yes - unplugging means power off.

Everything works fine until you try either unplugging or pressing the onboard reset button which makes it fall into the "Unknown" state.

[r2axz]

OK, thank you. I think at this point I need to perform some experiments myself in order to figure out what goes wrong. I can probably do this in the next few days.

[xJurgen]

Another interesting thing I found is that after I restarted my PC, everything started to work again, until I powered off (unplugged the USB/pressed the reset button) the Bluepill again. I think it really leads us to the missing USB re-enumeration on power-on.

Edit: The only workaround I've found so far for this is pulling D+ pin down for a few seconds to force the re-enumeration on the host side. I will keep working on this and let you know if I come up with something.

[r2axz]

Thanks for the information. This may be as well a Maple DFU bug. Or, a combination of Maple DFU + serial monster code may yield a bug. Or, and this is really important, check if your bluepill has 1.5 k resistor between D+ (PA12) and 3.3 V. This is mentioned in serial monster README and also in Maple DFU README. If the resistor is 10k, or 4.7k, there can be issues with USB re-enumeration in Maple DFU please check this:

"On "generic" boards, the USB reset (to force re-enumeration by the host), is triggered by reconfiguring the USB D+ line (PA12) into GPIO mode, and driving PA12 low for a short period, before setting the pin back to its USB operational mode. This USB reset method was written by @Victor_pv. Note: It is not guaranteed to work on all "generic" STM32 boards, and relies on PA12 having a pull-up resistor of around 1.5k - however most "generic" boards seem to have this. Its unclear if this method to reset the USB bus conforms precisely to the USB standard, but it seems to work fine on all PCs, Macs and Linux boxes on which it's been tested - and seems usable for hobby / non commericial / non-critical systems."

Taken from here: https://github.com/rogerclarkmelbourne/STM32duino-bootloader

All the bluepill boards I have didn't have 1.5k resistors initially and I had to replace the resistors.

[xJurgen]

I've checked all of my Bluepill boards and every one of them has 1.5k resistor.

I will look into the Maple DFU aswell but first I'll try to fix this on serial-monster side by forcing re-enumeration on every power up. I'm not sure if I'll be able to do it though.

[r2axz]

Sounds like a plan. I will also look into that as promised.