BCM2835 datasheet errata
Back to RPi_Hardware#Components
- 1 BCM 2835 datasheet errata
- 1.1 the BCM2835 on the RPI
- 1.2 PDF Generation
- 1.3 p7 footnote typo
- 1.4 p8
- 1.5 p12
- 1.6 p13
- 1.7 p14
- 1.8 p25 table
- 1.9 p26
- 1.10 p34 off-by-one?
- 1.11 p35 I2C clock stretching
- 1.12 p38 typo
- 1.13 p92 to 95 & 102 to 103
- 1.14 p90
- 1.15 p95
- 1.16 p96
- 1.17 p103 typo
- 1.18 p104 table
- 1.19 p111 spelling
- 1.20 p119 I2S clock
- 1.21 p126
- 1.22 p141
- 1.23 p142/143 register table
- 1.24 p153
- 1.25 p155
- 1.26 p156
- 1.27 p158
- 1.28 p160
- 1.29 p175
- 1.30 p177
- 1.31 p196
- 1.32 p197
- 1.33 p198
- 1.34 p202
BCM 2835 datasheet errata
It has a couple of typos. Some more serious than others.
Let's gather those datasheet typos and errors here.
The quality of the datasheet is high. It looks like it contains the information that programmers need. Some of the tables from the datasheet have been reproduced here.
It also "does the right thing" with reserved bits. Many datasheets specify "write: don't care, read as zeroes". Broadcom specifies the reserved bits the other way around: "Write zeroes, read: don't care".
This is the correct way to do it. If you expand the hardware the hardware may be enhanced and do "different things" if you write ones to the previously "reserved" bits. If you follow the datasheet, and write zeroes as specified to the reserved bits, the hardware guys can make sure you're not going to run into surprises. And by specifying "read: don't care" you can allow future hardware to provide status bits there.
the BCM2835 on the RPI
Not really an erratum, but not worth it to make a whole page for this. The Raspberry Pi runs the BCM2835 with a core clock of 250MHz. This is relevant for the peripheral modules like I2C, SPI and Timer ( ARM side ) for calculating the desired clock rate. The I2C section on page 34 mentions 150MHz as a "nominal core clock".
Switch on option for linking, so cross-references and table of contents can be jumped through. (RPi_BCM2835_GPIOs contains some useful cross-references)
p7 footnote typo
precuations should be precautions.
The register names are AUX_SPI0_.... and AUX_SPI1_.... . The "description" is then SPI 1 ... and SPI 2 ....
These modules are in fact SPI1 and SPI2, and NOT SPI0 and SPI1. This is confusing as indeed there is a different module called SPI0 (documented on page 148 and onwards).
The title should be AUX_MU_IER_REG. The name in the Synopsis is correct
These are R/W bits not read only
Bits 3:2 are marked as don't care, but are actually required in order to receive interrupts.
The title should be AUX_MU_IIR_REG. The name in the Synopsis is correct
LCR register, bit 1 must be set for 8 bit mode, like a 16550 write a 3 to get 8-bit mode
"AUX is IDLE:" should read "SPI is idle". (and for consistency below the line "Interrupts", SPI is Idle should be spelled "SPI is idle".
The table on page 25 has the bit numbers wrong. Some bits are mentioned twice, some not at all.
I'm guessing it should be something like:
|31:24||TX FIFO level||The number of data units in the transmit data FIFO||R/W||0|
|23:16||RX FIFO level||The number of data units in the receive data FIFO.||R/W||0|
|15:10||-||Reserved, write zero, read as don’t care||R/W||0|
|9||TX Full||If 1 the transmit FIFO is full
If 0 the transmit FIFO can accept at least 1 data unit.
|8||TX Empty||If 1 the transmit FIFO is empty R/W 0
If 0 the transmit FIFO holds at least 1 data unit.
|7||RX Empty||If 1 the receiver FIFO is empty R/W 0
If 0 the receiver FIFO holds at least 1 data unit.
|6||Busy||Indicates the module is busy transferring data.||R/W||0|
|5:0||Bit count||The number of bits still to be processed. Starts with 'shift-length' and counts down.||R/W||0|
The register reads as 0x280 after reset. Two bits high would be consistent with TX empty and RX empty. However, bits 7 and 9 does not match the original datasheet, nor my guess.....
The Peek register is documented here as being at 0x7e21508c, whereas the table on page 8 shows 0x7e215094.
The IO register is documented as 0x7e2150a0 (with automatic deassert) and 0x7e2150b0, whereas the table on page 8 shows 0x7e215090.
I strongly suspect that the CDIV counter is only 14 bits wide. The bottom bit doesn't work as per specifications, and because the "0" results in 32768, the top bit doesn't either. An easy implementation would implement the 0 value as the maximum divisor. Not as "half the maximum".
Another option is that SCL = cor clock * 2 / CDIV and that the counter is 15 bits after all. (only the lowest bit missing).
p35 I2C clock stretching
There is a bug in the I2C master that it does not support clock stretching at arbitrary points. It does support clock stretching during the ACK phase. See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=13771#p146272
harware instead of hardware (second paragraph)
p92 to 95 & 102 to 103
The GPIO Alternate function select Registers. This shows a bit pattern of 111 as alternative function 3. If you look at the values after boot up the Pi's SPI interface pins connected to the SD card have this value in them. This does not match the diagram on page 102 - 103 which shows this function is selected with alternative function 4. So either the bit pattern / function information is wrong or Table 6-31 is wrong.
address 0x7e20 0000 is listed twice as gpfsel0.
There is a spurious ) in "..clear registers) are used..."
Instead of "1 = Set GPIO pin n" for GPIO Output Clear Register 1, it should be "1 = Clear GPIO pin n"
The level registers have "0 = GPIO pin n is HIGH" which should be "1 = GPIO pin n is HIGH"
The level registers are listed as R/W but the table on page 90 states that they are only readable, which makes more sense.
In the "BSCSL SDA / MOSI" row of the "Special function legend" table, it says "salve" instead of "slave"
Where it says "BSC ISP slave" it should actually say "BSC/SPI slave"
The table, legend for table 6-31, started on page 103 shows twice in red: TXD0, RXD0, CTS0, RTS0. The second block, with functions starting: UART 1 should be: TXD1, RXD1, CTS1, RTS1.
The table, legend for table 6-31, has no mention of any of the SD1_x functions included in the previous table
top line: device should be devise.
p119 I2S clock
Allusions to the APB clock domain are made. However the exact speed of the APB clock is never explained.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/Cbaifdib.html explains "APB" as the Advanced Peripheral Bus, but that doesn't help much either.
There is amiguity on what register bits can be modified while the I2S system is active. p126 states that only the bottom three bits of CS_A can be modified. However p122 suggests to use the SYNC bit in CS_A for waiting. Does this mean, that the SYNC bit can also be changed at runtime as well?
There is no base address listed for this register block. Should be: 0x7E20C000
p142/143 register table
The CTL register controls both PWM channels 1 and 2, but in the description column, only channel 1 is mentioned. Bits 8 to 15, PWEN2 to MSEN2 should be described as controlling PWM channel 2, not 1. (I think- not confirmed)
Typo: wrirng -> writing.
Near the bottom of the page RXR. This bit would be useful if it signified more than half full. There is a space in "( full)" that would hint at that the word "half" was taken away. Another hint is that it says that the bit clears when "sufficient" data is read from the FIFO. The word sufficient is redundant when this is the "full and active" bit.
The way it is written now, this bit is just the same as bit RXF, except that the TA bit is anded into this one.
Two options. The hardware was changed (detecting "half full" was difficult?) and the documentation was changed accordingly. Or the hardware does what I expect: set this bit when more than half full.
There is a CSPOL bit described here, wereas there are also CSPOL[0,1,2] described on page 153. How do these combine???
The CDIV value is documented as "must be a power of 2". This is not true. I can perfectly set the register to 833 (not a power of 2) and get 250MHz/833 = 300kHz.
Maybe "must be a multiple of 2" was meant???
SPI_FIFO is misspelled as SPIFIFO in the last line of 10.6.2.
The registers base addresses -> the registers' base address or The base address of the registers is 0x7e21_4000.
top line. Two typos:
On mini UART and and PL011 UART
One mini UART and one PL011 UART
13.4 register view
The PL011 USRT is mapped on base adderss
The PL011 UART is mapped on base address
The base address is listed as 0x7e20100 . This should be 0x7e201000.
SP804 not AP804
bit 1, 32 bit counter not 23 bit counter
neither are register 0x40C raw is 0x410, masked is 0x414
The last entry of section 15.1.
The entries in the table should specify the choice that Broadcom made when instantiating the USB controller IP from Synopsys.
Possibly the "choice" hasn't been specified. Or maybe the "0=32, 1..5=512, 6,7=768" is the option that was chosen?