msperl
Posts: 354
Joined: Thu Sep 20, 2012 3:40 pm

Erata in BCM2835 (SoC) Datasheet?

Mon Oct 21, 2013 5:43 pm

Hi!

i am trying to write a DMA driver for the SPI interface and have been running into some "unexpected" walls.

The problem seems to be that if doing a SPI-transfer via DMA the HW seems to require that ADCS is set in the SPI_CS register.

But the BCM2835 Datasheet at least states:

on page 154:

Code: Select all

ADCS Automatically Deassert Chip Select
0 = Don t automatically deassert chip select at the end of a DMA transfer chip select is manually controlled by software.
1 = Automatically deassert chip select at the end of a DMA transfer (as determined by SPIDLEN)
on page 158:

Code: Select all

j) Enable DMA DREQ’s by setting the DMAEN bit and ADCS if required.
My testing shows that without setting the ADCS bit, the following happens:
only CS and MOSI goes low (with default polarity), but the clock does NOT start and thus the DMA transfer is stuck.
With the bit set - everything works like it should...

So I wonder if this is an ERRATA in the Document/Hardware?

Can someone confirm (from the Foundation or Broadcom) if this is the case?

Maybe there is a newer version of the Datasheet with updated information(or some appendix with Errata) that clarifies the situation?

Thanks,
Martin

Edit: corrected by replacing DMAEN with ADCS
Last edited by msperl on Mon Oct 21, 2013 7:07 pm, edited 1 time in total.

notro
Posts: 755
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Oct 21, 2013 6:59 pm

msperl wrote: My testing shows that without setting the DMAEN bit, the following happens:
Do you mean ADCS here?

msperl
Posts: 354
Joined: Thu Sep 20, 2012 3:40 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Oct 21, 2013 7:08 pm

yes - that is correct: ADCS

Post is corrected now - sorry for the confusion...

msperl
Posts: 354
Joined: Thu Sep 20, 2012 3:40 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Sun Nov 03, 2013 12:06 pm

Hi!

Does the Foundation and Broadcom have to say anything on this subject of errata in the existing SOC documentation?

Maybe even opening up some more on the supported devices side?
There should be some means for programming the DSI/CAM device from the ARM side, so that they could get used for some other stuff besides the Camera.

Thanks,
Martin

User avatar
joan
Posts: 16080
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Erata in BCM2835 (SoC) Datasheet?

Sun Nov 03, 2013 12:11 pm


jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 31861
Joined: Sat Jul 30, 2011 7:41 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Sun Nov 03, 2013 2:59 pm

msperl wrote:Hi!

Does the Foundation and Broadcom have to say anything on this subject of errata in the existing SOC documentation?

Maybe even opening up some more on the supported devices side?
There should be some means for programming the DSI/CAM device from the ARM side, so that they could get used for some other stuff besides the Camera.

Thanks,
Martin
I think the intention is to allow access to DSI from the ARM. CSI-2 isn't really possible, you need code on the GPU itself to drive that with any sort of usefulness.
Principal Software Engineer at Raspberry Pi Ltd.
Working in the Applications Team.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1744
Joined: Sat Sep 10, 2011 11:43 am

Re: Erata in BCM2835 (SoC) Datasheet?

Sun Nov 03, 2013 3:34 pm

I think it would be possible to provide access to DSI / CSI without involving the VPU, as an example you can do high data rate comms between two Pi's that way... Unfortunately we know there are significant issues with doing that and nobody out there is going to be able to debug it if it doesn't work

After all you need a £20K LeCroy scope to debug those signals!

So in general it's not really worth the time / money investment to write the documentation and support people doing it.

Gordon
Gordon Hollingworth PhD
Raspberry Pi - Chief Product Officer

msperl
Posts: 354
Joined: Thu Sep 20, 2012 3:40 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 04, 2013 10:35 am

Actually for this thread I was mostly hoping for an update of the SOC-document itself, so that it can get used as a reference.

Ok - there is the "end-user" maintained errata-wiki page, but is that really authoritative?
Does everyone know about this? I did not for example!
Also it is not linked in the "Technical, Help, and Resource Documents" (http://www.raspberrypi.org/phpBB3/viewt ... 44&t=51436) either. (and it requires separate registration)

What other bugs are known but not documented in that wiki?

Everything else is more of a "nice-to-have" list that came as an after-thought while posting the reminder after the thread got forgotten.

So this "other" part of the discussion might better continue in a new thread.

Still I believe after all the things that have been done with the RPI already I would _not_ presume
that people would _not_ want to give the other exposed connectors a try as well - just because it "seems" expensive to do debugging...

Logic-analyzers have come down in price and something like the "red-pitaya" could probably allow the "debugging" of such Signals on a much cheaper level (depending on speeds obviously).

But all of that needs the specific specs to be published so that we all can make use of it in creative and unexpected ways...
(some of it may not be feasible, but without any specs nobody can tell for sure or give it a try...)

In principle - depending how many ALT-mode those CSI/DSI pins are having, if any - I guess these might just as well act as additional GPIO interfaces (just not as easily connectable on a bread-board and probably more prone to EMI/static discharge issues I assume).

I know of people try to drive 320x200 LCD displays at 25Hz using the 30MHz SPI bus using DMA (notro can tell you more on the specifics). So providing the option of using "alternative" interfaces with probably faster speeds would be very welcome in this and other communities and I guess it might even avoid the need of the logic interface required for the HDMIPI... As seen from the above streaming at high frame-rates via DMA is possible - it just depends on the bus speed to get to higher resolutions (and the wiring of the main SPI interface is not made for higher speeds...)

Thanks,
Martin

P.s: Note that I am not asking for any documentation on the VideoCore programming itself, even though it would be nice (hint!) to be able to make use of those 2 additional cores for some FPU/streaming intensive processing (not to mention the GPU), which is (probably) used by the software for the camera-module for the computation of image corrections. And the transfer to/from the camera is probably done via DMA anyway, so this part is available from the ARM core itself...

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 31861
Joined: Sat Jul 30, 2011 7:41 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 04, 2013 10:55 am

Almost all the camera work is done in dedicated HW blocks (including the receipt of data from the camera) - the GPU just handles the data transfer between blocks, with some tweaking of parameters to deal with things like white balance. The VPU is used for some simple software stages, but isn't really fast enough for much more than that.
Principal Software Engineer at Raspberry Pi Ltd.
Working in the Applications Team.

msperl
Posts: 354
Joined: Thu Sep 20, 2012 3:40 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 11, 2013 9:31 am

I think this thread moved more to a "wishlist" thing.

Still - I got some strange observations that I would like confirmed if possible.

The observation is that
  • in SPI_CS (07R204000) TA and DMAEN are enabled
  • if I now write to SPI_CS TA|CLEAR_RX|CLEAR_TX (and DMAEN as well, but it does not make a difference)
  • then CS goes high for a "fraction" of a second. With my Logic Analyzer at 16MHz I can only measure it in 4% of all cases.
Note that the write to the register is done via a DMA transfer of 4 bytes and with only WAIT_RESP set in ControlBlock.info, but it might also be true if done writing "directly" from the ARM as well - I have not tested this yet....

Is this "expected" behavior?

Thanks,
Martin

msperl
Posts: 354
Joined: Thu Sep 20, 2012 3:40 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 11, 2013 10:04 am

OK - I ran it like this without DMA:

Code: Select all

        writel(BCM2835_SPI_CS_TA,bs->regs+BCM2835_SPI_CS);
        for(err=0;err<100000000;err++) {
                writel(
                        BCM2835_SPI_CS_TA /* enable Transfer */
                        | BCM2835_SPI_CS_CLEAR_RX /* clear RX buffers */
                        | BCM2835_SPI_CS_CLEAR_TX /* clear TX buffers */
                        ,bs->regs+BCM2835_SPI_CS);
        }
        writel(0,bs->regs+BCM2835_SPI_CS);
this loop runs in 3.0715 seconds and in my logic analyzer i see that CS toggles 3929229 times during this case (and I am definitely under-sampling here with 16MHz sample frequency, so I do not see all events...)

On the other hand I run with CLEAR_TX_FIFO commented out (but leave CLEAR_RX_FIFO), then everything is "fine"!

So I wonder: if this is expected behavior for the Hardware?
Is there a way around this?

Thanks, Martin

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2737
Joined: Thu Jul 11, 2013 2:37 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 11, 2013 2:09 pm

I wouldn't really call this "errata" - more like behaviour in edge cases that certainly wouldn't have been beaten out of the hardware before the documentation was written.

Given that the Pi is now being used with an entire ecosystem of devices, I would say that having a formally updated datasheet / programming model for the various hardware blocks would be a very useful thing to have.

The forum and probably the eLinux wiki would be the wrong place to collate information on the subject. If the eventual intent is to fully document the vagaries of the hardware then I would suggest starting a documentation project on Github. Full technical descriptions of the various peripheral blocks can then be accurately recorded (with the history of who discovered what being tracked through issue threads).

Doing it in a somewhat centrally controlled manner would then make it much easier to bring a formal datasheet update.
Rockets are loud.
https://astro-pi.org

msperl
Posts: 354
Joined: Thu Sep 20, 2012 3:40 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 11, 2013 2:47 pm

jdb wrote:I wouldn't really call this "errata" - more like behaviour in edge cases that certainly wouldn't have been beaten out of the hardware before the documentation was written.

Given that the Pi is now being used with an entire ecosystem of devices, I would say that having a formally updated datasheet / programming model for the various hardware blocks would be a very useful thing to have.
Well, then IMO Broadcom should provide official errata to their SOC - like other Vendors do...
But then, they probably do, but only to people with a signed NDA...

Or at least update the Peripheral document regularly after they have confirmed there is a bug and can tell EXACTLY what the behavior is...

I believe the Foundation and Broadcom _can_ talk about roles and responsibilities for the HW documentation and come up with a way acceptable to the end-users to write some code...
jdb wrote:The forum and probably the eLinux wiki would be the wrong place to collate information on the subject. If the eventual intent is to fully document the vagaries of the hardware then I would suggest starting a documentation project on Github. Full technical descriptions of the various peripheral blocks can then be accurately recorded (with the history of who discovered what being tracked through issue threads).

Doing it in a somewhat centrally controlled manner would then make it much easier to bring a formal datasheet update.
Us hobbyists can only point out that we see an issue, but we can not confirm under what circumstances it really occurs.
And for that a wiki/mailing-list/forum page... for reporting such issues would be good - not all of us are technical writers, have signed NDAs with Broadcom and/or have high end equipment to test such "border-cases" to write and maintain the DOC-documentation _for_ Broadcom or the Foundation.

Both make money with the equipment sold, so they should also spend some resources on supporting the SOC and keeping documentation up to date (and maybe opening up a bit more of the devices).

Thanks, Martin

P.s: In the above case - there is an observation that it happens in 4% of all writes to the SPI-control register, but I do not have a logic analyzer/oscilloscope that is "fast" enough (>500MHz, as the SPI clock is 250MHz) to see if this CS glitch happens in all cases (but is very short), or only under some circumstances (and then when this happens, how long CS stays disabled)

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1744
Joined: Sat Sep 10, 2011 11:43 am

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 11, 2013 3:51 pm

What are you expecting to happen here? You are sat in a loop setting the transfer active and clearing the FIFOs and therefore throwing away the data (I assume the data is being pushed in using DMA with a DREQ?)

There will be a period (of a few cycles...) between clearing the FIFOs and the new data becoming available (from the DMA) during this period the nCS signal will go high...

Gordon
Gordon Hollingworth PhD
Raspberry Pi - Chief Product Officer

msperl
Posts: 354
Joined: Thu Sep 20, 2012 3:40 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 11, 2013 4:59 pm

Well, I am trying to pipeline DMAs - especially Writes then Reads.
As DMA does 32 bit only it works perfectly as long as the number of bytes are multiple of 4.
If not then I need to do Clear RX and TX - as the "DLEN" is not "honoured" in this case really from the FIFO perspective.
If I write 3 Bytes in DLEN and then do the DMA then after the DMA and transfer is finished there is still one byte min the FIFO
Even when I have "said": 3 bytes only.

An even simpler case would be writing a datablock to an SD card via SPI - first the addressing bytes (2 bytes if I remember correctly), then 512 bytes of data , then 2 bytes crc. so which could get done in 3 DMAs without any Copying, but due to all the issue I have to reset the FIFOS after the 1st and 3rd.

If I do a reset of the TX-FIFO, why does it require that CS goes up - that is not a logical requirement, so the datasheet should mention it. (but why does it not happen for the RX FIFO?)
Especially if you look at it that you _can_ reset the FIFOS and also enable TA. So if the above was not correct, then this should
not work either.
gsh wrote:There will be a period (of a few cycles...) between clearing the FIFOs and the new data becoming available (from the DMA) during this period the CS signal will go high...
And if resetting takes some time, then it should get mentioned in the Datasheet as a requirement (which it does not state).
Nor does it state that CS will/may go high for a few cycles (whatever cycles means in this context SPI Clock or cdif divided SPI Clock - I would guess the former) - and documenting this case is especially important, as it is VERY hard to detect such a "glitch" of maybe only 4ns CS high with hobbyist equipment - and then it may ONLY happen in 5% of all cases... And then not all devices might even detect such a thing.

Something else related to FIFO: I also found that if you reset your FIFO and at the same time set DMAEN and TA, then in some cases (I did not even measure the percentage) at some point the "clock" ticks are not shifted out, while MOSI for example does change during that time - which results in the RX-DMAs getting stuck waiting for the transfer to finish for the missing byte.
But if you Reset Fifos, set dlen and then set CS to the final "value" it works...

Also the datasheet should also state that ADCS is required for a DMA to work, not optional like described in the "DMA Cookbook".

And finally the DMEN is ONLY honored if the CB is the last one in the chain (cb.info=DMEN;cb.next=NULL;) otherwise no interrupt gets triggered.

In the end the whole DMA pipelined thing is (almost) working and it is reducing CPU utilization a lot compared to the polling or interrupt-driven interfaces that are implemented in the linux kernel now.

What I am asking is that someone updates the SOC datasheet and updates it - not every "bug" found is also documented in the elinux wiki page and other people may also fall into the same traps, which is totally unnecessary...

And that is what I am asking for:
  • an updated datasheet with updates to everything that is not working as defined - the document is now almost 2 years old
  • a way to report a HW-bug so that they can get documented in the datasheet at some point (or clarifications if someone dislikes to see it called "errata")
And I believe others will also benefit from this effort.

Martin

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2737
Joined: Thu Jul 11, 2013 2:37 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 11, 2013 5:48 pm

msperl wrote: And that is what I am asking for:
  • an updated datasheet with updates to everything that is not working as defined - the document is now almost 2 years old
  • a way to report a HW-bug so that they can get documented in the datasheet at some point (or clarifications if someone dislikes to see it called "errata")
And I believe others will also benefit from this effort.

Martin
You will not get an updated datasheet. To do so would require Broadcom to commit engineering/technical writing hours which costs money. Because the documentation for such sparsely-used peripherals will have a negligible impact on volume sales of the SoC, the cost vastly outweighs the benefit. It's even a stretch to task an R-Pi employee with updating it - same principle applies.

This is why I suggested creating a documentation repository on Github to collate the information gathered from the myriad posts on this forum - I2S/I2C/SPI have received the most attention and as such there are forum posts describing the hardware interaction quite well. If there is impetus among the hardware modders for writing everything down so that a random IC can be interfaced with a Pi, then the repo would gain traction and become more reliable than the datasheet. The workflow for finding and documenting the errata/unexpected behaviours is also more clearly defined than random posts on a forum or the wikified eLinux.
Rockets are loud.
https://astro-pi.org

msperl
Posts: 354
Joined: Thu Sep 20, 2012 3:40 pm

Re: Erata in BCM2835 (SoC) Datasheet?

Mon Nov 11, 2013 6:23 pm

jdb wrote:This is why I suggested creating a documentation repository on Github to collate the information gathered from the myriad posts on this forum - I2S/I2C/SPI have received the most attention and as such there are forum posts describing the hardware interaction quite well. If there is impetus among the hardware modders for writing everything down so that a random IC can be interfaced with a Pi, then the repo would gain traction and become more reliable than the datasheet. The workflow for finding and documenting the errata/unexpected behaviours is also more clearly defined than random posts on a forum or the wikified eLinux.
Documenting the HW bugs should be in the best interest of the Foundation, so maybe it should start this project you proposed - it can get the original documents in a "better" format than just the PDF, which is NOT easily editable at all.
Also if it spends time/money on projects like pypy, which is commendable, why not spend some time/money on documenting its own product?

Any further bugs in the HW I find I will post here, as well as in the unofficial errata-wiki, which I still would recommend that you link to in your documentation thread, so that it is more visible...

Ciao, Martin

P.s: Anyway: I found a "workarround" for this last HW bug, but can not know if this may trigger other bugs...

Return to “Interfacing (DSI, CSI, I2C, etc.)”