Micro CAN Release Notes
- 1 General
- 2 V6.0.23
- 3 V6.0.21
- 4 V6.0.20
- 5 V6.0.18
- 6 V6.0.17
- 7 V6.0.15
- 8 V6.0.14
- 9 V6.0.13
- 10 V6.0.12
- 11 V6.0.10
- 12 V6.0.8
- 13 V6.0.7
- 14 V6.0.6
- 15 V6.0.5
- 16 V6.0.4
- 17 V6.0.2
- 18 V1.5.6
- 19 V1.5.5
- 20 V1.5.2
- 21 V1.5.1
The Micro CAN Module firmware is published as Open Source since firmware release V1.0.x. Below you'll find all the changes since that release.
The firmware updates happening in the Openmotics portal (Settings - Update) contain not only the firmware update of the Master, but also the firmware of other modules as well as the updates for the Beagle Bone Black. All these different firmware updates are assembled in a package which get's a general version number. This version number which you see in the portal is not the same as the Firmware Version of the Master. To check which firmware version is installed on the Master or any other module, in the Openmotics portal, go to Settings - Maintenance and open maintenance mode by pressing the Connect button. Type the instruction
firmware version to read the Master Firmware version.
- V6.x.y only works with Gen 3 hardware
- This firmware will support the writing of the Hardware version by the test system
- When the hardware version=255, the hardware version will automatically be set at 69 (Hardware release E)
- The firmware will update RAM every few minutes
- All internal eeprom locations can be read and written over the CAN bus. To allow this, the necessary CAN instructions have been added. This can be done by using CLI instruction "eeprom read" and "eeprom write".
- Sensors are not always working correctly. This release solves this issue
- Hw Revision has been added in Firmware and will be transmitted (together with Serial number) to the Master when CLI instruction "can ping list" is used
- Hw revision will be used to select the correct pins for the correct Hw version. The Hw revision will be programmed in eeprom during testing.
- Standard CAN parameters are being modified to be inline with the Brain and CAN Control parameters
- The timeout of a uCAN to revert to the standard CAN settings have been modified to 2 minutes. After a revert of parameters, the uCAN will reset automatically.
- When CLI instruction "sensor indicate" is used, multiple buzzers of multiple sensors could be ON at the same time. In this release, only one buzzer can be ON of the connected sensors.
- Firmware adapted to Hardware revision PBL-000046-F
- Firmware is also compatible with Hardware revision PBL-000046-E
- Double inputs could be detected on the same uCAN in other words, 2 inputs of the same uCAN could be linked to same virtual input. This release solves this issue.
- Factory reset has been added to this release: CAN broadcast 0 52 17 1 69 (+crc) will factory reset all connected uCAN's and erase the programmed information.
- When the CLI instruction "can speed write" was executed and in the case some uCAN's didn't receive this command, the CAN bus could be in a non-functional state after a reset. To resolve this, uCAN's that are not receiving correct CAN bus message within 40 seconds will be brought back to the factory CAN settings (125kbps). This will allow to recover the CAN bus.
- CAN parameters have been modified to improve CAN network stability. This release must be done together with Brain V1.0.89 and Can Control V6.0.32.
- CAN Speed selection: In this release (together with Brain(+) V1.0.89 or higher), you can change the speed of the CAN bus.
- CLI instruction "can speed read" is used to read the current speed
- CLI instruction "can speed write" is used to write the new speed (effective after reset)
- uCAN Eeprom bytes have been added, see https://wiki.openmotics.com/index.php/Bootloading_uCAN%27s_using_the_AIO
- CLI instruction "can ping list" has been modified to display the CAN parameters
- In this release, the speed of the CAN bus can be changed between 20, 50 and 125kbps (effective after reset)
- When initialising a uCAN on a bus with multiple uCAN's, the first press generate a beep on all uCAN's resulting in a power peak (and voltage drop) so CAN message got lost and button adding was not working very well. This release resolves this problem.
- The processor used in this module contains an Eeprom. This Eeprom is also used to share information between the application and the boot loader. In this release, byte 129 of the processor Eeprom will contain the number of retries the boot loader will use (to jump to application):
- Every time the boot loader jumps to application, the value of this byte (Eeprom byte 129) will be decreased with 1.
- After successful jumping to application, the application will reset this value (Eeprom byte 129) to 5 (retries).
- The led outputs are linked with the correct inputs
- This release adds the necessary functions and CAN modifications to do full testing of the Micro CAN via the Openmotics Test System
- The T67xx sensor needs stabilisation after a reset. So samples are measured first and once stabilisation is detected, the values are transmitted to the Master. This will take between 4 and 5 minutes before CO2 values of this sensor will appear.
- Input indicate with buzzer functionality has been added
- Sensor indicate with buzzer functionality has been added
- The indicate function remains active for 1 minute, after this, the buzzer and input leds will be switched off. When a non-linked input is pressed, the buzzer and associated led will be switched off.
- When the Honeywell sensor is connected, the status led should flash blue-green-red-red which wasn't the case. This is resolved in this release.
- Setup functionality added:
- The CAN protocol from the Brain(+) also sends the linked output when a CAN connected switch is pressed
- When no output is linked to the input pressed, a brief beep will sound
- When no output is linked to the input pressed, the input led will go ON as long as the input is pressed
- Enabling/disabling of the Multi-color led is made persistent in Flash
- Enabling/disabling of Buzzer is made persistent in Flash
- Enabling/disabling of Buzzer for non linked outputs has been added and made persistent
- Buzzer timer functionality has been added
- In case of a short circuit or overcurrent situation on the 5V OUT, the beeper will beep fast
- In case of a short circuit or overcurrent situation on the 5V OUT, An event will be thrown to the Core/Core+
- In case the Overcurrent situation is over, the beeper will stop beeping
- In case the Overcurrent situation is over, An event will be thrown to the Core/Core+
- In case the 5V out is switched ON or OFF, An event will be thrown to the Core/Core+
- Detection of failed i2c sensors have been improved and additional mechanism have been added to restore failed sensors
- The firmware includes all necessary changes for the new Micro CAN module
- Timer3 is configured and enabled to let the buzzer work (PWM)
- When an indicate (input, sensor or module) instruction is received, the buzzer will also be enabled
- An additional instruction (CAN instruction 97) has been added to switch ON/OFF the buzzer manually
- An additional instruction (CAN instruction 98) has been added to switch ON/OFF the built-in multi-color indication led
- Improved discovery of the sensors: When the first input of a uCAN is pressed, the sensor is discovered immediately. In CLI mode, when "debug on" is entered, you will see the sensor appear together with the first input pressed.
- In CAN networks with long cables, power instability can occur resulting in RAM memory loss of some RAM locations. When this happens, the module could for example think that an input or sensor is new and will add this as new in the Master. This release will read the stored configuration out of eeprom before it add a new input or sensor.
- Eeprom verification: After each write in eeprom, a read will happen to verify that the value is correctly written
- CAN input and output erase: In previous releases, when the CC was sending for example that the NrOfInputs=0 the all the programmed inputs were erased. In this release, a dedicated message must be received before an erase of inputs or sensors will happen
- Converted to single Master behaviour in other words, the CAN Control is Master over the CAN bus and will control the number of sensors and what the next sensor number will be. This will also apply for the inputs.
- Based on Firmware V1.3.56
- When no sensor request from Master is received, uCAN will sent sensor values automatically