Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the requirement for hardware SPI #3

Merged
merged 2 commits into from Feb 25, 2019

Conversation

Projects
None yet
3 participants
@tari
Copy link
Contributor

commented Feb 25, 2019

I spent a while fighting with my hardware before working this out- if
SPI is disabled in the kernel then reads will return all 1s which is very
confusing and looks more like something is wired up wrong when it's
actually correct.

Document the requirement for hardware SPI
I spent a while fighting with my hardware before working this out- if
SPI is disabled in the kernel reads will return all 1s which is very
confusing and looks more like something is wired up wrong when it's
actually correct.
@xobs

This comment has been minimized.

Copy link
Member

commented Feb 25, 2019

Curious. That shouldn't be the case. Let me investigate what's going in...

@xobs

This comment has been minimized.

Copy link
Member

commented Feb 25, 2019

Does it work if you run fomu-flash -i twice? That should print various SPI flash information registers.

There appears to be a reset issue when first powering up a device, and this may be related:

fomu@fomu-dev:~ $ fomu-flash -i
Manufacturer ID: unknown (ff)
Memory model: unknown (ff)
Memory size: unknown (ff)
Device ID: ff
Serial number: ff ff ff ff
Status 1: ff
Status 2: ff
Status 3: ff
fomu@fomu-dev:~ $ fomu-flash -i
Manufacturer ID: Winbond (ef)
Memory model: W25Q128JV (70)
Memory size: 128 Mbit (18)
Device ID: 17
Serial number: e4 67 28 65
Status 1: 00
Status 2: 00
Status 3: 60
fomu@fomu-dev:~ $ 
@tari

This comment has been minimized.

Copy link
Contributor Author

commented Feb 25, 2019

No, the all-1 output persisted across as many -i attempts as I cared to attempt.

This is the result of trying two different Raspberry Pis and three different programming fixtures, where one of the fixtures was @mithro's big orange one which I assumed actually did work. Eventually comparing the configuration of my and his Pi images I found that setting dtparam=spi=on makes it work correctly with my hardware (a Pi 2B); I assume turning it off on the Pi 3 will make it stop working in the same way.

I tried using the fomu-pi-gen image too, and it did the same thing- all-1 with the out-of-the-box configuration.


I should note that I'm using Hacker boards attached to my own programming jig, not an EVT attached as a hat.

@xobs

This comment has been minimized.

Copy link
Member

commented Feb 25, 2019

Thanks for testing it, and thank you for the patch. I'll merge this change, update fomu-pi-gen to produce an image with dtparam=spi=on, and then try to figure out just why it's a requirement...

@xobs xobs merged commit fb21ad7 into im-tomu:master Feb 25, 2019

@mithro

This comment has been minimized.

Copy link
Member

commented Feb 25, 2019

This seems really weird, right @xobs? You are bit banging the SPI?

@mithro

This comment has been minimized.

Copy link
Member

commented Feb 25, 2019

I would expect that you need dtparam=spi=off

@xobs

This comment has been minimized.

Copy link
Member

commented Feb 26, 2019

It is really weird, and you're right @mithro that I'm bit-banging SPI. My best guess is that setting dtparam=spi=on causes the kernel to enable clocks to those pins. This doesn't seem to be an issue with the Pi 3.

I intend to see what the issue is once I get access to a Pi 2 and an oscilloscope. I imagine that enabling a clock somewhere will fix the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.