Support for Kinetis KE04 8KiB, 64KiB and 128KiB variants in nxpke04.c
Target monitor commands for sector and mass erase.
Changes to kinetis.c MDM-AP target to support KE04.
Only KE04Z8 tested in HW.
* [efm32] Assume Device Identification (DI) version 1 if we don't know the OUI
Silabs are using some additional OUIs we don't know about. Reported in issue #389
These should use a DI version 1 layout, so assume version 1 layout for OUIs we don't
know. However do print a notice about this on DEBUG() as suggested by @UweBonnes
The IDCODE value is sufficient to make a positive identification of an EFM32 device.
See AN0062 Section 2.2. Therefore accepting any OUI is reasonable behaviour.
Additionally the part familiy is checked, and the target rejected if not in the
`efm32_devices` table. This commit makes that rejection explicit, although it does
not change the logical behaviour here.
Note that the important registers (part number, part family, flash size) are at the
same addresses in both layouts anyhow. Currently only `efm32_cmd_serial` and
`efm32_cmd_efm_info` functions use registers that differ between DI versions.
* [efm32] tidy format warning about portability UB
* [efm32] Simplify OUI checking
* Only read the OUI once
* Accept the device even if the OU is unknown, as silabs have been using
a variety of OUIs
* Perform fewer register reads before checking the device family is valid
Tested with x86_64-w64-mingw32-gcc-8.2.0 and cygwin gcc (GCC) 7.3.0.
Use libftdi1 unconditionally.
Try to convice github travis to use libftdi1.
Remove unportable "uint ". Thanks to jacereda for pointing out in #400.
* Add support for LPC11U3X devices.
The DeviceID register has a different address from the LPC11XX devices.
But it is shared with the LPC8XX family.
* Fix support for LPC1115 and LPC1115XL devices
* Fix whitespace
While scanning the USB bus for devices, stm32_scan() can find a device that it
doesn't have permissions to access it, dfu/usb class raises an exception and
stm32_scan() stops the scan completely.
This fix resolves the scan issue, by allowing the scan loop to continue.
While at it, there are cosmetic fixes related with tabs/spaces and readability.
Signed-off-by: Nikolay Dimitrov <nikolay.dimitrov@retrohub.org>
These extra cycles are needed by some CPU, e.g. STM32L0x1 to cross the SWCLK
/HCLK domains. Revert insufficient #373 also tackling that problem.
Thanks to Thorsten von Eicken for pointing out.