Call me back | My basket | Checkout | Add to email list

     You are here: Website » Knowledge base

« back to website

DataAndConfigurationMessages / 108GeneralConfiguration

General Configuration and Reflash message #108


Data 0 - Header Byte for DL1 Reflash (108 0x6C)
Data 1 - Channel length
Data 2 - Hardware type
All hardware = 0
DL1 = 0x1
DASH2 = 0x2
DASH3 = 0x3
VIDEO4 = 0x4
DL2 = 0x5
SPEEDBOX = 0x6
NEW DASH2 = 0x21

For hardware type #0: This is a special case and it used to get a list of all hardware in the system. When this message is received the device check to see if it already contains its own device type and serial number. If it doesn’t:

  • it adds on it’s own device type and serial number, updates the message length and recalculates it’s checksum then retransmits it. There can be a maximum of 16 devices inter-connected on a loop.
  • if it is already included then the message is discarded

The message will be built up in the format:

Header length 0 hardware1 serial LSB 1 serial MSB 1 hardware2 serial LSB 2 serial MSB 2 hardware3 serial LSB 3 serial MSB 3 ........ checksum

For all other hardware types:

Data 3 - Device Serial Number LSB
Data 4 - Device Serial Number MSB
The serial number is calculated using (data4) x 256 + (data3)

When any hardware sees a “general configuration message type 108”, then it decodes it and checks the hardware type against itself, and then the serial number against itself. If both match then it uses the information and makes a suitable response. In the case the device and/or serial number do not match then the serial message is re-transmitted.

 

Note that serial message “0” is a special case and should match any serial number.

 

Data 5 – message type
request read bytes = 0
request write bytes = 1
read/write response= 2
initialize write sequence = 3
acknowledge initialize write = 4
end write sequence = 5
acknowledge end write = 6
not used = 7
reset device = 8
acknowledge read fail = 9
request & acknowledge analogue data = 10
request & acknowledge accelerometer data = 11
request & acknowledge gyroscope data = 12
request gyroscope disconnect = 13
request to run board test = 14
internal use = 15
end of reflashing = 16
acknowledge write fail = 17
request active user = 18
request to change user = 19
acknowledge user messages = 20
flash sector read = 21
flash sector write = 22
flash sector read reply = 23
flash sector write reply = 24

 

For message type #0 “request read bytes”
Data 6 -Flash Address LSB
Data 7 -Flash Address
Data 8 -Flash Address
Data 9 -Flash Address MSB
Data 10 -Number of bytes requested (1 byte)

 

For message type #1 or #2 “request write bytes” or “read/write response”
Data 6 -Flash Address LSB
Data 7 -Flash Address
Data 8 -Flash Address
Data 9 -Flash Address MSB
Data 10 onward - Message Data Bytes ( Max 64 bytes)
Note that the number of bytes that are included can be calculated from the message length. In the case of a request to write bytes, then the data is the data to be written to the unit. In the case of a read response, then the data is the data read back from the unit’s memory, in the case that the memory is inaccessible, then no bytes should be returned in the payload.

 

For message type #3 “initialize write sequence”
Data 6-11 = {0x02,0x15,0x86,0x77,0x21,0xFF}

 
This is a random sequence of bytes that tell the system to prepare itself to be configured, this is in case the target system needs to prepare itself for a reflash and also as a security measure to ensure that the system is being intentionally written to.

For message type #4 “acknowledge initialize write”
Data6 = acknowledge status
Okay = 1
General failure = 2
(more failure types might be added in the future)

For message type #5 “end write sequence”
Data 6-11 = {0x45,0x65,0x12,0x11,0x81,0xAA}
This random sequence of bytes tells the system to transfer the data from it’s buffer (if any) and move them to the final location if required. Typically this will mean that the bytes are moved from RAM to FLASH.

 

For message type #6 “acknowledge end write”
Data6 = acknowledge status
Okay = 1
Unable to write to flash = 2
Error in flash validation = 3

 

For message type #8 “reset device”
This message is used to forcefully reset the target device.
No reply to this message.

 

For message type #9 “acknowledge read fail”
Data6 = acknowledge status

Device not yet calibrated = 4
Invalid flash address = 5
No valid configuration = 6
No common user configuration found = 7
Different user active in device = 10
 

For message type #10 “request analogue data”
This message is used to request analogue data for calibration.

Data6 = analogue channel id
 

For message type #10 “acknowledge analogue data”

Data6, 7 = analogue data
 

For message type #11 “request accelerometer data”
This message is used to request accelerometer data for calibration.


For message type #11 “acknowledge accelerometer data”

Data6, 7 = longitude acceleration
Data8, 9 = latitude acceleration
Data10, 11 = vertical acceleration
 

For message type #12 “request gyroscope data”
Data6 = request type

Offset = 0
Gain = 1
Temp = 2
 

For message type #12 “acknowledge gyroscope data”

Data6 - 9 = data
 

For message type #13 “request gyroscope disconnect”
This message is used to disconnect gyroscope for calibration purposes

 

For message type #14 “request to run board test”
This message forces the device to restart the unit and run board test programme.
No reply to this message.

 

For message type #16 “end of reflashing”
This finalises reflashing of the device.
No reply to this message.

 

For message type #17 “acknowledge write fail”
->Data6 = acknowledge status

General failure = 2
Invalid flash address = 5
Different user active in device = 10


For message type #18 “request active user”
This message is used to call active user from the device.

 

For message type #19 “request to change user”
This message is used to change the current user of the device.

Data6 = user id from 0 to 8
 

For message type #20 “acknowledge user messages”

If request is #18
Data6 = current user id (from 0 to 8)
If request is #19
Data6 = acknowledge status
No valid configuration for this user = 6
Same user found = 8
User changed = 9
 

For message type #21 “flash sector read”
Data 6 –Drive number
Data 7 -Flash Sector LSB
Data 8 -Flash Sector
Data 9 -Flash Sector
Data 10 -Flash Sector MSB
Data 11 -Number of sectors requested (1 byte)

 

For message type #22 “flash sector write”
Data 6 –Drive number
Data 7 -Flash Sector LSB
Data 8 -Flash Sector
Data 9 -Flash Sector
Data 10 -Flash Sector MSB
Data 11 –Offset in sector (this is 0,1,2,3) for which 128 byte section of the sector is being written)
Data 12-139 - 128 bytes of sector data
Data 140-141 - two byte data only checksum

 

For message type #23 “flash sector read reply”
Data 6 –Drive number
Data 7 -Flash Sector LSB
Data 8 -Flash Sector
Data 9 -Flash Sector
Data 10 -Flash Sector MSB
Data 11 –Offset in sector (this is 0,1,2,3) for which 128 byte section of the sector is being written)
Data 12-139 - 128 bytes of sector data
Data 140-141 - two byte data only checksum

 

For message type #24 “flash sector write reply”
Data 6 –Drive number
Data 7 -Flash Sector LSB
Data 8 -Flash Sector
Data 9 -Flash Sector
Data 10 -Flash Sector MSB
Data 11 –Offset in sector
Data 12 – acknowledge status
-->Okay = 1

Unable to write to flash = 2
Error in flash validation = 3
 

Typical read procedure (not sectors):

  • Reads can happen at any time, so just
  • Request read bytes (#0), and unit should respond with the bytes that are read (#2)
 

Typical write procedure (not sectors):

  • We send a message to initialize writes (#3)
  • System acknowledges as okay (#4)
  • We send writes message (#1)
  • System responds and these are checked against the request (#2)

(the above 2 are repeated as required)

  • When complete, or a buffer flush is required, complete the write sequence (#5)
  • Wait for acknowledge (#6)

Typical read procedure (sectors):

  • Reads can happen at any time, so just
  • Request read bytes (#21)
  • Unit replies with message #23, four messages per sector, for as many sectors as are requested

Typical write procedure (sectors):

  • We send a message to initialize writes (#3)
  • System acknowledges as okay (#4)
  • We send write message (#22) for ‘offset in sector’ 0
  • System responds with ‘offset in sector’ 0 acknowledge (#24)
  • Repeat write message and acknowledge for ‘offset in sector’ 1,2,3
(the above 2 are repeated as required)

The receiving system will store internally the data which makes up a complete sector.

After each section for offset 0,1,2 is received and the checksum is checked it will send an acknowledge

The acknowledge for offset in sector 3 is only sent after the data has been written to the memory card and checked.

When writing all the sectors has been finished, a write sequence message should be sent (#5). This won’t actually write anything to the card, but it will take the unit out of the writing mode.

When the unit is in the writing mode other functions on the unit will not work, such as serial ports, CAN, data logging, etc. This is to reduce the chances of problems with multiple access to the memory card.

Page last modified on November 15, 2011, at 12:44 PM