This change has also a practical reason. When flashing and testing the
hardware this change makes it easier to make sure all the LEDs work. Now
when the DFU bootloader is idle it is scanning the LEDs making it easy
to see if one of them has an issue.
In addition to that, the bootloader now indicates when there is data
being flashed using the DFU interface. In cases when one has more than
one device connected and accidently starts flashing a wrong device this
is very useful feature to have.
Until now the native hardware was pulling PB5-7 down and checking if
they were asserted high. BMPMV2b is pulling the pins down instead of
high. The hardware version routine now determines the hardware version
based on the fact if a pin is asserted at all. This means that if a pin
is left floating, the version number bit will be 0, and if the pin is
asserted either high or low the bit will be set to 1. While we were
already at it the "monitor version" command in GDB will now also print
the hardware version number.
There were a lot of nRF51 device ids missing. I wrote a script to pull nRF51 IDs from the openocd repository, which seems to be more up-to-date. The script's output goes in nrf51.c.
When gdb issues a `m xx,200` command, the probe should respond with a
packet of size 2*0x200=1024 which is the size of the packet buffer.
However, the `hexify()` procedures writes 1025 bytes in the buffer.
During my tests, it caused the probe to hang when issuing a `dump`
command. Presumably by overwritting the `cur_target` variable.
The F405 rev A uses a wrong CPUID, this patch use the core identifier to make
the distinction.
Tested with:
- F205
- F405 rev Z
- F429
Unfortunately, I do not have any F405 rev A.
The intention of `if (t->driver)` conditional was to test if any of the cases in the preceeding switch/case were met. However t->driver was previously set to point to a default value in cortexm.c:200 and therefore this would always evaluate to true. I've replaced the broken if statement with a duplicate of the switch/case run above.
It looks like this was introduced in 09544bc710 (PR #92) but 492d6c9cf8 maybe contributes to the confusion in this instance.
USB_VBUS is not an alternate function, it is an additionnal function which is
always enabled.
If configured as an alternate function, it will draw current from VBUS.
Gareth McMullin
Michał Derkacz
Piotr Esden-Tempski
Mark Rages
Mark Rages
Laurent Bonnans
Clement Burin des Roziers
Richard Meadows
Antti Nykänen
Uwe Bonnes
Nicolas Schodet
Benjamin Vanheuverzwijn