Annoying bug - Revision history

Rew at 14:30, 10 January 2013

2013-01-10T14:30:16Z

Rew at 16:24, 9 January 2013

2013-01-09T16:24:31Z

Rew at 16:08, 9 January 2013

2013-01-09T16:08:05Z

Rew: Created page with "Earlier versions of RPI_UI and DIO had an annoying bug in the firmware. * Dio 1.3 has fixed firmware. * RPI_UI 1.3 has fixed firmware. The bug in dio manifests it self as..."

2013-01-09T16:05:09Z

Created page with "Earlier versions of RPI_UI and DIO had an annoying bug in the firmware. * Dio 1.3 has fixed firmware. * RPI_UI 1.3 has fixed firmware. The bug in dio manifests it self as..."

New page

Earlier versions of RPI_UI and DIO had an annoying bug in the firmware.

* Dio 1.3 has fixed firmware.
* RPI_UI 1.3 has fixed firmware.

The bug in dio manifests it self as follows: When you write the value 0x1234 to the nsamp register (0x81) with the value 0x1234 TWICE, the value 0x3412 is read back.

his means that as a workaround for this board, you should byteswap the value you want and then write it twice. This can be done in one SPI transaction of only one byte extra.

In rpi_ui the lower 8 bits will always remain 0x00. So after writing 0x1234 twice, you'll see 0x3400 in the register. This means that you have the choice of using 0x40, the default (i.e. do not touch the register at all) or use a multiple of 0x100.

Luckily this is only an issue for the nsamp register.

@@ Line 6: / Line 6: @@
 The bug in dio manifests it self as follows: When you write the value 0x1234 to the nsamp register (0x81) with the value 0x1234 TWICE, the value 0x3412 is read back.
-his means that as a workaround for this board, you should byteswap the value you want and then write it twice. This can be done in one SPI transaction of only one byte extra.
+his means that as a workaround for this board, you should byteswap the value you want and then write it twice. This could be done in one I2C transaction of only one byte extra (send address, register address, highbyte, lowbyte, highbyte). Or: Send a dummy byte between the register address and the lowbyte.
-In rpi_ui the lower 8 bits will always remain 0x00. So after writing 0x1234 twice, you'll see 0x3400 in the register. This means that you have the choice of using 0x40, the default (i.e. do not touch the register at all) or use a multiple of 0x100.
+In rpi_ui the lower 8 bits will always remain 0x00. So after writing 0x1234 twice, you'll see 0x3400 in the register. This means that you have the choice of using 0x40, the default (i.e. do not touch the register at all) or use a multiple of 0x100. (the lowbyte will always be ignored anyway, so the shortest way is to just send the highbyte. Or you can treat it the same as i2c_dio above: send three bytes).
 Luckily this is only an issue for the nsamp register. Version 1.3 and further have this problem fixed.

@@ Line 1: / Line 1: @@
-Earlier versions of RPI_UI and DIO had an annoying bug in the firmware.
+Earlier versions of the I2C versions of RPI_UI and DIO had an annoying bug in the firmware.
 * Dio 1.3 has fixed firmware.
@@ Line 11: / Line 11: @@
 Luckily this is only an issue for the nsamp register. Version 1.3 and further have this problem fixed.
+Example with an I2C rpi_ui with the bug:
+ raspberrypi:/home/pi# bw_tool -I -a 94 -W 81:1234
+ raspberrypi:/home/pi# bw_tool -I -a 94 -W 81:1234
+ raspberrypi:/home/pi# bw_tool -I -a 94 -R 81:s
+Example with an I2C dio with the bug:
+ raspberrypi:/home/pi# bw_tool -I -a 84 -R 81:s
+ raspberrypi:/home/pi# bw_tool -I -a 84 -W 81:1234
+ raspberrypi:/home/pi# bw_tool -I -a 84 -W 81:1234
+ raspberrypi:/home/pi# bw_tool -I -a 84 -R 81:s
+ raspberrypi:/home/pi#

← Older revision		Revision as of 16:08, 9 January 2013
Line 10:		Line 10:
	In rpi_ui the lower 8 bits will always remain 0x00. So after writing 0x1234 twice, you'll see 0x3400 in the register. This means that you have the choice of using 0x40, the default (i.e. do not touch the register at all) or use a multiple of 0x100.		In rpi_ui the lower 8 bits will always remain 0x00. So after writing 0x1234 twice, you'll see 0x3400 in the register. This means that you have the choice of using 0x40, the default (i.e. do not touch the register at all) or use a multiple of 0x100.

	Luckily this is only an issue for the nsamp register.		Luckily this is only an issue for the nsamp register. Version 1.3 and further have this problem fixed.