doryan/BloomPatched
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Tidying

Browse Source
This commit is contained in:
Nav
2024-02-15 21:25:32 +00:00
parent 7e9e28286f
commit a09de592f4
3 changed files with 2 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/Targets/Microchip/AVR/AVR8/Avr8.cpp
View File

@@ -786,20 +786,10 @@ namespace Targets::Microchip::Avr::Avr8Bit
this->avrIspInterface->activate(); this->avrIspInterface->activate();
/* /*
* It is crucial that we understand the potential consequences of this operation.
*
* AVR fuses are used to control certain functions within the AVR (including the debugWire interface). Care * AVR fuses are used to control certain functions within the AVR (including the debugWire interface). Care
* must be taken when updating these fuse bytes, as an incorrect value could render the AVR inaccessible to * must be taken when updating these fuse bytes, as an incorrect value could render the AVR inaccessible to
* standard programmers. * standard programmers.
* *
* For example, consider the SPI enable (SPIEN) fuse bit. This fuse bit is used to enable/disable the SPI for
* serial programming. If the SPIEN fuse bit is cleared, most programming tools will not be able to gain access
* to the target via the SPI. This isn't too bad, if there is some other way for the programming tool to gain
* access (such as the debugWire interface). But now consider the DWEN fuse bit (which is used to enable/disable
* the debugWire interface). What if both the SPIEN *and* the DWEN fuse bits are cleared? Both interfaces will
* be disabled. Effectively, the AVR will be bricked, and the only course for recovery would be to use
* high-voltage programming.
*
* When updating the DWEN fuse, Bloom relies on data from the target description file (TDF). But there is no * When updating the DWEN fuse, Bloom relies on data from the target description file (TDF). But there is no
* guarantee that this data is correct. For this reason, we perform additional checks in an attempt to reduce * guarantee that this data is correct. For this reason, we perform additional checks in an attempt to reduce
* the likelihood of bricking the target: * the likelihood of bricking the target:

2
src/Targets/TargetDescription/TargetDescriptionFile.cpp
View File

@@ -85,7 +85,7 @@ namespace Targets::TargetDescription
: std::nullopt; : std::nullopt;
} }
const AddressSpace & TargetDescriptionFile::getAddressSpace(std::string_view key) const { const AddressSpace& TargetDescriptionFile::getAddressSpace(std::string_view key) const {
const auto addressSpace = this->tryGetAddressSpace(key); const auto addressSpace = this->tryGetAddressSpace(key);
if (!addressSpace.has_value()) { if (!addressSpace.has_value()) {

2
src/Targets/TargetDescription/TargetDescriptionFile.hpp
View File

@@ -104,8 +104,8 @@ namespace Targets::TargetDescription
protected: protected:
std::map<std::string, std::string> deviceAttributesByName; std::map<std::string, std::string> deviceAttributesByName;
std::map<std::string, AddressSpace, std::less<void>> addressSpacesByKey;
std::map<std::string, PropertyGroup, std::less<void>> propertyGroupsByKey; std::map<std::string, PropertyGroup, std::less<void>> propertyGroupsByKey;
std::map<std::string, AddressSpace, std::less<void>> addressSpacesByKey;
std::vector<PhysicalInterface> physicalInterfaces; std::vector<PhysicalInterface> physicalInterfaces;
std::map<std::string, Module> modulesMappedByName; std::map<std::string, Module> modulesMappedByName;
std::map<std::string, Module> peripheralModulesMappedByName; std::map<std::string, Module> peripheralModulesMappedByName;