-
Notifications
You must be signed in to change notification settings - Fork 18
Description
KNX Spec. 3.0 06 Profiles 4.2.10 User EEPROM specifies BIM112 UserEeprom range 0x4000-0xCFFF.
In most of our BIM112 applications the user eeprom starts with the group address table 0x4000-41ff, followed by the association table 0x4200-43ff
and then the communication object table 0x4400-0x....
The offset list of UserEepromMASK0701 derived from UserEepromBCU2 class:
software-arm-lib/sblib/inc/sblib/eib/userEepromBCU2.h
Lines 21 to 46 in 4e6a918
| static const int appTypeOffset = 0x015; //!< 0x0115: \todo Application program type: 0=BCU2, else BCU1 | |
| static const int loadStateOffset = 0x370; //!< 0x0470: Load state of the system interface objects | |
| static const int addrTabAddrOffset = 0x378; //!< 0x0478: Address of the address table | |
| static const int assocTabAddrOffset = 0x37A; //!< 0x047a: Address of the association table | |
| static const int commsTabAddrOffset = 0x37C; //!< 0x047c: Address of the communication object table | |
| static const int commsSeg0AddrOffset = 0x37E; //!< 0x047e: Address of communication object memory segment 0 // TODO needs implementation, see handleTaskCtrl2(...) in properties.cpp | |
| static const int commsSeg1AddrOffset = 0x380; //!< 0x0480: Address of communication object memory segment 1 // TODO needs implementation, see handleTaskCtrl2(...) in properties.cpp | |
| static const int eibObjAddrOffset = 0x382; //!< 0x0482: Address of the application program EIB objects, 0 if unused. // TODO needs implementation, see handleTaskCtrl1(...) in properties.cpp | |
| static const int eibObjCountOffset = 0x384; //!< 0x0484: Number of application program EIB objects. // TODO needs implementation, see handleTaskCtrl1(...) in properties.cpp | |
| static const int padding1Offset = 0x385; //!< 0x0485: Padding 1 | |
| static const int serviceControlOffset = 0x386; //!< 0x0486: Service control | |
| static const int padding2Offset = 0x388; //!< 0x0488: Padding 2 | |
| static const int serialOffset = 0x38A; //!< 0x048A-0x48f: Hardware serial number (4 byte aligned) | |
| static const int orderOffset = 0x390; //!< 0x0490-0x0499: Hardware Type | |
| static const int orderInfoOffset = 0x39A; //!< 0x049A-0x04A3: Ordering information | |
| ///\todo why here, isn't this system b specific? | |
| static const int addrTabMcbOffset = 0x3A4; //!< 0x04A4-0x04AB: | |
| static const int assocTabMcbOffset = 0x3AC; //!< 0x04AC-0x04B3: | |
| static const int commsTabMcbOffset = 0x3B4; //!< 0x04B4-0x04BB: | |
| static const int eibObjMcbOffset = 0x3BC; //!< 0x04BC-0x04C3: | |
| static const int commsSeg0McbOffset = 0x3C3; //!< 0x04C4-0x04CB: ///\todo address missmatch? | |
| static const int eibObjVerOffset = 0x3CC; //!< 0x04CC-0x04D0: Application program 1 version | |
| static const int commsSeg0VerOffset = 0x3D1; //!< 0x04D1-0x04D5: Application program 2 version |
All these offsets are accessing the userEepromData array
| __attribute__ ((aligned (FLASH_RAM_BUFFER_ALIGNMENT))) byte *userEepromData; // must be word aligned, otherwise iapProgram will fail |
Memory::normalizeAddress software-arm-lib/sblib/inc/sblib/eib/memory.h
Line 112 in 4e6a918
| void normalizeAddress(uint32_t* address) const {(*address -= startAddress);} |
This causes all of these offsets to fall within the range 0x4270-0x42D5, which conflicts with the range of the association table 0x4200-43ff and can corrupt it.
HOWTO check if my device is affected:
BIM112 devices with less then ~57 group address/communication object associations should not be affected by this bug.
You can check whether a device may be affected using the ETS function “Compare Device.”
Example of an affected device:

Affected applications/devices:
- MultiSensorAktor
- rol-jal-bim112
- dim4-bim112
- led-4-channels-bim112
- out-cs-bim112
- weatherstation-bim112
- in16-bim112
- rain-bim112
As far as i could track this down, this bug exists at least ever since commit 5eeced8 from 2015.
Since we are currently undergoing an extensive refactoring of the lib, I would suggest changing as little source code as possible to fix this bug. The easiest way would be to subtract from the UserEepromBCU2 offset addresses 0x300. This would place all offsets before the user EEPROM and in a range that is already reserved by UserEepromMASK0701 but not entirely used.
| UserEepromMASK0701() : UserEepromBCU2(0x3f00, 3072, 4096) {}; |
