This is will make debugging earier if this does happen, rather than
dereferencing the null pointer (or passing it to memcpy, or worse).
blackmagic PR #475
* [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
* DI layout is identified by attempting to read OUI from both layouts
* MSC address is passed to flashstub in r3
Retested EZR32LG230 (EZR Leopard Gecko M3)
Tested EFR32BG13P532F512GM32 (EFR Blue Gecko)
Achieves aims of PR #264 (I think) Thanks to @dholth and @ryankurte for inspiration
Fixes Issue #226
